Repository navigation
The removal of TypeScript types may result in broken JavaScript code #56597
Description
Activity
This is due to ASI issues around
returnspecifically; the proper fix is likely that swc should replace the snippets to the following, respectively:function mkId() { return ( (x )=>x); } function mkId() { return ( (x )=>x); }
Yes, introducing parenthesis around the generic closure would do the trick.
- addedstrip-typesIssues and PRs related to TypeScript type stripping.Issues and PRs related to TypeScript type stripping.
on Jan 14, 2025 We see how swc transpiles:
const { stripTypeScriptTypes } = require('node:module'); const code = stripTypeScriptTypes(`function mkId() { return <T> (x: T) => x; } const id = mkId(); console.log(id(5));`); console.log(code);
Output:
function mkId() { return (x ) => x; } const id = mkId(); console.log(id(5));
I'm only afraid how we can fix this without changing locations
cc @kdy1
@robpalme I think you fixed this issue ints-blank-space- addedconfirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.
on Jan 14, 2025 @marco-ippolito it can be fixed by using parens - basically it'd only change one location, where it adds the paren before the semicolon - otherwise it'd just be adding a paren instead of a blank space.
@marco-ippolito it can be fixed by using parens - basically it'd only change one location, where it adds the paren before the semicolon - otherwise it'd just be adding a paren instead of a blank space.
If we change even 1 location it would introduce edge cases.
Maybe with backticks we can overcome (hacky af)return ` `,(x ) => x;Maybe with backticks we can overcome
More naturally (and works even if the second line isn't indented):
return 0, (x ) => x;
I suppose the semicolon could be replaced with the paren. but yeah,
0,might work better.Reacted by Marco IppolitoI went ahead and opened an issue on SWC.
Reacted by Jordan HarbandThanks for the report @BlueNebulaDev
Ashley and I made some bold claims about prizes for anyone who could break this. If you are ever in London and wish to collect, please let me know 😉
Reacted by Marco Ippolito, Ivan Rubinson, BlueNebulaDev and Pietro MarchiniReacted by Mert Can Altin, Jordan Harband and BlueNebulaDevReacted by BlueNebulaDevOhh, that sounds intriguing and fun!
I'm likely to be in London in late-spring/early-summer. I'll drop you a private message once my plans become more concrete.Reacted by Rob Palmer- added a commit that references this issue
on Jan 29, 2025 - added 4 commits that reference this issue
on Apr 8, 2025
Version
v23.2.0
Platform
Subsystem
No response
What steps will reproduce the bug?
Run the following TypeScript script with nodejs (with the
--experimental-strip-typesoption, if necessary):How often does it reproduce? Is there a required condition?
It always happen deterministically.
What is the expected behavior? Why is that the expected behavior?
The script should print
5.What do you see instead?
The script errors with:
Additional information
I believe that Node strips TS types in such a way that the script I showed gets turned into the following JS code:
And unfortunately Node interprets a
returnfollowed by a new line as areturn;.The same behavior happens with different (but similar code), for instance:
It is somewhat common to break templates on a new line, when the generic types are complex (for instance if they have long
extendclauses) and this issue is particularly annoying because the IDE (which understands TS) doesn't flag it as an error.