Repository navigation
Javascript error which isn't one: 'type arguments' can only be used in a .ts file #29235
Description
- VSCode Version: 1.31-insider
- OS Version: Windows 10 Pro
Activity
Please include reproducible steps.
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.
Reacted by Wesley Wighamconfirmed using typescript@3.3.0-dev.20190101
The pattern that causes issues is:
if((0)<0>(0)){ }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.jsfile.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)
- removed this from the TypeScript 3.4.0 milestone
on Jan 2, 2019 9 remaining items
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 doesx|0which binds more loosely than greater than/less than. Variables in general aren't parenthesized.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
.jsfile; I'm just not sure if that's practical.I have a (work in progress) tried on my branch Kingwl@9143748 but I'm not sure that is expected
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-ignoreboth before theimportand before the line where the error is reported. I have tried using the// @ts-nocheckcomment at the beginning of the generated file. There doesn't seem to be any way to silence this false positive.I think this is fixed by #36673, right?
I am not sure whether or not I did the test correctly. I have modified my
package.jsonfile entry to :"typescript": "mprobst/TypeScript#f308ac136d420a71819616207a0358b8d369a9cc"and rannpm installafterwards. 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.
I have successfully cloned
mprobst/TypeScript:parse-jsand 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/masterinto my local copy ofmprobst/TypeScript:js-parseand 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.This is an old issue, but this was definitely fixed by #36673 in TS 4.2.
- locked as resolved and limited conversation to collaborators
on Oct 21, 2025