Without some kind of transformation on `enum` isn't this mostly useless? `enum` is heavily used in many TypeScript code-bases.
Node.js adds experimental support for TypeScript
231–240 of 570 posts
Re: Node.js adds experimental support for TypeScript
#232Nice, but without support for Enums, for me it's mostly useless.
In our codebase we started to disallow enums in favour of string literal types, and once folks get over the ingrained "this needs to be an enum" (coming mostly from other languages like Java), it's not much missed. Enums are one of the very few things in typescript that seem to not have turned out that well, but it's relatively easy to work without them with string-literable types and such, derived from some const in…
agree enums in typescript are the devil
Re: Node.js adds experimental support for TypeScript
#233Nice, but without support for Enums, for me it's mostly useless.
There are union types for strings; and there are plain javascript objects (typed as const) if "namespace.name" syntax is desired. With these available, what is the point of enums?
Namespaces are also not supported as per https://github.com/nodejs/node/blob/main/doc/api/typescript.....
I for one can can live without all these features and will be banning via eslint.
Re: Node.js adds experimental support for TypeScript
#234My favorite deno feature is coming to node directly. Awesome! Maybe this means I don't always have to install esbuild to strip types - very excited how this will make writing scripts in TypeScript that much easier to use. I lately have been prefering Python for one off scripts, but I do think personally TypeScript > Python wrt types. And larger scripts really benefit from types especially when looking at them again a…
btw if anyone is looking to run ts on node, there is tsx. there is also ts-node but i prefer tsx. https://github.com/privatenumber/tsx
Tsx’s only reset-in-console mode is , which makes it impossible to develop cli apps in watch mode.
You cannot run tsx from a non-project cwd if you’re using tsconfig/paths.
And personally I find its maintainers relatively unpleasant to message with. Leaves “you’re plebs” aftertaste most of the times.
Re: Node.js adds experimental support for TypeScript
#235Earlier quoted context omitted.
https://www.typescriptlang.org/docs/handbook/2/types-from-ty... https://www.typescriptlang.org/docs/handbook/2/template-lite... alone puts TS over anything that Java has.
> alone puts TS over anything that Java has. Virtual Threads alone challenge this assumption. Syntax bloat is not a feature.
It's not really a syntax bloat, the linked docs mention how to define strict string types and elaborate on type-level programming, something that is a very rare and powerful type-level capability.
As far as I understand Virtual Threads aren't type oriented feature, which is basically the context for this thread.
Re: Node.js adds experimental support for TypeScript
#236My favorite deno feature is coming to node directly. Awesome! Maybe this means I don't always have to install esbuild to strip types - very excited how this will make writing scripts in TypeScript that much easier to use. I lately have been prefering Python for one off scripts, but I do think personally TypeScript > Python wrt types. And larger scripts really benefit from types especially when looking at them again a…
Have you tried https://github.com/google/zx ?
This seems very interesting approach to scripting. Does it basically provides with an alias to child_process.exec as $ and besides that I can write in the same way I'd do in Node?
> Node.js standard library requires additional hassle before using
I read the hassle as having to setup Node runtime in advance, but zx requires npm to install so I'm not sure.
Re: Node.js adds experimental support for TypeScript
#237Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun run`). Meanwhile, I can’t configure node to not require extensions on import, nor have tsc configured to automatically add .js extensions to its compiled output, without adding on a bundler… although native TypeScript support would remedy this nit quite a bit,…
Isn't Bun too raw? It's built with Zig, which hasn't even hit 1.0.
Probably had to stay in the oven a bit longer...
Jokes apart, Zig is moving forward a lot which is why it's not 1.0 yet, but it doesn't mean you can't write safe and performant applications right now.
Zig is also a rather simple and straightforward language (like C) and has powerful compile-time code generation (like C macros, but without the awful preprocessor).
Re: Node.js adds experimental support for TypeScript
#238One thing to note is that it is impossible to strip types from TypeScript without a grammar of TypeScript. Stripping types is not a token-level operation, and the TypeScript grammar is changing all the time. Consider for example: `foo ( x )`. In TypeScript 1.5 this parsed as (foo (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo (x) which…
I'm not worried about that too much to be honest. To me beyond v4.4 or so, when it started being possible to create crazy recursive dependent types (the syntax was there since ~4.1 - it's just that the compiler complained), there weren't a lot of groundbreaking new features being added, so unless an external library requires a specific TS version to parse its type declarations, it doesn't change much.
> crazy recursive dependent types
Some edge-cases involving those have bugfixes and ergonomy improvents I've run into on 5.x.
Re: Node.js adds experimental support for TypeScript
#239Earlier quoted context omitted.
It’s an issue because node has a system of LTS releases, whereas TypeScript has quarterly updates, so the release cadence is different. Updating node is much more fraught than updating TypeScript. For example, it may break any native code modules. That’s why users are directed to use the LTS and not the most recent release, so that there’s enough time for libraries to add support for the new version. On the other han…
TypeScript feels "boring" enough at this point that being a few years behind isn't gonna be an issue in most cases. For teams who want to stay on the absolute latest release of TypeScript but want to be more conservative with their Node version, external compilation will remain necessary; but for someone like me, where TypeScript has been "good enough" for many years that I'm not excited by new TypeScript releases, t…
typescript is still evolving in dramatic ways. The 5.0 release has some really good improvements
Re: Node.js adds experimental support for TypeScript
#240It's interesting how TypeScript beat Flow in terms of popularity, and yet everyone is now calling for TypeScript to be more like Flow (to focus on plain type checking instead of transpilation; just strip out the type annotations)... And most of those people don't even know about the existence of Flow.
The sad thing about the tech sector is that you can be right about something and yet still lose the hype-wagon popularity contest. Then your competitor copies your original idea... The exact same idea which they had previously claimed was inferior.
It seems that the idea was inferior purely on the basis that it wasn't their idea. As soon as they've appropriated the idea, suddenly it's the best idea in the world.