Repository navigation
TypeScript Support #43816
Description
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
Activity
MoLow commentedon Jul 13, 2022
using
ts-nodeas a esm loader (or any other transpiler) is supposedly the standard way to do this now.MoLow commentedon Jul 13, 2022
@avin-kavish have a look at #43818 discussing this
JakobJingleheimer commentedon Jul 14, 2022
Indeed what you're asking for is easily achieved at this moment with a loader:
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 commentedon Jul 14, 2022
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 commentedon Jul 14, 2022
@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 commentedon Jul 14, 2022
True, it's not exactly the same.
I see two options:
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 commentedon Jul 14, 2022
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:
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.
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 commentedon Jul 14, 2022
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 commentedon Jul 14, 2022
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 commentedon Jul 14, 2022
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 commentedon Jul 14, 2022
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 commentedon Jul 14, 2022
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.
11 remaining items
GerbenRampaart commentedon Jan 25, 2024
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 commentedon Jan 25, 2024
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 commentedon Jan 25, 2024
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 commentedon Jan 25, 2024
Vendoring it is not on the table ;)
The planned implementation was agnostic: You could use babel, esbuild, swc, ts-node, or whatever else works.
MickL commentedon Jan 25, 2024
keenwon commentedon Jun 19, 2024
Just a note: ts-node hasn't been updated for over six months, and currently it has issues running on node v20.
silverwind commentedon Jul 17, 2024
Related PR: #53725
silverwind commentedon Jul 24, 2024
I'd say this is fixed with 35f92d9.
telmotrooper commentedon Jul 26, 2024
@keenwon You might want to give tsx a go.
Hacksore commentedon Jul 26, 2024
FWIW
tsxoffers no typechecking so if you have type errors it will just ignore them.https://tsx.is/typescript#type-checking
privatenumber commentedon Aug 14, 2024
Same with Node's new
--experimental-strip-types, Deno, and ts-node with SWC.marco-ippolito commentedon Oct 7, 2024
experimental typescript support landed in https://nodejs.org/en/blog/release/v22.6.0