Ts-node: Swc support for faster transpilation

[cspotcode]

I just wanted to drop this on the radar in case you hadn't seen it. swc is a transpiler written in Rust that's an order of magnitude faster than those written in JS.
https://swc-project.github.io

On the one hand it seems out of scope for ts-node.

On the other hand, people turn to ts-node when they want to run TS code without pre-compilation. It handles all the details: sourcemaps work, your tsconfig is respected, etc. If ts-node had a --useSwc mode that made it an order of magnitude faster (with caveats) I think people would find that very useful.

I imagine that the hypothetical --useSwc flag is invalid unless --transpileOnly is also specified. Or --useSwc implies --transpileOnly. swc can't perform typechecking.

[blakeembrey]

That does look useful. I also see https://github.com/swc-project/swc/issues/126. I wonder if it makes sense to have something more generic than ts-node for this sort of thing. E.g. node -r swc/register. With the way things are moving, it might be preferable to use a light-weight transpiler at runtime and compile time, and only use tsc for type checking with noEmit enabled.

[cspotcode]

I'm very skeptical that swc will ever be able to perform typechecking.
Just feels way too complex an undertaking.

I agree that a very lightweight compiler for dev and runtime is awesome.
tsc --noEmit can be moved to the test suite. Shameless plug: I threw
together tsc-to the other day. It's like tsc but skips typechecking.

I think the missing piece for TS developers is: automatically generating
swc configuration from our tsconfig, e.g. grabbing the correct react pragma
and approximating the "target" flag. Whether that lives within ts-node or
swc, I'm not sure. But it'd be really cool if a TS dev didn't have to
think much about it.

I don't think swc's compilation flags map one-to-one with tsconfig.
Decorators won't work the same. Swc offers more granular control than TS's
"target"

On Mon, Feb 11, 2019, 1:05 AM Blake Embrey <[email protected] wrote:

That does look useful. I also see swc-project/swc#126
https://github.com/swc-project/swc/issues/126. I wonder if it makes
sense to have something more generic than ts-node for this sort of thing.
E.g. node -r swc/register. With the way things are moving, it might be
preferable to use a light-weight transpiler at runtime and compile time,
and only use tsc for type checking with noEmit enabled.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/TypeStrong/ts-node/issues/779#issuecomment-462226822,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAW-uLN0XuAWW-X6u8W0qgKFnaB-5kkeks5vMQg8gaJpZM4azaRj
.

[cspotcode]

I did a bit more poking around. swc isn't ready for primetime; I filed a few issues: https://github.com/swc-project/swc/issues/created_by/cspotcode

Hopefully it will be soon!

[wclr]

@blakeembrey
In TS 3.4 they also added incremental flag and option to speed up sequential builds, not sure if it affects ts-node buids?

[Suyashtnt]

any updates?

[cspotcode]

@suyashtnt marked as "help wanted" to indicate this will likely require an external contribution, a PR. Also "research" since they will need to figure out if SWC has fixed all their TypeScript bugs and figure out how to parse tsconfig files, converting them to SWC compiler flags.

[Brooooooklyn]

deno has used swc as their TypeScript compiler under --no-type-check flag.

[Brooooooklyn]

how to parse tsconfig files, converting them to SWC compiler flags.

Like this https://github.com/Brooooooklyn/swc-node/blob/master/packages/register/register.ts#L73 ?