got "TypeError: Cannot read property 'loc' of undefined" after entering 'const' in typescript file in vscode

[UncleYee]

What version of TypeScript are you using?
v2.9.1

What version of typescript-eslint-parser are you using?
v16.0.0

What code were you trying to parse?

// Put your code here
const

What did you expect to happen?
no error

What happened?
After entering const

[Trace - 3:10:47 PM] Received notification 'window/logMessage'.
[Error - 3:10:47 PM] TypeError: Cannot read property 'loc' of undefined
at Object.VariableDeclaration [as listener] (/openSource/koa-typescript-example/node_modules/eslint/lib/rules/indent.js:1317:69)
at Program:exit.listenerCallQueue.filter.forEach.nodeInfo (/openSource/koa-typescript-example/node_modules/eslint/lib/rules/indent.js:1496:55)
at Array.forEach ()
at Program:exit (/openSource/koa-typescript-example/node_modules/eslint/lib/rules/indent.js:1496:26)
at listeners.(anonymous function).forEach.listener (/openSource/koa-typescript-example/node_modules/eslint/lib/util/safe-emitter.js:47:58)
at Array.forEach ()
at Object.emit (/openSource/koa-typescript-example/node_modules/eslint/lib/util/safe-emitter.js:47:38)
at NodeEventGenerator.applySelector (/openSource/koa-typescript-example/node_modules/eslint/lib/util/node-event-generator.js:251:26)
at NodeEventGenerator.applySelectors (/openSource/koa-typescript-example/node_modules/eslint/lib/util/node-event-generator.js:280:22)
at NodeEventGenerator.leaveNode (/openSource/koa-typescript-example/node_modules/eslint/lib/util/node-event-generator.js:303:14)

eslint issue #11023

[kaicataldo]

Hi, thanks for the issue. Sorry to keep passing the buck, but this is actually an issue in https://github.com/JamesHenry/typescript-estree. Do you mind making an issue there, with the expected behavior being that typescript-estree should throw a syntax error for this?

[JamesHenry]

@kaicataldo The thing is, typescript-estree is powered by parsing using the TypeScript compiler and then transforming the AST before returning the result.

This means ultimately, that the parsing infrastructure is dictated by how the TypeScript compiler behaves.

TypeScript is incredibly forgiving during the parsing phase, because a lot of its value comes from its language service architecture which gives feedback on the code, e.g. in your editor.

Here you can see the parsing behaviour directly, it has no problem producing an AST for this source: https://astexplorer.net/#/gist/1ceed74d9bdbf7aa7e4c8df7acc53a35/b7879412d61d6280fd76a9c78dd0d62b5368373a

Short of performing a second parse step on top of the TypeScript compiler, I'm not sure what we can do about these kinds of situations... Definitely open to suggestions!

[JamesHenry]

@Andy-MS sorry to ping you here on a repo you haven't worked on, but would you mind giving your thoughts on this?

There is no way to get the parser within the tsc to be more strict about syntax errors, right?

[mysticatea]

I think we can verify JS syntax errors on around parser.js#L26 and throw it.

I see some situations:

• VariableDeclaration which node.declarations.length is 0. (E.g. const;, var;)
• VariableDeclaration which node.kind is "const" and has a member node.declarations[i].init == null. (E.g. const A;, the const declaration without that initializer is a syntax error in JS. But TS allows declare const A; and something like...)

There may be others, but I'm not sure.

[mysticatea]

Or back to eslint then fix rules to allow those. Because those are syntax error, but, but ESTree spec doesn't forbit those.

[ghost]

You can use program.getSyntacticDiagnostics(file); to get parse errors.

[JamesHenry]

@Andy-MS Thanks so much for getting back to me, interestingly that doesn't flag anything for the above case.

getSemanticDiagnostics does, however, return it as an issue.

program.getSyntacticDiagnostics(file); -> []

program.getSemanticDiagnostics(file); ->

Variable declaration list cannot be empty.

Should I open an issue on the TypeScript repo, I think it should be flagged as a syntax error?

[ghost]

You could open an issue, though this is hard to change because grammar and semantic checking are coupled currently.