TypeScript Support - Githubissues

avin-kavish commented 2 years ago

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 commented 2 years ago

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

MoLow commented 2 years ago

@avin-kavish have a look at https://github.com/nodejs/node/issues/43818 discussing this

JakobJingleheimer commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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: https://github.com/nodejs/node/issues/43818#issuecomment-1184415188

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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[bot] commented 1 year ago

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.

MickL commented 1 year ago

What bothers me the most is that it is not possible to create and publish a pure TypeScript npm package that can only be used in TypeScript projects and has not been compile to JavaScript.

aduh95 commented 1 year ago

What bothers me the most is that it is not possible to create and publish a pure TypeScript npm package that can only be used in TypeScript projects and has not been compile to JavaScript.

That's not something that Node.js can change, this issue is about adding (some kind of) support for the existing TypeScript ecosystem out of the box in Node.js, not to discuss modifications that could be done to said ecosystem.

github-actions[bot] commented 1 year ago

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 commented 1 year ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

Deno comes with integrated TypeScript support AND linting aswell. It just runs without a build step and without configuration. What a redemption coming from Node!