New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: no-restricted-exports
: Cannot read property 'name' of null
#15384
Comments
The JavaScript code is invalid. You can’t have “export class extends” because exports require a name. I’ve tested Acorn, Babel, and Espree, and they all throw a syntax error on your example code. typescript-eslint should be throwing a parsing error before it ever gets to the rule, but it actually looks like TypeScript itself is not throwing an error, so typescript-eslint is just converting what it gets back. The true source of the error appears to be TypeScript. |
we currently throw almost no errors during parsing - typescript-eslint/typescript-eslint#1852 typescript doesn't throw error because its parser is intentionally "forgiving" so that it can work in an IDE where you need a parser that can recover to provide a good UX (eg so a parser error earlier doesn't break all autocomplete, etc for the entire file). |
Yikes okay, that seems like a problematic behavior. The problem from the ESLint side is that we assume a valid AST is presented. If we need to start assuming that the AST may be invalid, that will affect a ton of rules and become a maintenance nightmare. We just can’t programmatically check for validity in each rule without adding a lot of overhead and headaches. Would it make sense for typescript-eslint to throw during transforming the TypeScript AST into ESTree format? |
Yes, see the issue I mentioned. It's just going to take time and effort to build that - two things we're short on.
It's worth noting that this is how it has always been since the parser's creation (the code you originally wrote back in 2015!). This is not a problem in the real world because these "invalid" states are transient - people write broken code and then they correct it straight away. People don't report issues for these sorts of crashes because they fix themselves when they fix their broken code. In particular for TS - they won't be able to build their code without fixing it, so people have to fix it! In this instance @AriPerkkio maintains a tool which is sort of "crowd-sourced" testing of ESLint rules on real-world code. https://github.com/AriPerkkio/eslint-remote-tester This "bug" report is essentially telling you that there is code out there on github that is broken, and running ESLint over that broken code produces a crash in a lint rule. TL;DR - you can close this issue. It's not actually a problem you need to worry about. |
In similar previous reports I've seen people complaining how IDE's linter integrations keep crashing while a new line is being written. However these were pretty old comments and such IDE plugins have improved a lot since. I think these are the only cases these crashes will affect.
I was expecting this to be fixed on a rule level but this is valid point. Let's close this issue as everything works as expected from ESLint's side. |
Environment
Node version:
v14.17.4
and 16 LTSnpm version:
6.14.14
, yarn1.22.10
Local ESLint version:
8.3.0
Global ESLint version: none
Operating System: Debian 10
What parser are you using?
@typescript-eslint/parser
What did you do?
Configuration
What did you expect to happen?
The
export class extends
should not crash the rule. It should rather report the rule if any problems are detected.What actually happened?
Participation
Additional comments
Crash report: AriPerkkio/eslint-remote-tester#315 (comment)
This does not happen with default espree parser. This is likely caused by typescript-eslint/typescript-eslint#1852 but should be handled by the rule.
The text was updated successfully, but these errors were encountered: