Cache importFixes/fixMissingImport in getCodeFixes requests
See original GitHub issueSearch Terms
- getCodeFixes cache
Suggestion
In tsserver, the completionInfo
request benefits from a cache of import suggestions.
Could the getCodeFixes
request be extended to use a suggestion imports cache as well?
Both call codeFixes.forEachExternalModuleToImportFrom
, which can be very slow in a large project. Thanks!
Checklist
My suggestion meets these guidelines:
- This wouldn’t be a breaking change in existing TypeScript/JavaScript code
- This wouldn’t change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- This feature would agree with the rest of TypeScript’s Design Goals.
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (7 by maintainers)
Top Results From Across the Web
No results found
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
That’s great to hear! It seems like this issue is lower priority now, though there are definitely still worthwhile improvements that could be made. I’m going to bump it to the backlog for now.
@andrewbranch So I was following #40584, but didn’t think it applied to my project since it uses yarn instead of pnpm. I could not have been more wrong. After pulling your change in #42150,
getCodeFixes
finishes in ~650ms. That’s a 14x improvement from the ~9s previously.Thank you so much! 🎉
This project uses yarn workspaces to symlink its ~500 monorepo packages into
node_modules
, so that’s likely why the fix ended up carrying over.I’ll leave the status of this issue up to the discretion of the TypeScript team. (Feel free to close it.) When I was filing it, I never expected
getCodeFixes
to get that drastic of a performance improvement and thought it should be at least cached. But that cache isn’t necessary now.