Roadmap to stable strip-types

[marco-ippolito]

We have unflagged --experimental-strip-types in v23.6.0.
Here what I think are some of the next steps:

• Article on how to publish a new package @JakobJingleheimer feat(learn): add article for publishing a typescript package nodejs.org#7279
• Update SWC with feat(ts/fast-strip): Distinguish invalid vs unsupported swc-project/swc#9846 and Amaro so we will be able to identify when ts syntax is unsupported (like enums in strip types) or just generally invalid syntax. This should be the last "planned" breaking change since it will throw different errors rather than ERR_INVALID_TYPESCRIPT_SYNTAX for everything.
• Backport the changes to v22 (Wait some time, dependending on how many bugs we find)
• Wait for TypeScript 5.8 (at least beta) --erasableSyntaxOnly flag
• Update the suggested tsconfig file with the new --erasableSyntaxOnly flag @khaosdoctor (Add recommended configuration for Node.js running TS natively tsconfig/bases#293)
• Create an utility (like https://github.com/fastify/tsconfig) to validate tsconfig or generate tsconfig compatible with --experimental-strip-types @robpalme added it to https://github.com/tsconfig/bases/blob/main/bases/node-ts.json
• Move the feature to stability 1.2 (Release candidate)
• Move to stable ideally around October 2025 when we cut v24 LTS release (this mean rename flags to --strip-types, remove warnings etc...)

Feel free to add items if you think I missed something

[mcollina]

I think we should publish the suggested tsconfig on npm and maintain it.

Plan sounds good.

[JakobJingleheimer]

I think we should publish the suggested tsconfig on npm and maintain it.

Plan sounds good.

Great idea 🙂 could go under the @nodejs namespace we already have

[JakobJingleheimer]

Article on how to publish a new package node/nodejs.org#7279

I'm getting back to this tonight. I have made the requested updates locally. Need to finish a couple other things and then will push.

Wait for TypeScript 5.8 (at least beta) compatibility flag with strip-types (@nodejs/typescript ETA?)

Looks like this is still an unknown: https://bsky.app/profile/jakebailey.dev/post/3lf4igi3lzc2m

Create some utilities to validate tsconfig or generate tsconfig compatible with --experimental-strip-types

I can do! I recently did something similar for one of my own libraries.

[ljharb]

What about TS syntax in the repl? Should that work by default too?

[marco-ippolito]

What about TS syntax in the repl? Should that work by default too?

I did not dare to try implement it in the REPL as it looks quite complicate.

[RyanCavanaugh]

We've named and approved microsoft/TypeScript#59601 which should land in either TS 5.8 or 5.9 depending on timing, so that should be a recommended flag once it's in

[khaosdoctor]

On the tsconfig file, @jakebailey brought up that we could also use https://github.com/tsconfig/bases which is kinda the "standard" way to get the base files with minimal effort, so I'll add the file there once the 5.8 Beta comes out extending it from the main Node 22 base config

[khaosdoctor]

Well that was fast: https://devblogs.microsoft.com/typescript/announcing-typescript-5-8-beta/

[simonbuchan]

Small heads up since it seems to be easy to miss that 5.7 also added --rewriteRelativeImportExtensions to support importing .ts in ts code without disabling build (like --allowImportingTsExtensions does )for code you use both locally and in published packages.

I've added a PR in tsconfig/bases#300 to add it already, but thought it was worth mentioning here.

[albertodiazdorado]

Do you have any insights about the possibility of --experimental-transform-types becoming stable?

The existence of this roadmap for type stripping is excellent news, because it means that the feature is likely to become stable and we are already considering it for our projects. I wonder whether there is any similar information about type transformation :)

[marco-ippolito]

--experimental-transform-types will become stable but will not be unflagged and stay behind the --transform-types flag

[jakebailey]

Of course note that TS itself is "unstable", so you may end up with a break when using that flag eventually (e.g., we will probably be removing the module keyword to make way for TC39 use).

[marco-ippolito]

Of course note that TS itself is "unstable", so you may end up with a break when using that flag eventually (e.g., we will probably be removing the module keyword to make way for TC39 use).

We have already removed the module keyword support completely.
If there are semver major changes to the syntax that break transpilation we will update node in a semver major.