Enhancement: ban wide globs in parserOptions.useProjectService.allowDefaultProjectForFiles
#8923
Closed
4 tasks done
Assignees
Labels
accepting prs
Go ahead, send a pull request that resolves this issue
enhancement
New feature or request
locked due to age
Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing.
package: typescript-estree
Issues related to @typescript-eslint/typescript-estree
Milestone
Comments
|
For visibility: note that #7752 already added in a check that if a file is available in the project service, it shouldn't also be in the default project list. +1 to this issue for adding in more checks. |
3 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Before You File a Proposal Please Confirm You Have Done The Following...
Relevant Package
typescript-estree
My proposal is suitable for this project
Description
We should lock down this API to start with and widen it as needed.
In particular we know that the default project can and will cause perf issues if used incorrectly.
EG if it matches too many files it'll cause dramatic slowdowns.
Based on what @JoshuaKGoldberg has found - it'll create one new
ts.Programper file. This process is slow - but given the number of files is small then it shouldn't impact things too badly. If someone does something dumb like pass a glob like**/*.tsto match their entire project then their run will be stupidly slow for no good reason.In a nutshell - the motivation against this was the entire reason we moved away from "default programs" back in v2.0.0. Because people accidentally fell into the default program and their lint runs slowed to a crawl because of them.
We should do the following:
(1) ban obviously dumb globs like
*,**/*,**/*.*, etc. Essentially any glob that doesn't match the regex\wshould be banned with an explicit failure like(2) ban too many files matching the glob. We should pick a sensible default that we think won't noticably impact the run performance (say, 5 files) and if the lint run matches against more than that many files - we should explicitly fail like
Additional Info
No response
The text was updated successfully, but these errors were encountered: