Let AutoImportProviderProject resolve JS when allowJs and maxNodeModulesJsDepth allows#45524
Conversation
…lesJsDepth allows
|
|
||
| /* @internal */ | ||
| export function tryResolveJSModule(moduleName: string, initialDir: string, host: ModuleResolutionHost): string | undefined { | ||
| export function tryResolveJSModule(moduleName: string, initialDir: string, host: ModuleResolutionHost) { |
There was a problem hiding this comment.
This function was never used before now 👀
| setTimeout(callback: (...args: any[]) => void, ms: number, ...args: any[]): any { | ||
| // eslint-disable-next-line no-restricted-globals | ||
| return setTimeout(callback, ms, args); | ||
| return setTimeout(callback, ms, ...args); |
There was a problem hiding this comment.
At least a 5-year-old bug right here
|
Under what circumstances is |
|
@amcasey any time a user sets it in a project config file, but perhaps most relevantly, it’s one of the options VS Code sends for all inferred JS projects, so it’s set for all JS users who don’t have any config files. |
amcasey
left a comment
There was a problem hiding this comment.
The change looks correct, but let's keep an eye on the perf impact. Does the existing auto-imports telemetry give us enough information to filter to unconfigured JS workspaces?
|
I don’t think so—there’s nothing in the completions telemetry that would indicate what kind of project we’re in, but maybe there’s something from another event that we could join on the session id? |
|
Following up on telemetry separately. We need a small change in TS, but more importantly we’re chasing down an issue with GDPR classification integration between TS and VS Code. |
…lesJsDepth allows (microsoft#45524) * Let AutoImportProviderProject resolve JS when allowJs and maxNodeModulesJsDepth allows * Simplify function
Fixes #45109 (the bug part of it—might open a new issue to track the feature idea)