⚡️ Performance: Don't open client files unnecessarily for project service #8427
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.
performance
Issues regarding performance
Milestone
Uh oh!
There was an error while loading. Please reload this page.
Before You File a Proposal Please Confirm You Have Done The Following...
Relevant Package
typescript-estree
My proposal is suitable for this project
Description
As reported by @yepitschunked in #8322 (thanks! ❤️🔥):
I like the idea of not calling
service.openClientFile
unnecessarily.useProgramFromProjectService
is indeed called always ifparseSettings.EXPERIMENTAL_useProjectService
is true:typescript-eslint/packages/typescript-estree/src/parser.ts
Lines 48 to 53 in 5a1e85d
Logs in #8424 show that opening files with a warmed-up project service to take a few ms per file. That can really add up in projects with many files.
#8322 (comment) shows that avoiding calling
service.openClientFile
on files that don't ask for type checking can speed up service-type-checked linting to be on par with traditional type-checked linting. ⚡Additional Info
Note that I'm not yet convinced that #8322's starting approach is the correct one. That approach only calls
openClientFile
on files with type-checked linting enabled. But some users enable type information on all files despite only using it in some. And, heck, type-checked rules only use type checking conditionally - and try to avoid calling it if they can bail out early. So gatingopenClientFile
on whether a file wants type information can still allow files through the gate unnecessarily.An alternative possibility might be to avoid opening the client file altogether until
getParserServices
is called within a lint rule. I think that's the best possible strategy for avoiding unnecessaryopenClientFile
calls. But that might require moving all the type generation logic togetParserServices
... which might be good in general? Investigation required.The text was updated successfully, but these errors were encountered: