Repository navigation
JS value being parsed as a TS type argument #36662
Description
TypeScript Version: 3.8.0-dev.20200205
Search Terms: emscripten "type arguments"
Code
The following code (I added the declaration) was found in the distribution package for viz.js: https://github.com/mdaines/viz.js/releases/download/v2.1.2/lite.render.js. This file is generated by emscripten, so the syntax is a little weird.
declare let [k, e, a, c, n]: number[];
if ((k | 0) < (e | 0) | (k | 0) > (a << 16 >> 16 | 0)) {
c[n >> 2] = 1364;
}Expected behavior:
This is valid JavaScript and should have the same parse as JS.
Actual behavior:
If this is parsed as TS, the part between the < and the > get pulled out as a type annotation, leaving
if ((k | 0)(a << 16 >> 16 | 0))
which is clearly incorrect, as it's trying to call a number. If this is parsed as a JS file (with --allowJs), it produces an error:
$ tsc --allowJs a.js
a.js:2:14 - error TS8011: 'type arguments' can only be used in a .ts file.
2 if ((k | 0) < (e | 0) | (k | 0) > (a << 16 >> 16 | 0)) {
~~~~~~~~~~~~~~~~~~
Even if one makes the argument that this is not valid TS syntax, it should still parse the explicitly-JS input.
Playground Link:
Related Issues:
I was unable to find anything.
Activity
jcalz commentedon Feb 7, 2020
Duplicate of #33639, except that this was spotted in the wild.
DanielRosenwasser commentedon Feb 7, 2020
Thanks for the de-dupe - though I think there's a good point which is that this isn't a
.tsfile, it's a.jsfile. Maybe we should have a separate path for parsing in.jsfiles.Stephen Hicks (@shicks) can you tell us more about why you ended up piping this through TypeScript?
shicks commentedon Feb 7, 2020
We have a
ts_development_srcsbazel build rule that uses tsc to transpile/downlevel the transitive closure of a project's dependencies for testing and development serving (as opposed to the production compilation path that uses tsickle without any downleveling so that Closure Compiler can do better optimizations). This build rule provides an option (on by default) to pass *.js sources to tsc to downlevel as well, so that the whole transitive closure can be handled in one place (we have build rules for using Closure to downlevel JS only, but they don't work well with TS inputs and we're trying to move off of them anyway).The workaround here was to just turn off this option, but that could be a problem if there were also *.js sources written in ESnext sitting alongside viz.js and needing to be tested in an older browser.
fatcerberus commentedon Feb 7, 2020
If only it were! The fun thing here is that this is valid TS syntax.☹️ (though take my outsider perspective with a grain of salt, I don't know that much about the compiler internals!)
< (e | 0) | (k | 0) >is most likely being parsed ase | 0 | k | 0, that is, a union type. In a.tsfile, the expression is actually ambiguous. Fixing it is likely nontrivialDo not parse template arguments in JavaScript files.
Do not parse template arguments in JavaScript files. (#36673)