Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js adds experimental support for TypeScript

github.com

Post reply on HN
Print view View original

441–450 of 570 posts

Re: Node.js adds experimental support for TypeScript

#441

Post by rlt »

pphysch wrote: post #39
pansa2 wrote: post #34

If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript - it could be used solely as a type checker. This would be similar to the situation in Python, where type checkers check types and leave them intact, and the Python interpreter just ignores them. It's interesting, though, that this approach in Python has led to several (4?) different popular…

> In Python, I've even heard of people writing types in source code but never checking them This is my main approach. Type hints are wonderful for keeping code legible/sane without going into full static type enforcement which can become cumbersome for rapid development.

I don't find TypeScript to be burdensome when rapidly iterating. Depending on how you've configured your dev environment you can just ignore type errors and still run the code.

Re: Node.js adds experimental support for TypeScript

#442

Post by Omerd6 »

unilynx wrote: post #370

If this feature ever becomes the default (ie not behind a flag) - how will the NPM ecosystem respond? Will contributors still bother to build CJS end EJS versions when publishing a NPM module, or just slap an 'engine: nodejs >= 25' on the package.json and stop bothering with the build step before pushing to NPM ? I personally would very much prefer if NPM modules that have their original code in TS and are currently…

The legendary Ryan dahl is actually working on solving the exact problem you described by creating a new package registry called JSR.

Essentially what it does is allow you to upload your typescript code without a build step so when other devs install it they can see the source code of the module in it's original typescript instead of transpiled JavaScript.

Re: Node.js adds experimental support for TypeScript

#443

Post by WorldMaker »

nfriedly wrote: post #426
WorldMaker wrote: post #424

Earlier quoted context omitted.

> I think if node.js had made require() work with ESM, I could probably drop CJS Why is making downstream have to switch to `await import()` that big of a deal? You can use async/await in CJS just fine. Sure, sometimes you may need to resort to some ugly async IIFE wrappers because CJS doesn't support top-level await like ESM does, but is that really such a big deal? Sure, it's a breaking change, but that's what semv…

> Why is making downstream have to switch to `await import()` that big of a deal? > You can use async/await in CJS just fine. Sure, sometimes you may need to resort to some ugly async IIFE wrappers because CJS doesn't support top-level await like ESM does, but is that really such a big deal? It might seem like a small amount of work, but for a library one must to multiply that small amount of work by the number of us…

> multiply that small amount of work by the number of users who will have to repeat it

