-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Glob pattern in parser's option "project" slows down linting #2611
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
Comments
So looking at the glob you're using - it's always going to be slow.
OTOH if you use a better glob - like the one we use in our project: Log dump with good glob
There will be a non-zero cost to globs OFC - globs require work to parse, expand and match against the file system.
This is an unfortunate problem that we cannot work around. The first two cases can be treated the same (the lint runs and then the instance dies), but the IDE case is special. The IDE is persistent, and reuses the parser again and again. This means the parser state is reused again and again. Most parsers don't worry about this because they're stateless. But our parser is stateful because it's too expensive to recompute the TS type info. This means that our parser has to be built to handle the cases of:
When the ESLint config changes (i.e. you change This is why we have to recompute the glob every single lint run. |
Yes, this is why I suggested to update the docs as this seems like known limitation and is hard to fix on parser side. |
An issue is important to understand the problem you're having and what the solutions are. The problem here isn't that globs are slow - the problem is that unnecessarily wide globs are slow. I'm okay if you add an FAQ article about appropriate globs and the slowness of |
Absolutely, discussion about the issue is important. FAQ already has few notes around wide globs in "My linting feels really slow", we could maybe extend that. But we should also explicitly mention that glob needs to be recomputed for every parsed file. This is known limitation of parser but I don't think users generally expect that. I was thinking about introducing a cache with reasonable expiration time but this seems overcomplicated and fragile. How would you feel about collecting stats and maybe warning user in runtime when glob resolutions are slow (not yet sure about what metric to use) and suggesting to use less wide pattern(s) or path(s)? Thanks. |
Yeah, I wish that the there was a way to do these queries at the filesystem level and have them cached by the filesystem. Ultimately to make this work properly, we'll need to help ESLint evolve in this space so that it can tell us when a lint run starts and stops.
I think this is fine to do - as long as we implement a way to turn off the log as well (similar to how we have |
Repro
Expected Result
Linting with glob pattern should take similar time as when tsconfig.json is passed directly via relative path.
Output:
Actual Result
Parser seems to be resolving glob pattern for every linted file individually which significantly increases time to finish the scan.
Output:
Additional Info
Until the issue is investigated and fixed we were suggesting adding a note in the documentation to warn users - #2602
Versions
@typescript-eslint/typescript-estree
4.3.0
TypeScript
4.0.2
node
14.6.0
The text was updated successfully, but these errors were encountered: