The future of `--experimental-transform-types`

[marco-ippolito]

I wanted to talk about the future of --experimental-transform-types.
The feature has been stable for a while no outstanding issue.
The problem with this flag is that the syntax supported might change due to typescript deprecations (rip module which btw is already not supported just an example), syntax becomes supported in the js spec (Maybe enums one day 😆) etc...
Here a few options:

• remove the flag completely (I dont know if its even possible given the massive usage)
• Leave the flag experimental forever (I dont like this option)
• Mark the flag as stable but document that the changes in the syntax are not semver major therefore it can break)
• Mark the flag as stable and mark every syntax change as semver major (😫)

WDYT @nodejs/typescript

[ljharb]

massive usage

i'd love to see numbers on this!

I'd expect the only viable options are 2, or 4. 1 will upset people who use it even if the usage was small, and 3 contradicts the meaning of "stable".

[jakebailey]

I would personally say option 2; "use at your own risk".

[marco-ippolito]

massive usage

i'd love to see numbers on this!

I'd expect the only viable options are 2, or 4. 1 will upset people who use it even if the usage was small, and 3 contradicts the meaning of "stable".

Quick search https://github.com/search?q=--experimental-transform-types+NOT+is%3Afork&type=code 1.7K results

[ljharb]

Thanks! Is that considered "massive"? What do other experimental flags look like in those results?

[aduh95]

Thanks! Is that considered "massive"? What do other experimental flags look like in those results?

https://github.com/search?q=--experimental-strip-types+NOT+is:fork&type=code shows 5.9k results, https://github.com/search?q=--experimental-require-module+NOT+is:fork&type=code shows 769 results, https://github.com/search?q=--experimental-sqlite+NOT+is:fork&type=code 560 results, https://github.com/search?q=--experimental-websocket+NOT+is:fork&type=code 126 results.

[robpalme]

Thanks for getting the numbers @aduh95. I am curious about the numeric thresholds Node uses to make these kinds of decisions.

Just in case option 1 seemed too blunt, there is also...

Option 1.5: "Carefully managed removal". Mark it as deprecated so that people know it will be considered for removal in some future major version.

[robpalme]

From OP:

(rip module which btw is already not supported just an example)

Just one narrow correction: the deprecation of the module keyword was not specific to transform-types. It was just a plain carefully-executed TypeScript-wide deprecation. The proof is that if you enable erasableSyntaxOnly in TS 5.9, you can still use module to create type-only ("uninstantiated") namespaces.

A year ago, knowing this deprecation was likely coming in TS 6.0, we took mitigation steps in Amaro/SWC to error on the old syntax. This is why today both strip-types and transform-types are immune to the deprecation.

Would you mind editing to remove this example? Or use strike-through.

[marco-ippolito]

module is a fitting example of deprecated syntax which would require a Node.js semver major if the flag were to be marked as stable. Thats (among other more compelling reasons) why I think its not a good idea to mark it as stable. Type stripping would of course have the same problem, but since transform-types supports more syntax, this issue is more likely