Breaking: throw syntax error on incomplete variable declarations (fixes #531)

[mysticatea]

This PR makes the parser throwing on incomplete variable declarations.

It's a syntax error on both JavaScript and TypeScript. But TypeScript parser looks so tolerant and triggers that core rules are confusing.

[mysticatea]

I added this configuration of jest because jest threw a syntax error on new tests/fixtures/basics/solo-const.src.js file while collecting coverage.

[platinumazure]

Is this something we can control in the TS parser (e.g., with a parser option)? It might be better/easier if we just tell TS not to tolerate that error type.

[mysticatea]

I guess tsc verifies it on type checking phase so the parsing phase is tolerant.

[platinumazure]

Got it.

I guess my other thought is, should this be handled in typescript-estree? If that project is supposed to create ESTree output and variable declarations with no declarators are invalid, maybe that should throw the error rather than typescript-eslint-parser?

What do you think?

[mysticatea]

I'm thinking about it, too.

I'm not sure if this is a spec violation or not because: ESTree defines types (E.g., VariableDeclaration#declarations is Array<VariableDeclarator>) but ESTree doesn't define restrictions (E.g., VariableDeclaration#declarations.length should not be 0).

Anyway, I should open an issue on typescript-estree repo.

[JamesHenry]

Yep we can get that in as an option in the parser 👍

[JamesHenry]

See my comment here after Andy from the TypeScript team responded: #531 (comment)

It should hopefully be possible for us to leverage TypeScript here, as long as we can clarify the behaviour is correct

[JamesHenry]

Response from Andy:

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

Maybe a good next step would be if I add an option to the parser (which will be false by default so as to be non-breaking) which checks for results from both:

program.getSyntacticDiagnostics(file);
program.getSemanticDiagnostics(file);

E.g. the option could be

"errorOnTypeScriptSyntaticAndSemanticIssues": false

...and we could see if that is something this ESLint parser would to enable?

[mysticatea]

I'm sorry for the delay. I have overlooked this.

errorOnTypeScriptSyntaticAndSemanticIssues option sounds good to me.

[armano2]

errorOnTypeScriptSyntaticAndSemanticIssues seems nice
for now i implemented this as rule in bradzacher/eslint-plugin-typescript#245

[j-f1]

throwSemanticErrors?

[JamesHenry]

FYI I added the errorOnTypeScriptSyntaticAndSemanticIssues option to typescript-estree in version 8.1.0, so you can opt in to that and it will error in the exact test case you have in this PR

[JamesHenry]

Once we merge the latest updates of typescript-estree (#596), we can explore surfacing an option for the diagnostics reporting

[JamesHenry]

Closing this for now, we'll add in full support for errorOnTypeScriptSyntaticAndSemanticIssues