Skip to content

The removal of TypeScript types may result in broken JavaScript code #56597

Description

@BlueNebulaDev

Version

v23.2.0

Platform

Linux 6.12.9 Fri Dec 20 10:11:49 UTC 2024 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

Run the following TypeScript script with nodejs (with the --experimental-strip-types option, if necessary):

function mkId() {
	return <T>
		(x: T)=>x;
}

const id = mkId();
console.log(id(5));

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:

console.log(id(5));
            ^

TypeError: id is not a function

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:

function mkId() {
	return
		(x: T)=>x;
}

const id = mkId();
console.log(id(5));

And unfortunately Node interprets a return followed by a new line as a return;.

The same behavior happens with different (but similar code), for instance:

function mkId() {
	return <
		T
	>(x: T)=>x;
}

It is somewhat common to break templates on a new line, when the generic types are complex (for instance if they have long extend clauses) and this issue is particularly annoying because the IDE (which understands TS) doesn't flag it as an error.

Activity

  1. ljharb commented on Jan 14, 2025

    @ljharb
    SponsorMember

    This is due to ASI issues around return specifically; 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);
    }
  2. BlueNebulaDev commented on Jan 14, 2025

    @BlueNebulaDev
    Author

    Yes, introducing parenthesis around the generic closure would do the trick.

  3. marco-ippolito commented on Jan 14, 2025

    @marco-ippolito
    Member

    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 in ts-blank-space

  4. ljharb commented on Jan 14, 2025

    @ljharb
    SponsorMember

    @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.

  5. marco-ippolito commented on Jan 14, 2025

    @marco-ippolito
    Member

    @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;
    
  6. bakkot commented on Jan 14, 2025

    @bakkot
    Contributor

    Maybe with backticks we can overcome

    More naturally (and works even if the second line isn't indented):

    return 0,
    (x ) => x;
  7. ljharb commented on Jan 14, 2025

    @ljharb
    SponsorMember

    I suppose the semicolon could be replaced with the paren. but yeah, 0, might work better.

  8. bakkot commented on Jan 14, 2025

    @bakkot
    Contributor

    I went ahead and opened an issue on SWC.

  9. robpalme commented on Jan 14, 2025

    @robpalme
    Contributor

    Thanks 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 😉

  10. BlueNebulaDev commented on Jan 15, 2025

    @BlueNebulaDev
    Author

    Ohh, 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.

  11. added a commit that references this issue on Jan 29, 2025
  12. added a commit that references this issue on Feb 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    confirmed-bugIssues and PRs for confirmed bugs.strip-typesIssues and PRs related to TypeScript type stripping.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions