Skip to content

When resolving from typings cache, handle node code modules #31820

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

Merged
merged 2 commits into from
Jun 12, 2019

Conversation

sheetalkamat
Copy link
Member

Earlier when first time we resolved things like "net", "stream" they would get added to the unresolved imports and typings installer would install the typing for node and project would get updated with it.
After this if one added import that doesn't resolve, we sent request to typings installer with unresolvedImport as that one and say it was invalid import, that would mean that the typings would come back as empty. At this point project would be invalidated and while resolving existing say "net" import in typings cache location we would lookup for "net.d.ts" and other such files which offcourse wont be there. That means now we have error resolving "net" import. But if this was another typing say like lodash it will resolve since it would find lodash/index.d.ts or some such file. So problem arises with these node core modules.
The fix is to identify these module and lookup for "node" instead of "net" just like we do when we install typings when "net" is unresolved import.

Fixes #29865

@sheetalkamat sheetalkamat merged commit a0d164f into master Jun 12, 2019
@sheetalkamat sheetalkamat deleted the nodeModules branch June 12, 2019 17:55
@DanielRosenwasser
Copy link
Member

❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adding a single relative require() call turns other calls into a crazy game of whack-a-mole in JS project with Node
3 participants