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.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[JakobJingleheimer]

Perhaps a topic for the collab summit in September? Loaders might be stable by then, so our team might have bandwidth to move this forward.

[GerbenRampaart]

Can I ask what the current standing on this issue is from the core team?

I'm just any old nodejs lurker who has been using it for a decade so I don't really want to give my opinion but I am fishing for an updated opinion from the core collaboration team.

The whole Bun storm has not gone unnoticed to most of you probably and while Bun is not there yet, their message is clear; replace node. They literally say this.

While anyone can argue that the popularity is caused by it's speed optimizations or because 'it's something new', another big pillar for Bun is running typescript out of the box (in other words; it carries the transpiler with it in the runtime).

I have serious projects, with lots of code, running big frameworks such as nestjs, that I can run without a transpile step using Bun.

While that makes me excited about javascript's future, it also makes me worried a bit about nodes future.

[JakobJingleheimer]

I was championing this, but I had to pause contributing to node (too much going on IRL).

Currently, you totally can use TypeScript in node via a simple loader like https://github.com/JakobJingleheimer/nodejs-loaders (tsx-loader). Takes seconds to set up.

In terms of nodejs handling this robustly and automatically, there was a generally accepted plan, and then as implementation started, it ran into a wall of "well actually, how about"s. AFAIK, there's been some chatter here and there since then, but it hasn't moved. I'm hoping to find out next week whether my IRL distractions have resolved, so I can pick back up with node.

[GerbenRampaart]

Does it stagnate on the generality issue?

What I mean is that vendorizing typescript alone does not feels right, and we need an inclusive solution to also support flow and babel and so on?

Because I feel that ship has sailed a good while ago. It's fine to support just typescript.

[JakobJingleheimer]

Vendoring it is not on the table ;)

The planned implementation was agnostic: You could use babel, esbuild, swc, ts-node, or whatever else works.

[shinebayar-g]

Hi guys, latest update from NodeJS team is at #43818 (comment)
I also created a thread on Typescript project here microsoft/TypeScript#56838
There are some response from Typescript team. I'm trying to advocate and gain some visibility into this issue, but haven't been able to convince anyone seriously.