Ts-node: Differences between ts-node and @babel/register + @babel/preset-typescript ?

[trusktr]

I'm curious to know what are differences between ts-node and @babel/register + @babel/preset-typescript. Any insights would be greatly appreciated!

I can start with a few:

• ts-node supports all TypeScript language features, while @babel/preset-typescript does not support namespaces and inline modules.
• ts-node supports various Ecmascript language features out of the box that otherwise extra babel plugins are needed for on top of @babel/preset-typescript (f.e. @babel/plugin-proposal-object-rest-spread)
• ts-node can do type checking while transpiling, while @babel/preset-typescript only strips type information and requires you to check typing separately.

What are more technical differences or similarities in the implementations? For example how does caching differ, performance differences between transpileOnly and Babel's, etc?

[blakeembrey]

I haven’t really used Babel in years now so I couldn’t give a useful response here. In general, I would hope they act similarly aside from being different compilers. Of course, by being different compilers that means the emit will likely be much different. And if the emit output is different, you probably only want to be using the Babel CLI if you’re also using the compiler. Otherwise you’ll encounter differences one day. If using the Babel compiler down the entire stack, I’m guessing you’d be using TypeScript only for type checking.

[harrysolovay]

Wishing there was more in this thread. I’m super interested in knowing the differences! Anyone out there able to provide more info?

[blakeembrey]

What exactly would you like to know? Most of the high level seems clear, and the rest probably comes down to “what’s the difference between Babel and TypeScript”? This CLI is super straightforward and does have caching, I believe the caching is pretty similar to Babel (though caching will be retired because it isn’t a huge improvement and created buggy edge cases for TypeScript type checking).

[harrysolovay]

@blakeembrey some more low-level details please :) It seems like they both highjack the require statement. They both need to transform ASTs. Both only transform the tree of imported/required files.

I'm trying to wrap my head around the details because it's a great project and I'd like to learn from it. But I'd imagine there are other people who want more details to better evaluate whether this is the right fit for their projects. Performant on-the-fly compilation seems almost too good to be true! Any more details you can give would be greatly appreciated 💯

[kachkaev]

I've been user of ts-node for a while and I love it a lot as it lets me execute .ts files straight away without messing up my development process. Having no build scripts or temporary JavaScript files when doing simple stuff rocks. One thing that's a bit painful though is the ts-node warming-up time, which is about 2-4 seconds for each call to ts-node (I have not bothered to collect the exact stats). This performance imperfection makes the biggest difference during fast development cycles and if a command like ts-node script/do-a-b-c.ts is used in CI. Three seconds times 5-10 CI tasks slows down things considerably and build up into hours of pipeline time over months. This is not critical, but a little bit irritating.

I just came across this tweet, which brought me into the ts-node repo:

If stripping typings via babel can be quite fast and typescript checking can done by calling tsc --noEmit anyway, could ts-node leverage babel instead of tsc and thus perform a bit quicker? Is there any theoretically possibility for this at all? 🤔

[blakeembrey]

Why wouldn’t you use transpile mode today? That’s how it works today, but with the TypeScript compiler instead of Babel.

[kachkaev]

@blakeembrey could you please elaborate?

My comment was suggesting that babel may be faster these days than tsc, which may help with slow warp-up times.

[blakeembrey]

Based on your comment you are using this module for both type checking and transpilation. You suggested that you could split it into type checking with TypeScript directly and transpilation with this module. I’m informing you this is already possible and would indeed improve your warp-up times. It just doesn’t use the Babel compiler.

[kachkaev]

Oh. Do you mean --transpile-only flag? I just discovered it and it looks like this is what I need! 🎉