Vite: Reconsider about using swc as JS/TS transformer

[Brooooooklyn]

In early days, the performance of swc is much worse than esbuild (around 2 ~ 5x slower).

But recently, the author of swc landed many performance enhancements in swc project.

Now the performance of transform API is very close between @swc/core and esbuild: transform parallel benchmark results

Besides, swc have some advantages over esbuild:

• Support experimentalDecorators in TypeScript.
• Support @jsx pragma.
• Exposed transformer API, so community can customize transform plugin top on it jest-hoist-plugin.
• (Maybe) more users, deno is strongly dependent on swc (They are using swc in --no-type-check mode).

/cc @yyx990803 @kdy1

[kdy1]

As a side note, swc supports some typescript specific features like emitDecoratorMetadata which is important for some libraries and swc tries to be spec-compilant as much it can.

Also, starting from v1.2.23, which will be released within a week, swc will support @jsx pragma.
(It's already implemented, but not published yet)

[remorses]

I instead think we should stick with Esbuild, after it becomes more mature we could even replace rollup with esbuild in the final bundle step and have much faster builds

However you should be able to make a new plugin that uses swc to compile your ts and jsx files if you want

[yyx990803]

It's worth considering but esbuild is working just fine so the advantage must be somewhat significant to warrant a major refactor.

• TS decorators are out of sync with spec for a long time and IMO should really be avoided.
• Per-file JSX pragma is only needed when you use different JSX implementations in the same project, very rare and we can easily support that by checking the pragma from Vite and pass it on to esbuild.
• Vite don't really need a transformer API in the TS compiler, but esbuild also has a plugin/transformer API on the way: https://github.com/evanw/esbuild/issues/111

More importantly, esbuild is also a bundler so that provides potential cases where we can use esbuild in place of rollup (e.g. pre-optimizing deps).

Overall I don't consider it convincing enough to switch.

[evanw]

Support @jsx pragma.

FWIW esbuild has already supported this for a long time (since July, so before the original post). @jsxFrag is also supported to control what's used for the <>...</> syntax.