This is probably where we have the biggest difference in our calculations. I know there's a lot of pain in legacy CJS systems, but from my view (which is maybe more "browser-oriented", which is maybe a bit more Deno/Bun-influences, which comes from a "Typescript-first" mentality going way back to 0.x) it is more legacy "giant balls of mud" maintained by a sparse few developers. I don't see this multiplicand as very big on the scale of library user count. Most CJS for years and years has been transpiled from Typescript or Rollup; most CJS only exists to be eaten by Webpack or other bundler, many of which today rewrite CJS to ESM anyway. From what I see a lot of CJS seems either transpiled out of habit (for some notion of supporting Node Of course, if your multiplicand is lines-of-code impacted, because I agree there are some great big huge piles of mud in CJS that are likely stuck that way for lack of developers/maintainers and lack of time/budget/money, then worrying about the minority of users still intentionally using CJS is worth caring about, and my sympathies in that situation.

You, of course, know your library's users better than me and maybe you do have a lot of CJS users that I just wouldn't consider in my calculations. I'm not going to stop you from transpiling to CJS if you find that necessary for your library. That's your judgment call. I just wanted to also make sure to ask the questions of "do you really need to?" and "how many users do you actually think it will impact?" out loud. Thanks a lot for the conversation on it, and I'm still going to be a radical banging the "CJS Must Die" drum, but I understand pragmatism and maintenance needs, especially those of legacy applications, and mostly just want to make sure the conversation is an active one and a lot less of passively transpiling stuff that doesn't really need it.

Re: Node.js adds experimental support for TypeScript

#444

Post by flanbiscuit »

afavour wrote: post #262
murmansk wrote: post #185

Earlier quoted context omitted.

[flagged]

I’ve had a lot of success combining JSDoc JS with .d.ts files. It’s kind of a Frankenstein philosophically (one half using TS and one half not) but the actual experience is great: still a very robust type system but no transpiling required. In a world where ES modules are natively supported everywhere it’s a joy to have a project “just work” with zero build steps. It’s not worth it in a large project where you’re alr…

I do this as well. JSDoc is great for simple definitions, but as soon as you want to do something more complicated (generics, operators, access types, etc) you get stuck. The .d.ts are ignored because you're only importing them within JSDoc comments.

Re: Node.js adds experimental support for TypeScript

#445

Post by FractalHQ »

dobladov wrote: post #303
rty32 wrote: post #245

Earlier quoted context omitted.

In general JSDoc is just much more verbose and has more friction, even outside complex types. I recently finished a small (20 files/3000 lines), strictly typed JS project using full JSDoc, and I really miss the experience of using the real TypeScript syntax. Pain points: annotating function parameter types (especially anonymous function), intermediate variable type and automatic type-only import, these are the ones t…

I use snippets to write those, yes it's more verbose there's not denying that. For me the advantages of just having JS files and not worrying about more complex source-maps, build files, etc definitely makes it worth it.

Source maps and build files are automatically generated when bundling which you need to do with or without typescript… so this argument always confuses me. There is no tangible downside in my experience.. either way it’s just typing “pnpm build”.

Re: Node.js adds experimental support for TypeScript

#446

Post by jitl »

felixfbecker wrote: post #403
zarzavat wrote: post #120

One 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 think the kind of teams that always stay on top of the latest TypeScript version and use the latest language features are also more likely to always stay on top of the latest Node versions. In my experience TypeScript upgrades actually more often need migrations/fixes for new errors than Node upgrades. Teams that don't care about latest V8 and Node features and always stay on LTS probably also care less about the l…

I work on a large app that’s both client & server typescript called Notion.

We find Typescript much easier to upgrade than Node. New Node versions change performance characteristics of the app at runtime, and sometimes regress complex features like async hooks or have memory leaks. We tend to have multi-week rollout plans for new Node versions with side-by-side deploys to check metrics.

Typescript on the other hand someone can upgrade in a single PR, and once you get the types to check, you’re done and you merge. We just got to the latest TS version last week.

Re: Node.js adds experimental support for TypeScript

#447

Post by RyanCavanaugh »

mananaysiempre wrote: post #260
miki123211 wrote: post #89

Earlier quoted context omitted.

Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful. With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[f…

> A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Given TypeScript’s type system is unsound, neither could it even if it tried, right? I guess Flow could, but well, here we are.

Flow's type system isn't sound either FWIW

Re: Node.js adds experimental support for TypeScript

#448

Post by FractalHQ »

wiseowise wrote: post #432
Dylan16807 wrote: post #423

Earlier quoted context omitted.

Specifically, you saw the section titled "Limits of JSDoc Type Annotations"?

Specifically, I saw JSDoc syntax and it triggered me so much that I closed the page and threw my phone away in disgust at absurdness of even the idea that someone thought having something like this unironically is a remotely good idea.

I support this behavior as the only correct reaction.

Re: Node.js adds experimental support for TypeScript

#449

Post by WorldMaker »

Timon3 wrote: post #425
felixfbecker wrote: post #402

Earlier quoted context omitted.

This is true, but in other cases they added keywords in ways that could work with type stripping. For example, the `as` keyword for casts has existed for a long time, and type stripping could strip everything after the `as` keyword with a minimal grammar. When TypeScript added const declarations, they added it as `as const` so a type stripping could have still worked depending on how loosely it is implemented. I thin…

I don't know a lot about parser theory, and would love to learn more about ways to make parsing resilient in cases like this one. Simple cases like "ignore rest of line" make sense to me, but I'm unsure about "adversarial" examples (in the sense that they are meant to beat simple heuristics). Would you mind explaining how e.g. your `as` stripping could work for one specific adversarial example? function foo () { retu…

Most parsers don't actually work with "lines" as a unit, those are for user-formatting. Generally the sort of building blocks you are looking for are more along the lines of "until end of expression" or "until end of statement". What defines an "expression" or a "statement" can be very complex depending on the parser and the language you are trying to parse.

In JS, because it is a fun example, "end of statement" is defined in large part by Automatic Semicolon Insertion (ASI), whether or not semicolons even exist in the source input. (Even if you use semicolons regularly in JS, JS will still insert its own semicolons. Semicolons don't protect you from ASI.) ASI is also a useful example because it is an ancient example of a language design intentionally trying to be resilient. Some older JS parsers even would ignore bad statements and continue on the next statement based on ASI determined statement break. We generally like our JS to be much more strict than that today, but early JS was originally built to be a resilient language in some interesting ways.

One place to dive into that directly (in the middle of a deeper context of JS parser theory): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Node.js adds experimental support for TypeScript

#450

Post by low_tech_punk »

suby wrote: post #63
dgellow wrote: post #36

Earlier quoted context omitted.

I would rather let Typescript evolve a few more years before freezing its development via standardization

I'm interested to know what are some things that you (or anyone reading this) feels that Typescript is missing / should change?

Maybe it's helpful to analyze TypeScript's track record in deprecating features and creating breaking changes, which could be a big red flag to TC39. I'm all for typing support but my work is mostly prototyping on short lived projects. People maintaining production systems that will eventually become legacy systems might have a different opinion.
Post reply on HN