Comment by reactordev | Hacker News Reader

Comment by reactordev | Hacker News Reader

This is great up until you get to the fact that typescript will not be accepted under node_modules [0].

That leads me to ask, what about project dependencies? I wrote a lib for my data models in typescript and I want to import that into my app in node, in typescript? Does the rule only apply to npm packages? There’s opportunity here…

I wrote a runtime in golang that runs typescript (well, JavaScript in general). The grafana folks have sobek that all they need is to add type striping. I feel like if there’s one runtime where typescript could be adopted fully and it would change the world is Node.js. No transpiler, no typescript-go, no rust (well, maybe some rust ;) just a great parser that will keep track of the source map and types in debug mode (for tracing).

Either way, kudos to the node team, contributors, for pulling in the goal posts to make the kick to launch shorter. I’m still a fan of bun, and my own runtime, but node is the standard by which we all are kinda following. I also like that the embedding api is simple and clean to use now so if you want to make an executable, you can.

[0] https://nodejs.org/api/typescript.html#type-stripping-in-dep...

I made the same comment here https://news.ycombinator.com/item?id=44931575

"To discourage package authors from publishing packages written in TypeScript"

I tried to use it with private packages but that doesn't work either, apparently node doesn't even read the "private" field.

It’s a missed opportunity for sure

"Written only in TypeScript" might put it better. If your module ships TypeScript source and a JS build as it should, then this will never affect it. Otherwise, to support stripping arbitrary modules would immediately compromise the design goal of light weight, due to the torrent of ill-founded and -formed bug reports incorrectly raised on Node that would follow. ("Don't make the maintainers' lives too miserable to continue the work" being also of course an implicit goal.)

Why would I want to ship a JS build for my private package? That's just extra machinery I don't need. Switching to a superior runtime would be easier.

Well, I don't suppose I know, but if it's an argument you want then that's actually room 12a just next door.

I can sort of understand the publishing argument, since npm doesn't solve for this at all, unlike JSR:

"You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility."

Not allowing it for private modules doesn't make much sense to me, though. It either forces me to use a loader, or now figure out a JS build step which I have been more than happy to avoid up until now.

The implication is that the capability is implemented to conditionally allow, which I suspect has been deliberately avoided, less because the change would require much technical effort (though it might; I don't know) than because the PR to make it offers another opportunity to keep that door nailed firmly shut.

As a past and present module author, I don't feel myself unduly burdened by the need to maintain the tooling to support the work I publish. Or present-ish, anyway; last time around it was Bower and about Node 8, and the experience these days is worlds more comfortable.

I can see why others would feel differently, but again, I'm not really here to argue preferences. If you'd like to fill your afternoon instead with an enjoyable, on-theme read, try the UNIX-HATERS Handbook: https://web.mit.edu/~simsong/www/ugh.pdf

Compile the packages to JavaScript before publishing. We absolutely should but be publishing TypeScript to npm.

I can understand the argument, since npm has no solution for TypeScript packages, unlike JSR:

"You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility."

Still would have been nice to have this for private packages.

This makes Deno/Bun much more attractive alternatives

JSR does that? Now that might be a good reason to move my packages over to get rid of tsup.

As an additional compat dist? Maybe. Otherwise, just leave TS as-is. It simplifies debugging and would allow things like static Hermes to work.

Reply on news.ycombinator.com