-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Reduce number of fs.stat call for files under node modules #52695
Comments
I noticed this in September and asked @andrewbranch about this:
|
I thought about this more and decided having these files would be such an antipattern that I’m fine to deviate from Node’s CJS algorithm here. I pitched it to the team and nobody had objections. Just forgot to follow through. So yes, we can almost certainly avoid making these calls. |
Similar case: when there's an import such as
Can we skip these checks for |
Yeah, I think so. We probably shouldn’t do directory searches for anything that looks like an absolute URI (#35749) |
or in @types. Although the node module resolution algorithm looks for .js files there, they would never be there in correctly configured node_modules. So it should be safe to skip *.ts, *.js, *.tsx, etc. Also skips looking for files directly in node_modules/@types. Fixes microsoft#52695
Bug Report
🔎 Search Terms
Problem
While working on web project wide IntelliSense, I noticed that TS makes a number of
fs.statSync
calls for files stored under the global typings cache. At least some of these calls seem to be unnecessary, such as here where we check for files calledmkdirp.ts
,mkdirp.tsx
,mkdirp.d.ts
directly undernode_modules
:I don't think these specific files would ever exist, would they?
These calls are relatively fast on desktop but do have more of an overhead on web. Even on desktop, I see around 250ms total spent on all the stat calls when starting TS Server in a simple project
Can we avoid making these calls?
The text was updated successfully, but these errors were encountered: