101–110 of 275 posts
Earlier quoted context omitted.
Which is why the title is "Node can now execute Typescript files" and not lint, check, or even run TypeScript files.
I'm not sure what the distinction between "execute" and "run" is; is there a difference?
This will unfortunately drive people towards using TS only as a linter, and not use its powerful features that are inherently impossible to implement with just type stripping.
I’m not a heavy JS/TS dev so here’s an honest question: why not use Bun and forget about node? Sure I understand that not every project is evergreen but isn’t Bun a much runtime in general? It supports TS execution from day 1, has much faster dependency resolution, better ergonomics… and I could keep going. I know I’m just a single data point but I’ve had a lot of success migrating old node projects to bun (in fact I…
Node has its share of flaws, but it's the de facto baseline against which things are tested and developed. I'm somewhat more comfortable working with The Main Thing.
The JavaScript ecosystem is nightmarish enough that many developers don't want to switch to the Next Cool Thing. I think many of us have had enough fatigue caused by new build tools, new bundlers, new runtimes, etc.
As of right now, Bun is not compelling enough for the potential headaches down the line.
(Maybe there won't be any, but I've spent weeks dealing with incompatibilities caused by a single TS minor update (which should've been breaking). Days chasing after dependency problems, after missing docs, etc.)
I think this + node:test makes Node.js a pretty compelling sensible default for most things now. Running things with `tsx` was such a QoL improvement when it happened, but it didn't solve everything. Runtime type assertion at the edges is mostly solved through `zod` and tools like `ts-rest` and `trpc` makes it so much easier to do full-stack Typescript these days.
I'm very much in favor of TS support directly in node. vitest has made it easier these days, but I've lost too much time over the years getting the balance just right when configuring test environments for .ts files. trpc and ts-rest are a different animal in my opinion. I'm happy to use either one but won't deal with them in production. For trpc that's mainly due to the lack of owning API URLs and being able to more…
Earlier quoted context omitted.
> A typescript compiler does not generate code Except for where it does: Enums, namespaces, parameter properties, etc.
This is true but these are also old features, and the TS team have stated that they will not add any more features like those, and to a certain extent regret adding them initially (particularly decorators, which iirc were added because the Angular framework wanted to use them). You can also see that these features aren't really being updated to match recent Typescript developments (parameter properties can't do true…
How useful is it exactly that you accept to not use DX improving syntax like constructor properties, enums, etc? To me, someone who uses these features _a lot_, this would be a terrible trade. Seems more like people push this out of ideology and because TS is never going to be part of node itself (since its implementation is just way too slow)
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.
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.
>so at best it saves you a transpilation pass and doesn't improve safety. That's a bit misleading. Node being able to run TS code does not "improve safety", because that's not where the type checking happens. You can do type checking in your editor, or various other points in your toolchain. Node being able to run TS code reduces the friction in writing TS code, which indirectly helps with type safety.
That just doesn't make sense. Yes, you can wait for your editor in your current open file, if you are lucky and the change in the open file doesn't break anything downstream in another file that is not yet open. In best case you have such simple code that nothing breaks, and in worst case, you have to still run it with type-checking - on top of running it in type-stripping-mode, because you got weird errors in runtime. This is a net negative.
This whole situation is there because we are trying to workaround the slow TSC. It's not a feature, it's something we actively work around. We try to whitewash now the obviously less useful "solution" of running code without its core features enabled: type checking. To me this is insane.
Earlier quoted context omitted.
I'm not sure what the distinction between "execute" and "run" is; is there a difference?
Node is just inline transpiling the TS into JS, then running the JS.
Very well done Node team!
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.
Not needing a separate compile step just to run some script sounds great to me. I will run tsc if I want a type check.
I think running TS without type checks is almost entirely pointless.