Faster build with SWC or Esbuild

[eric-burel]

Is your feature request related to a problem? Please describe.
I am exploring modern alternatives to Babel/Webpack for a faster build time.

First experiment is on the react-ui package.

Describe the solution you'd like
- Need to be able to output code for Node (during SSR) and the browser (for React components)
- Need to generate .d.ts?

• Esbuild and SWC cannot do that, and won't do that, because that's a slow heavy operation.
  However, we could generate those files only when publishing the package on NPM, or by hand. Sadly, I failed to find the right command with tsc or ts-loader. See Generates corresponding .d.ts file swc-project/swc#657

Describe alternatives you've considered

SWC

Next.js is backing SWC, so it's expected to have a lot of updates.

Be careful that SWC is a parser, so a replacement to Babel, not to Webpack. They are building "SWCpack" for this purpose but it's not there yet.

Dumping Babel may have some consequences, see vercel/next.js#30174, as SWC doesn't support all packages yet and have a smaller ecosystem.

It proposes a Webpack loader => great for fast setup by replacing babel-loader.

We need to figure the .d.ts generation thing.

Esbuild

Seems to work ok, very fast. But since Next is preferring SWC, that is written in Rust (Esbuild is in Go, so great language but less relevant for a build tool), we might go the Next.js way.

Not completely sure how it replace Babel/Webpack. But I am sure it doesn't correctly support .d.ts either: evanw/esbuild#95

Additional context
Add any other context or screenshots about the feature request here.

[eric-burel]

This article describe an alternative, using TypeScript "build" option. Maybe it could help getting rid of Babel and Webpack? Or at least improve our Lerna workflow: https://betterstack.dev/blog/lerna-typescript-monorepo/

[eric-burel]

About the Express starter

• Esbuild register currently lead to some issues with dependencies with weird exports: feat: esm format egoist/esbuild-register#12

Converting "require" to "esm" is currently not supported
{
  column: 27,
  file: '/code/vulcan-npm/starters/express/.yalc/@vulcanjs/mongo/dist/index.js',
  length: 7,
  line: 36,
  lineText: 'var import_merge = __toESM(require("lodash/merge.js"));',
  namespace: '',
  suggestion: ''
}
Converting "require" to "esm" is currently not supported
{
  column: 19,
  file: '/code/vulcan-npm/starters/express/.yalc/@vulcanjs/mongo/dist/index.js',
  length: 7,
  line: 37,
  lineText: 'var import_utils = require("@vulcanjs/utils");',
  namespace: '',
  suggestion: ''
}
Converting "require" to "esm" is currently not supported
{
  column: 30,
  file: '/code/vulcan-npm/starters/express/.yalc/@vulcanjs/mongo/dist/index.js',
  length: 7,
  line: 38,
  lineText: 'var import_mongoose = __toESM(require("mongoose"));',
  namespace: '',
  suggestion: ''
}

It's often an issue in the way we use the library (eg mongoose should maybe use import * as mongoose because it's default is not setup correctly), but still difficult to bypass

• TSC is not a bundler so it won't resolve local files correctly, it is not self-sufficient: Compiled JavaScript import is missing file extension microsoft/TypeScript#40878
• Tsup works the best as usual
• Esbuild-node-tsc did not work, however provided a nice tip with Nodemon: if the build is fast enough, and it is thanks to Tsup, you can add a build step to the nodemon reload:
  In nodemon.json:

{
  "watch": ["src"],
  "ignore": ["src/**/*.test.ts"],
  "ext": "ts,mjs,js,json,graphql",
  "exec": "yarn run build && node ./dist/app.mjs",
  "legacyWatch": true
}

[eric-burel]

Relevant thread on making the libraries tree-shakeable when they are rebuilt in the end user app (Next) and not just tree-shaked during the publication of the NPM package: egoist/tsup#578