Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider about using swc as JS/TS transformer #788

Closed
Brooooooklyn opened this issue Sep 7, 2020 · 5 comments
Closed

Reconsider about using swc as JS/TS transformer #788

Brooooooklyn opened this issue Sep 7, 2020 · 5 comments

Comments

@Brooooooklyn
Copy link

Brooooooklyn commented Sep 7, 2020

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
Copy link

kdy1 commented Sep 7, 2020

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
Copy link
Contributor

remorses commented Oct 13, 2020

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
Copy link
Member

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: Support the esbuild plug-in system? evanw/esbuild#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
Copy link

evanw commented Oct 28, 2020

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.

@axe-me
Copy link
Contributor

axe-me commented Mar 11, 2021

you can write a simple plugin if you really want to use swc for ts transform.
https://github.com/axe-me/vite-plugin-node/blob/main/src/rollup-plugin-swc.ts

@github-actions github-actions bot locked and limited conversation to collaborators Jul 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants