7 ms·

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 t

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 < bar & baz > ( x )`. In TypeScript 1.5 this parsed as (foo<bar) & (baz > (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo<(bar & baz)>(x) which desugared to foo(x). I realise I’m going back in time here but it’s a nice simple example. If you want to continue to use new TypeScript features you are going to need to keep compiling to JS, or else keep your node version up to date. For people who like to stick on node LTS releases this may be an unacceptable compromise.

spoiler 2y ago
It's possible that internal SWC version will be versioned alongside Node, meaning TS syntax support won't drift. Or am I missing something?
- thecopy 2y ago
  TypeScript evolves independent of Node, and the syntax you can use depends on your `typescript` version in the `package.json`
  - re-thc 2y ago
    Not if SWC or your tooling doesn't support it.
- satanacchio 2y ago
  yes but can also be upgraded separately as npm package
the_gipsy 2y ago
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
baybal2 2y ago
[dead]
Tade0 2y ago
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.
- 3np 2y ago
  > crazy recursive dependent types Some edge-cases involving those have bugfixes and ergonomy improvents I've run into on 5.x.
  - Tade0 2y ago
    That's great to know, thank you. That being said I regret every use of `infer` in application code.
noname120 2y ago
It's already the case for ECMAScript and I don't see why TypeScript should be treated differently when Node.js has to transpile it to JavaScript and among other things ensure that there are no regressions that would break existing code. Unlike Python typing it's not only type erasure: enums, namespaces, decorators, access modifiers, helper functions and so on need to be transformed into their JavaScript equivalent.
- shortrounddev2 2y ago
  and there's a slight runtime difference between typescript classes and javascript classes
madeofpalk 2y ago
It looks like the team has already considered this in one regard > There is already a precedent for something that Node.js support, that can be upgraded seperately, its NPM. Node bundles a version of npm that can upgraded separately, we could do the same with our TypeScript transpiler. > We could create a package that we bundle but that can also be downloaded from NPM, keep a stable version in core, but if TypeScript releases new features that we don't support or breaking changes, or users want to use the new shiny experimental feature, they can upgrade it separately. This ensures that users are not locked, but also provides support for a TypeScript version for the whole 3 years of the lifetime of Node.js release. https://github.com/nodejs/loaders/issues/217 https://github.com/nodejs/loaders/issues/217
- SomeCallMeTim 2y ago
  As long as Node understands to use the project-specific version of TypeScript (i.e., the one in node_modules or the PNP equivalent), that should be fine. But it would be a step backward to need to globally upgrade TypeScript (as you do with npm), since some older projects will not be compatible with newer versions of TypeScript. Ask me how I know. ;)
  - silverwind 2y ago
    > As long as Node understands to use the project-specific version of TypeScript It won't, but in such a scenario, typescript would only be a type checker, wich is a entirely different endeavor than running typescript.
  - madeofpalk 2y ago
    I think Node’s strategy here is to not let perfect be the enemy of useful for some people.
  - nilsbunger 2y ago
    At first I thought that's not a big deal, I could manage that with `nvm`. But I think you're right, you really want it to pick up the project-specific typescript so that you're using ONE version of typescript for type checking, execution, and more.
getcrunk 2y ago
Do you really need to update all the time? Are the new features always that immediately important?
nialv7 2y ago
Using inequality signs as angled brackets really is a mistake isn't it...
- klodolph 2y ago
  I’ll flip this around… reusing comparison as angle brackets is the mistake. C++ ran into some issues too. I think Rust made the really smart move of putting :: before any type parameters for functions. Go made the good move of using square brackets for type parameters.
  - zarzavat 2y ago
    The problem can be traced back to ASCII/typewriters only including three sets of paired characters, plus inequality signs, which is not enough for programming languages. We really need five sets: grouping, arrays/indexing, records, type parameters, and compound statements. Curly braces {} are also overloaded in JS for records and compound statements, leading to x => {} and x => ({}) meaning different things. Square brackets wouldn't work for parametric functions because f[T](x) already means get the element at index T and call it.
    - xigoi 2y ago
      I think the D syntax would work: f!T(x)
    - behnamoh 2y ago
      Everytime a standardization happens, part of human creativity gets suppressed. Before ASCII, people were inventing all sorts of symbols and even the alphabet was flexible to changes. After ASCII, we got stuck with a certain set of letters and symbols. Heck, even our keyboards haven't changed that much since then. I really think we need more symbols than just &@$#%^*}{][<>()/\_~|
    - parasense 2y ago
      Paired characters... That's an interesting topic. Do you happen to know if UTF-8 contains more "pair" characters? In Latex we call these delimiteres, but that's just my limited experience coming in from math side. I tend to agree that it would be helpful to have more kind of nesting/pairing/grouping/delimiting characters. The problem is my imagination is limited to what I know from the ASCII world, and so it goes... no idea what new sets would look like.
WorldMaker 2y ago
The syntax from the perspective of type stripping has been relatively stable for more versions of Typescript than it was unstable. You had to reach all the way back to 1.5 in part because it's been very stable since about 2.x. The last major shift in syntax was probably Conditional Types in 2.8 adding the ternary if operator in type positions. (The type model if you were to try to typecheck rather than just type-strip has changed a lot since 2.x, but syntax has been generally stable. That's where most of Typescript's innovation has been in the type model/type inferencing rather than in syntax.) It's still just (early in the process) Stage 1, but the majority of Typescript's type syntax, for the purposes of type stripping (not type checking), is attempting to be somewhat standardized: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- teaearlgraycold 2y ago
  They did just add a new keyword, satisfies, in 5.4. That would be a breaking change if you can’t upgrade the type stripper separately.
  - panzi 2y ago
    But at least its a loud failure and not a silent different interpretation of the source as the example was. Still.
  - felixfbecker 2y ago
    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 think there is a world where type stripping exists (which the TS team has been in favor of) and the TS team might consider how it affects type stripping in future language design. For example, the `satisfies` keyword could have also been added by piggy-backing on the `as` keyword, like: const foo = { bar: 1 } as subtype of Foo (I think not using `as` is a better fit semantically but this could be a trade-off to make for better type stripping backwards compatibility)
felixfbecker 2y ago
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 latest and greatest TypeScript features.
- jitl 2y ago
  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.
js4ever 2y ago
If only typescript could avoid changing syntax every 2 weeks.
pornel 2y ago
Does TypeScript have some disambiguating syntax like turbofish?

spoiler 2y ago

It's possible that internal SWC version will be versioned alongside Node, meaning TS syntax support won't drift. Or am I missing something?

thecopy 2y ago
TypeScript evolves independent of Node, and the syntax you can use depends on your `typescript` version in the `package.json`
- re-thc 2y ago
  Not if SWC or your tooling doesn't support it.
satanacchio 2y ago
yes but can also be upgraded separately as npm package

the_gipsy 2y ago

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

baybal2 2y ago

[dead]

Tade0 2y ago

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.

3np 2y ago
> crazy recursive dependent types Some edge-cases involving those have bugfixes and ergonomy improvents I've run into on 5.x.
- Tade0 2y ago
  That's great to know, thank you. That being said I regret every use of `infer` in application code.

noname120 2y ago

It's already the case for ECMAScript and I don't see why TypeScript should be treated differently when Node.js has to transpile it to JavaScript and among other things ensure that there are no regressions that would break existing code. Unlike Python typing it's not only type erasure: enums, namespaces, decorators, access modifiers, helper functions and so on need to be transformed into their JavaScript equivalent.

shortrounddev2 2y ago
and there's a slight runtime difference between typescript classes and javascript classes

madeofpalk 2y ago

It looks like the team has already considered this in one regard > There is already a precedent for something that Node.js support, that can be upgraded seperately, its NPM. Node bundles a version of npm that can upgraded separately, we could do the same with our TypeScript transpiler. > We could create a package that we bundle but that can also be downloaded from NPM, keep a stable version in core, but if TypeScript releases new features that we don't support or breaking changes, or users want to use the new shiny experimental feature, they can upgrade it separately. This ensures that users are not locked, but also provides support for a TypeScript version for the whole 3 years of the lifetime of Node.js release. https://github.com/nodejs/loaders/issues/217 https://github.com/nodejs/loaders/issues/217

SomeCallMeTim 2y ago
As long as Node understands to use the project-specific version of TypeScript (i.e., the one in node_modules or the PNP equivalent), that should be fine. But it would be a step backward to need to globally upgrade TypeScript (as you do with npm), since some older projects will not be compatible with newer versions of TypeScript. Ask me how I know. ;)
- silverwind 2y ago
  > As long as Node understands to use the project-specific version of TypeScript It won't, but in such a scenario, typescript would only be a type checker, wich is a entirely different endeavor than running typescript.
- madeofpalk 2y ago
  I think Node’s strategy here is to not let perfect be the enemy of useful for some people.
- nilsbunger 2y ago
  At first I thought that's not a big deal, I could manage that with `nvm`. But I think you're right, you really want it to pick up the project-specific typescript so that you're using ONE version of typescript for type checking, execution, and more.

getcrunk 2y ago

Do you really need to update all the time? Are the new features always that immediately important?

nialv7 2y ago

Using inequality signs as angled brackets really is a mistake isn't it...

klodolph 2y ago
I’ll flip this around… reusing comparison as angle brackets is the mistake. C++ ran into some issues too. I think Rust made the really smart move of putting :: before any type parameters for functions. Go made the good move of using square brackets for type parameters.
- zarzavat 2y ago
  The problem can be traced back to ASCII/typewriters only including three sets of paired characters, plus inequality signs, which is not enough for programming languages. We really need five sets: grouping, arrays/indexing, records, type parameters, and compound statements. Curly braces {} are also overloaded in JS for records and compound statements, leading to x => {} and x => ({}) meaning different things. Square brackets wouldn't work for parametric functions because f[T](x) already means get the element at index T and call it.
  - xigoi 2y ago
    I think the D syntax would work: f!T(x)
  - behnamoh 2y ago
    Everytime a standardization happens, part of human creativity gets suppressed. Before ASCII, people were inventing all sorts of symbols and even the alphabet was flexible to changes. After ASCII, we got stuck with a certain set of letters and symbols. Heck, even our keyboards haven't changed that much since then. I really think we need more symbols than just &@$#%^*}{][<>()/\_~|
  - parasense 2y ago
    Paired characters... That's an interesting topic. Do you happen to know if UTF-8 contains more "pair" characters? In Latex we call these delimiteres, but that's just my limited experience coming in from math side. I tend to agree that it would be helpful to have more kind of nesting/pairing/grouping/delimiting characters. The problem is my imagination is limited to what I know from the ASCII world, and so it goes... no idea what new sets would look like.

WorldMaker 2y ago

The syntax from the perspective of type stripping has been relatively stable for more versions of Typescript than it was unstable. You had to reach all the way back to 1.5 in part because it's been very stable since about 2.x. The last major shift in syntax was probably Conditional Types in 2.8 adding the ternary if operator in type positions. (The type model if you were to try to typecheck rather than just type-strip has changed a lot since 2.x, but syntax has been generally stable. That's where most of Typescript's innovation has been in the type model/type inferencing rather than in syntax.) It's still just (early in the process) Stage 1, but the majority of Typescript's type syntax, for the purposes of type stripping (not type checking), is attempting to be somewhat standardized: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

teaearlgraycold 2y ago
They did just add a new keyword, satisfies, in 5.4. That would be a breaking change if you can’t upgrade the type stripper separately.
- panzi 2y ago
  But at least its a loud failure and not a silent different interpretation of the source as the example was. Still.
- felixfbecker 2y ago
  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 think there is a world where type stripping exists (which the TS team has been in favor of) and the TS team might consider how it affects type stripping in future language design. For example, the `satisfies` keyword could have also been added by piggy-backing on the `as` keyword, like: const foo = { bar: 1 } as subtype of Foo (I think not using `as` is a better fit semantically but this could be a trade-off to make for better type stripping backwards compatibility)

felixfbecker 2y ago

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 latest and greatest TypeScript features.

jitl 2y ago
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.

js4ever 2y ago

If only typescript could avoid changing syntax every 2 weeks.

pornel 2y ago

Does TypeScript have some disambiguating syntax like turbofish?