Live data from Hacker News

Node.js is able to execute TypeScript files without additional configuration

nodejs.org

261–270 of 275 posts

Re: Node.js is able to execute TypeScript files without additional configuration

#261
post #253

Earlier quoted context omitted.

Am I? My comment was 7 words suggesting consideration for Deno 2, responding to a 7-word comment suggesting to use Bun.

It was a collective you, applying to the parent post as well.

That's... weird. And kind of hypocritical, given the quality of your own comment which (a) mentioned downvotes and (b) used a few more words that boil down to "module protection". At this point I'm not exactly elevating the conversation either, for which I apologize. But I do think brief comments like mine and the one I replied to are perfectly fine.

Re: Node.js is able to execute TypeScript files without additional configuration

#262
post #231

Earlier quoted context omitted.

Using it as a precommit hook in OSS projects makes it so that people can write code however they want. But it ends up in the repo following the guidelines of the repo. Minimizing unnecessary back-and-forth with PRs. Extremely useful in my opinion. Even though prettier has defaults, but they can be modified to quite some extent to suit your projects needs: https://prettier.io/docs/options

> Using it as a precommit hook in OSS projects makes it so that people can write code however they want. That is the point of a formatter, so any formatter would do that (and there were many more active projects to allow formatting before prettier came around). > quite some extent Not really, and I have written prettier plugins to get around that constraint. IMO, its not great, which is kind of how things work out wh…

> That is the point of a formatter, so any formatter would do that (and there were many more active projects to allow formatting before prettier came around).

No arguments here. You are free to choose the formatter you want.

> Not really, and I have written prettier plugins to get around that constraint.

Or you could simply use those better formatters you were talking about.

Re: Node.js is able to execute TypeScript files without additional configuration

#263

Earlier quoted context omitted.

I switched to deno for new projects ~1 year ago and it’s only been joy. There’s a shockingly small amount of friction to switch over, and there are so so many benefits

I have only one issue I've encountered with Deno that mattered (so to speak) and it's probably my fault. I actually created an issue for it ( https://github.com/denoland/deno/issues/30433 ). My project config is weird (slightly more sophisticated that my repro), so, it's probably on me. Otherwise I absolutely love Deno. It makes TypeScript simple and joyful. It's the simplicity this language/tooling ecosystems badly…

Huh, turns out it's a real bug in node resolution: https://github.com/denoland/deno/issues/30444

Re: Node.js is able to execute TypeScript files without additional configuration

#266

Earlier quoted context omitted.

Package and environment management are both pretty commonly brought up.

I work with Node every day, and the library ecosystem is a nightmare. Just keeping a project from falling apart takes a huge amount of effort. Libraries are either abandoned when the author moves on, or they push major releases almost every month. And there’s a new CVE practically every week. Python libraries are much more stable and reliable.

> the library ecosystem is a nightmare I agree.

> Just keeping a project from falling apart takes a huge amount of effort I think the culture of importing libraries with lots of dependencies is a big contributor.

> Libraries are either abandoned when the author moves on This applies to any OSS project. Generally speaking popular abandoned libraries get forked.

> or they push major releases almost every month This sounds like a very bad library to use. I would not recommend having this type of library as a dependency in Node or even in Python for that matter.

> Python libraries are much more stable and reliable. Not sure what would make python libraries magically more stable and more reliable. Maybe libraries with minimal dependencies would could be the reason. That is why I recommend 0 or minimal dependecy libraries for node.

Re: Node.js is able to execute TypeScript files without additional configuration

#267
post #140

Earlier quoted context omitted.

This is great to hear, but perhaps comes too late for people like myself. Node.js has been by go-to platform from around 2014 until last year. But around September last year, I found myself thrust into the .NET ecosystem (due to a client project). Within a few months, I realized that it too, had finally become usable by default (unlike the last time I tried it, when it was too tightly coupled to Windows). In fact, it…

Eh the focus on OOP is my main issue with it. It’s not my style in that sense.

F# is a great FP language that runs on .NET and there's a growing field of FP proponents working in C#, sort of a Trojan Horse situation trying for a best of both worlds (easy onboarding for C# junior devs, but deep FP options thanks to things like C#'s clever LINQ syntax). LanguageExt is a big part of some of those ecosystems: https://github.com/louthy/language-ext

Re: Node.js is able to execute TypeScript files without additional configuration

#268

Earlier quoted context omitted.

This. It's 2025 and the node ecosystem is finally usable by default! ESM modules just work with both Node and Typescript, Node can run .ts files, and there's the a good enough test runner built in. --watch. The better built in packages - `node:fs/promises` - are nice with top-level await for easier async loops. It took a while to convince everyone involved to just be pragmatic, but it's nice now.

What's the story with supporting CommonJS libraries? I've tried to update many projects to ESM multiple times over the years, and every time, I ended up backing out because it turned out that there was some important upstream library that was still CommonJS - or even if we fixed those issues, our downstream NPM consumers wouldn't be able to consume EJS. So then you have to go down this rabbit hole of dual compilation…

With "type": "module" there's very few reasons to do dual compilation unless you have very conservative downstreams that hate promises and async/await, and even then there's mitigations now (sync `require()` of async ESM).

It's been a while since I've had a trouble importing an upstream CommonJS library. Often it is easy enough in the rare cases where upstream is particularly old/gnarly you can vendorize an ESM build with rollup or esbuild.

That said, CommonJS is also now a strong maintenance signal for me and if a library doesn't have recent ESM builds I start to wonder if it is at all well maintained and not just a pile of tech debt to avoid. JSR has started becoming my first place to search for a library I need, ahead of NPM, because of JSR's focus (and scoring systems) on ESM first and good Typescript types.

Re: Node.js is able to execute TypeScript files without additional configuration

#269
post #62

Earlier quoted context omitted.

does it have a go fmt / lint command yet?

jslint/tslint are an install away.

tslint has been deprecated for quite a long time now - from 2019: https://github.com/palantir/tslint/issues/4534

Re: Node.js is able to execute TypeScript files without additional configuration

#270
post #2

It looks like this works by stripping away the type information, so at best it saves you a transpilation pass and doesn't improve safety.

Yes, it can't parse enums, for example.

I think enums are on their way out, and erasable syntax is one of the main reasons.

https://dev.to/ivanzm123/dont-use-enums-in-typescript-they-a...

They added an optional flag to disable enums (and a few other features) in 5.8

https://www.totaltypescript.com/erasable-syntax-only

Post reply on HN