Use swc / ts-node instead of babel

[cspotcode]

I'm sending this PR to get a second opinion on these changes and to show that tests are passing. But if it's not merge-able, I think we should close it to keep the PR queue tidy.

What's the problem this PR addresses?

Slow developer experience working in berry's codebase due to babel.

How did you fix it?

Switched to an experimental ts-node swc compiler. ts-node loads configuration from tsconfig.json like usual. It is configured to use an experimental swc compiler, where we configure swc to match your tsconfig flags.

3x modes are possible: ts-node with caching, swc without caching, and swc with caching. Additionally, setup-ts-execution.js supports an env var to switch back to the babel compiler.

Most of this switching complexity is meant to be removed if/when berry officially switches to ts-node or swc.

swc does not elide type-only imports unless they are import type. So I also added import type where necessary, and added the necessary tsconfig flag to enforce this when typechecking.

All releases are marked "decline" because I don't think these code changes affect the published packages. Unless they affect the emitted .d.ts?

I had to forcibly add the native bits of swc in .yarn/unplugged for tests to pass. Is there a better way?

Issues uncovered while testing

• Wrong codegen for computed class properties when using TypeScript swc-project/swc#1122
• Wrong optional call expression emit when target < 2020 swc-project/swc#1136
• Broken codegen of class with decorated method when using jsc.module.lazy swc-project/swc#1135 We don't use decorators anymore
• swc uses _interopRequireDefault when it should use _interopRequireWildcard swc-project/swc#1786 (optional, has workaround)
• swc reuses _variable name when importing different modules with same filename in CommonJS swc-project/swc#1787
• Does not transform ||= "logical or assignment" operator swc-project/swc#1788
• Doesn't export the default value when interopRequireDefault is applied swc-project/swc#1790
• tiered WebAssembly compilation broken nodejs/node#36616

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[cspotcode]

The plugin-compat failure is unrelated to these changes; looks like it's failing across the board due to changes in ts 4.2 dev builds.
cspotcode#2

[merceyz]

Some context:

@paul-soporan looked into using swc earlier and found some bugs that needed to be fixed first https://github.com/swc-project/swc/issues?q=is%3Aissue+author%3Apaul-soporan+

@arcanis looked at using esbuild for bundling Yarn but it also has a transpile only function that is also an option I suppose https://esbuild.github.io/api/#transform-api

I had to forcibly add the native bits of swc in .yarn/unplugged for tests to pass. Is there a better way?

We looked at using their WASM version instead as native isn't really an option due to things like #1939

[cspotcode]

I see there's one bug remaining, specifically pertaining to the "lazy" option of swc. Does yarn currently use a lazy-equivalent behavior? In case it gets lost in the swc discussion, I want to point out this PR *also* includes an implementation that doesn't use swc. It seems to outperform babel in the common case of editing one or two files and rerunning.

…

On Thu, Dec 10, 2020, 3:05 AM Kristoffer K. ***@***.***> wrote: @paul-soporan <https://github.com/paul-soporan> looked into using swc earlier and found some bugs that needed to be fixed first https://github.com/swc-project/swc/issues?q=is%3Aissue+author%3Apaul-soporan+ I had to forcibly add the native bits of swc in .yarn/unplugged for tests to pass. Is there a better way? We looked at using the WASM version instead — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2228 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OGRQDLOW2PD4S6PZKLSUB6M5ANCNFSM4UUM7BXA> .

[paul-soporan]

I see there's one bug remaining, specifically pertaining to the "lazy"
option of swc. Does yarn currently use a lazy-equivalent behavior?

I don't think there's any lazy-equivalent behavior at the moment (unless @babel/register happens to do some magic under-the-hood by default, but I doubt it), so the lazy flag for swc isn't important (I only opened the issue so that it can eventually be fixed). The important bugs have been fixed very quickly and swc is definitely usable.

[cspotcode]

Linking related swc tickets:

swc-project/swc#1787 This bug is a blocker

swc-project/swc#1786 not strictly a blocker, but it forces us to add a dependency on @swc/helpers in every package

swc-project/swc#1060 swc added ability to elide type-only imports without requiring import type, so I may be able to revert all the import type changes in this PR

[cspotcode]

Linking to another swc issue:

swc-project/swc#1788

[merceyz]

Found another bug swc-project/swc#1790, I updated the OP to contain the issues reported upstream

[cspotcode]

I think we're hitting nodejs/node#36616, specifically nodejs/node#36616 (comment)

I tried implementing caching in the ts-node swc codepath, but it was still slower than babel. Then I tried switching to @swc/core and it was fast, even though cache was being used for everything, so swc was never invoked! I now believe that merely loading @swc/wasm causes a ~4 second slowdown.

Other related issues:
nodejs/help#2823
swc-project/swc#1352

[cspotcode]

To reproduce the node bug above, do the following:

echo "require('@swc/wasm'); process.on('exit', console.log.bind(console, 'we should be terminated!')); process.exit()" | node

You will see "we should be terminated" immediately but will have to wait ~4 seconds till the process exits.

[arcanis]

@cspotcode I'll close this issue since we try to move the build pipelines to ESBuild (so it'd be ideal to switch the runtime to its compiler rather than swc), but we're still interested by the general idea of bringing local dev in sync with pre-built binaries!

[cspotcode]

Ok, sounds good. Truth be told I haven't had any time to attempt a fix for the underlying node / WASM issue we were hitting.