Javascript error which isn't one: 'type arguments' can only be used in a .ts file

[masbaehr]

• VSCode Version: 1.31-insider
• OS Version: Windows 10 Pro

[octref]

Please include reproducible steps.

[masbaehr]

Just put this file into the editor and open it:

https://github.com/schmich/instascan/releases/download/1.0.0/instascan.min.js

Usually other minified js files open normally and syntax highlighting still works, but not this one. I can't exclude this is an error in the file but even then the error message is probably wrong.

[mjbvz]

confirmed using [email protected]

The pattern that causes issues is:

if((0)<0>(0)){ }

[fatcerberus]

Hmm, it appears to think the stuff inside <> is a type argument, in this case it’s <(n|0)|(e|0)> which I guess the compiler thinks is a type union...

My instinct is that the error message should probably be removed entirely and the compiler just treat it as a normal < or > operator when inside a .js file.

[DanielRosenwasser]

Basic idea is that when the file is a JS/JSX file, don't try to parse type arguments for

• call expressions
• new expressions
• tagged template strings
• JSX
• decorators (I don't even think we currently do at all)

[sheetalkamat]

@DanielRosenwasser I don't think not parsing type arguments is correct fix. We do that so we can report better errors.
The above example in typescript file is an error too?

a.ts:1:4 - error TS2349: Cannot invoke an expression whose type lacks a call signature. Type 'Number' has no compatible call signatures.

1 if((0)<0>(0)){ }
     ~~~~~~~~~


Found 1 error.

[DanielRosenwasser]

It's a type error in TypeScript, but it would've parsed as different but syntactically valid JavaScript. In this case, that code is generated my another program, so saying "that's not valid JS" is weird.

[weswigham]

No, like, the issue moreso that we shouldn't be interpreting that pattern as type arguments in any language variant, ideally.

[fatcerberus]

I don't think that's possible in the general case; what if instead the pattern is x<y>(z); in TypeScript the <y> can legally be parsed as a type argument, but in JS it means instead x < y > (z). I admit it would be nice if we could invoke No True Scotsman and just say "don't do that", but if a minifier used in someone's toolchain is producing code that looks like this and that file is part of the TS project, then we don't have that luxury.

[weswigham]

We could trim back the scope of what we parse as type arguments, however - while x<y>(z) is reasonably a call with type arguments, (x)<y>(z) is... less so, IMO (though yeah, I get that it works today and would technically be a break).

[weswigham]

For anyone interested and reading this issue, parseCallExpressionRest in parser.ts is where we handle this.

[fatcerberus]

What I was getting at was there's no guarantee that a minifier won't produce code that looks exactly like x<y>(z). Even in the code sample in the OP you can see it comes dangerously close to doing so--the parentheses are only present because it does x|0 which binds more loosely than greater than/less than. Variables in general aren't parenthesized.

[fatcerberus]

That being said, I agree it would be nice to keep the error for the benefit of people trying to write TS code in a .js file; I'm just not sure if that's practical.

[Kingwl]

I have a (work in progress) tried on my branch Kingwl@9143748 but I'm not sure that is expected

[Dalzhim]

I have the same kind of problem and I've been searching for hours for a workaround that I could use without any success. I am using Emscripten to compile some C++ code into JavaScript. It produces a JavaScript file. I have to import the generated *.js file from within a *.tsx file in order to leverage the exposed functions.

I have tried using the // @ts-ignore both before the import and before the line where the error is reported. I have tried using the // @ts-nocheck comment at the beginning of the generated file. There doesn't seem to be any way to silence this false positive.

[DanielRosenwasser]

I think this is fixed by #36673, right?

[Dalzhim]

I am not sure whether or not I did the test correctly. I have modified my package.json file entry to : "typescript": "mprobst/TypeScript#f308ac136d420a71819616207a0358b8d369a9cc" and ran npm install afterwards. After doing that, the error remains when I compile my project.

TS8011: Type arguments can only be used in TypeScript files.
TS1139: Type parameter declaration expected.

Edit: I'm now quite certain my test is not correct as I can look into node_modules/typescript/lib/tsc.js and I see the old version of the code prior to the commit.

[Dalzhim]

I have successfully cloned mprobst/TypeScript:parse-js and built the package. It now fails with the following error :

ERROR in ./src/client/app/index.js
Module build failed (from ./node_modules/ts-loader/index.js):
Error: Debug Failure. Unexpected node.
Node ComputedPropertyName was unexpected.
    at bindThisPropertyAssignment (/TypeScript/lib/typescript.js:32648:30)
    at bindWorker (/TypeScript/lib/typescript.js:32280:29)
    at bind (/TypeScript/lib/typescript.js:32160:13)
    at visitNode (/TypeScript/lib/typescript.js:18468:24)
    at Object.forEachChild (/TypeScript/lib/typescript.js:18884:21)
    at bindEachChild (/TypeScript/lib/typescript.js:30688:16)
    at bindChildrenWorker (/TypeScript/lib/typescript.js:30783:21)
    at bindChildren (/TypeScript/lib/typescript.js:30658:17)
    at bind (/TypeScript/lib/typescript.js:32171:21)
    at bindEach (/TypeScript/lib/typescript.js:30680:21)
    at visitNodes (/TypeScript/lib/typescript.js:18473:24)
    at Object.forEachChild (/TypeScript/lib/typescript.js:18864:21)
    at bindEachChild (/TypeScript/lib/typescript.js:30688:16)
    at bindChildrenWorker (/TypeScript/lib/typescript.js:30783:21)
    at bindChildren (/TypeScript/lib/typescript.js:30658:17)
    at bind (/TypeScript/lib/typescript.js:32171:21)
    at visitNode (/TypeScript/lib/typescript.js:18468:24)
    at Object.forEachChild (/TypeScript/lib/typescript.js:18850:24)
    at bindEachChild (/TypeScript/lib/typescript.js:30688:16)
    at bindChildrenWorker (/TypeScript/lib/typescript.js:30783:21)
    at bindChildren (/TypeScript/lib/typescript.js:30658:17)
    at bind (/TypeScript/lib/typescript.js:32171:21)
    at visitNode (/TypeScript/lib/typescript.js:18468:24)
    at Object.forEachChild (/TypeScript/lib/typescript.js:18538:21)
    at bindEachChild (/TypeScript/lib/typescript.js:30688:16)
    at bindChildrenWorker (/TypeScript/lib/typescript.js:30783:21)
    at bindChildren (/TypeScript/lib/typescript.js:30658:17)
    at bind (/TypeScript/lib/typescript.js:32171:21)
    at bindEach (/TypeScript/lib/typescript.js:30680:21)
    at visitNodes (/TypeScript/lib/typescript.js:18473:24)
    at Object.forEachChild (/TypeScript/lib/typescript.js:18783:21)
    at bindEachChild (/TypeScript/lib/typescript.js:30688:16)
    at bindChildrenWorker (/TypeScript/lib/typescript.js:30783:21)
    at bindChildren (/TypeScript/lib/typescript.js:30658:17)
    at bindContainer (/TypeScript/lib/typescript.js:30639:17)
    at bind (/TypeScript/lib/typescript.js:32174:21)
    at /TypeScript/lib/typescript.js:30664:94
    at bindEach (/TypeScript/lib/typescript.js:30680:21)
    at bindEachFunctionsFirst (/TypeScript/lib/typescript.js:30664:13)
    at bindChildrenWorker (/TypeScript/lib/typescript.js:30774:21)
    at bindChildren (/TypeScript/lib/typescript.js:30658:17)
    at bindContainer (/TypeScript/lib/typescript.js:30604:17)
 @ multi @babel/polyfill ./src/index.js bundle[1]

Edit 1 : I have tried using the revision prior to the merge request : 2cc5856, and the above error was already present before the commit in the pull request.

Edit 2 : I have merged upstream/master into my local copy of mprobst/TypeScript:js-parse and I still get the above error. Therefore, I am unable at this moment to confirm without any doubts that the error is resolved. I will wait for feedback before doing any further testing on this PR.

[jakebailey]

This is an old issue, but this was definitely fixed by #36673 in TS 4.2.