TypeScript Support

[avin-kavish]

What is the problem this feature will solve?

With TypeScript becoming ubiquitous these days, and alternative js runtimes presenting TypeScript support as a value proposition to users, I think it would be good for node.js to support it out of the box too.

Currently, users have to explicitly run ts-node to run ts files without a pre-compile step. This only applies to the main process, programs that spawn processes that need to run TypeScript also have to require ts-node. ts-node by default doesn't use the optimized transpilers like swc that have popped up recently. There's further configuration to do to get that speed boost.

It's more ergonomic when the runtime supports typescript without configuration.

What is the feature you are proposing to solve the problem?

Include a typechecker + transpiler in node.js that'll activate when .ts files are loaded.

What alternatives have you considered?

No response

[MoLow]

using ts-node as a esm loader (or any other transpiler) is supposedly the standard way to do this now.

[MoLow]

@avin-kavish have a look at #43818 discussing this

[JakobJingleheimer]

Indeed what you're asking for is easily achieved at this moment with a loader:

node --loader ts-node/esm app.ts

ts-node reads from a number of configuration files. Opting into swc is a set-and-forget config option for ts-node.

As I understand it, ts-node also handles carrying over the loader & config to spawned processes and threads.

As a litmus test, I just did this last night, and it took me ~30 seconds to get everything set up.

[mcollina]

All our unofficial conversations with the TypeScript team pointed out that vendoring TypeScript (or any other TS transpiler) would be a bad idea. Node.js offers a long LTS cycle that TS does not cover.

[avin-kavish]

@JakobJingleheimer

I don't agree that it's the same. Especially for new devs being onboarded in to the eco-system. Alternate runtimes provide a first-class experience. It's like starting to code with TypeScript as opposed to learning js --> chosing typescript --> learning concepts like transpilation -> learning how to maintain your ts tooling.

And for me also, there's a baseline overhead when starting a new project in node.

[JakobJingleheimer]

True, it's not exactly the same.

I see two options:

• Contribute this bespoke integration with typescript. I estimate it would take you at least 50 hours for the initial implementation (and then subsequent maintenance). Feel free to ping me on specific questions, and I'll try to point you.
• Use a loader with the CLI arg (this is already possible). One does not need to be aware of the transpilation at all to get it working (neither what it is nor that it's even happening), merely "I need to copy+paste this tiny thing and it JustWorks". This option will take you about 30 seconds one time.

On a related note: If you literally can't add that CLI arg or install npm packages in order to get ts-node (or similar), that's a different problem, and one I'd be happy to bring to the team 🙂

[cspotcode]

ts-node's experience is being cited in favor of loaders, but note that we have to hack around the loaders API in a number of ways.

Two examples from this thread:

ts-node reads from a number of configuration files.

This is complicated by the fact that loaders do not give us information about the entrypoint. Our CLI makes it easier because we control the entrypoint, but then we have to spawn a child process (ew). I think #43408 might improve the situation.

ts-node also handles carrying over the loader & config to spawned processes and threads.

This is a hack done in spite of the loaders API, by working around it.

Point being, there's a lot that needs to be done on node's end to make this experience better. Loaders are only one piece, and the ideal user experience may very well completely hide loaders as an implementation detail.

[JakobJingleheimer]

This is complicated by the fact that loaders do not give us information about the entrypoint. Our CLI makes it easier because we control the entrypoint, but then we have to spawn a child process (ew).

Sorry, I'm losing track of the myriad of redundant issues started this week discussing this.

We would happily expose more info for you and intend to provide helpers so you don't need these hackarounds: nodejs/loaders#94 I'm very motivated to ease this difficulty. As soon as we nail down the design, it's next on the list 🙂

[cspotcode]

Same feeling here, too many issues, and there's always the chance we'll be told to stop talking about something in the wrong thread. :D

I don't think helpers is quite solving the entrypoint problem, though.

I've already voiced some concerns on the helpers thread. I was told some were off-topic, but the fact that they've been brought up here is, I think, good justification they're on-topic. Perhaps we can circle back.

There are a variety of API gaps in node, I posted an incomplete list over here:
#43818 (comment)

Some are in loaders, some are elsewhere, and some might be addressed by the new entrypoint hooks proposal in #43408. So I'm interested to see where that goes.

[JakobJingleheimer]

some might be addressed by the new entrypoint hooks proposal in #43408

Ugh, I missed that one. I'll try to get to it this weekend. I have 242 messages for Node.js to read/action on 😭 at least it's a nice symmetric number.

[GeoffreyBooth]

Let’s please tag anything related to TypeScript with loaders, and ping @nodejs/loaders. Whether or not the solution eventually involves loaders, today’s solutions all involve loaders, and it’s likely the same team will be involved.

[GeoffreyBooth]

I’ve already voiced some concerns on the helpers thread. I was told some were off-topic, but the fact that they’ve been brought up here is, I think, good justification they’re on-topic. Perhaps we can circle back.

Re the helpers, the goal with that thread is at first to expose parts of the internal Node resolution and loading flows to make replacing them less boilerplate-y. These won’t be the last helper/utility functions we create. It’s just not part of that initial effort. If you’d like to start a design doc with other helpers/APIs for other parts of integration, that would be great.