5 ms·

You would also have to update your compiler. I guess you could phrase this as: you can't update your TS versions independently from your node.js version. But th

You would also have to update your compiler. I guess you could phrase this as: you can't update your TS versions independently from your node.js version. But that's probably not an issue.

zarzavat 2y ago
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 hand, I usually adopt a new TypeScript version as soon as it comes out.
- another-dave 2y ago
  Though I'd primarily see this as a feature for the REPL or manual scripts where I'm not going to mind doing a `nvm use X`. For production use, I'd still put my TS files through a build pipeline as normal
  - chrisweekly 2y ago
    tangential protip: if you're using nvm to manage node versions, take a look at fnm as a superior replacement. (It can read the same .nvmrc file to switch on cd into a given dir, but it's faster and "cleaner" wrt impact on your shell.)
- satanacchio 2y ago
  I made it sure to decouple the transpiler from node itself, the transpiler is in a npm package called amaro, that is bundled in node. The goal is to allow user to upgrade amaro indipendently so we dont have to lock a ts version for the whole lifespan of a release
- mort96 2y ago
  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, this feature will be really nice. ("Boring" in this context is a compliment, by the way) EDIT: Though reading other comments, it seems like you can update the typescript stripper independent of node? That makes this moot anyway
  - mu53 2y ago
    typescript is still evolving in dramatic ways. The 5.0 release has some really good improvements
    - mort96 2y ago
      But at the same time, it's good enough and has been good enough for many years. It's like how I'm sure EcmaScript 2024 contains cool new stuff, but if node only supported ES6, I would have no trouble writing ES6.
klodolph 2y ago
Not necessarily. With a couple exceptions (like enums), you can strip the types out of TypeScript and end up with valid JS. What you could do is stabilize the grammar, and release new versions of TypeScript using the same grammar. Maybe you need a flag to use LTS grammar in your tsconfig.json file.
- 3np 2y ago
  > With a couple exceptions (like enums) Apart from a clueless engineer attempts them, it's been working out fine to pretend they don't exist.

You would also have to update your compiler. I guess you could phrase this as: you can't update your TS versions independently from your node.js version. But that's probably not an issue.

zarzavat 2y ago

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 hand, I usually adopt a new TypeScript version as soon as it comes out.

another-dave 2y ago
Though I'd primarily see this as a feature for the REPL or manual scripts where I'm not going to mind doing a `nvm use X`. For production use, I'd still put my TS files through a build pipeline as normal
- chrisweekly 2y ago
  tangential protip: if you're using nvm to manage node versions, take a look at fnm as a superior replacement. (It can read the same .nvmrc file to switch on cd into a given dir, but it's faster and "cleaner" wrt impact on your shell.)
satanacchio 2y ago
I made it sure to decouple the transpiler from node itself, the transpiler is in a npm package called amaro, that is bundled in node. The goal is to allow user to upgrade amaro indipendently so we dont have to lock a ts version for the whole lifespan of a release
mort96 2y ago
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, this feature will be really nice. ("Boring" in this context is a compliment, by the way) EDIT: Though reading other comments, it seems like you can update the typescript stripper independent of node? That makes this moot anyway
- mu53 2y ago
  typescript is still evolving in dramatic ways. The 5.0 release has some really good improvements
  - mort96 2y ago
    But at the same time, it's good enough and has been good enough for many years. It's like how I'm sure EcmaScript 2024 contains cool new stuff, but if node only supported ES6, I would have no trouble writing ES6.

klodolph 2y ago

Not necessarily. With a couple exceptions (like enums), you can strip the types out of TypeScript and end up with valid JS. What you could do is stabilize the grammar, and release new versions of TypeScript using the same grammar. Maybe you need a flag to use LTS grammar in your tsconfig.json file.

3np 2y ago
> With a couple exceptions (like enums) Apart from a clueless engineer attempts them, it's been working out fine to pretend they don't exist.