Skip to content
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

Detect preference for node:-prefixed node core modules #45080

Merged
merged 1 commit into from
Jul 19, 2021

Conversation

andrewbranch
Copy link
Member

Fixes #43842

  1. It was actually really easy and cheap to detect the presence of node: module specifiers as we build the program, so this does use other files as a backup heuristic, despite my hesitance about that in the design meeting. It currently prefers the node: versions if it sees any imports/re-exports of that flavor in non-node_modules, non-declaration files. It would be trivial to change that to a more conservative strategy of preferring the node: flavor if it finds some node:-prefixed imports/re-exports and no unprefixed ones, if we’re more comfortable with that.
  2. The first recognized node core module import in a file sets the preferred style for that file. Other files are only considered for files that have no node core module imports yet.
  3. For completions, only the preferred style is shown. For codefixes, both styles are shown, but the preferred style is sorted higher. (There is a precedent for codefixes offering a more granular and complete set of modules to import from.)

@typescript-bot typescript-bot added Author: Team For Milestone Bug PRs that fix a bug with a specific milestone labels Jul 16, 2021
@@ -29,8 +29,9 @@ namespace ts.JsTyping {
return availableVersion.compareTo(cachedTyping.version) <= 0;
}

export const nodeCoreModuleList: readonly string[] = [
const unprefixedNodeCoreModuleList = [
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was missing a few entries; I scraped the latest from DefinitelyTyped via

grep -r "declare module ['\"]node:" types/node | sort

@@ -2327,6 +2330,9 @@ namespace ts {
// only through top - level external module names. Relative external module names are not permitted.
if (moduleNameExpr && isStringLiteral(moduleNameExpr) && moduleNameExpr.text && (!inAmbientModule || !isExternalModuleNameRelative(moduleNameExpr.text))) {
imports = append(imports, moduleNameExpr);
if (!usesUriStyleNodeCoreModules && currentNodeModulesDepth === 0 && !file.isDeclarationFile) {
usesUriStyleNodeCoreModules = startsWith(moduleNameExpr.text, "node:");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems kind of unimportant here whether what follows node: is actually something we recognize in our list, particularly as this PR shows we have neglected to keep the list fully up to date. I do use the list in the single-file analysis so we know we can stop looking at more module specifiers when we see an unprefixed one like fs or path.

@@ -1635,6 +1637,7 @@ namespace ts {

sourceFileToPackageName = oldProgram.sourceFileToPackageName;
redirectTargetsMap = oldProgram.redirectTargetsMap;
usesUriStyleNodeCoreModules = oldProgram.usesUriStyleNodeCoreModules;
Copy link
Member

@DanielRosenwasser DanielRosenwasser Jul 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this get fixed up on subsequent builds? Or does it "stick"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you got it. It gets reused if resolution isn’t going to happen in the next program.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@DanielRosenwasser DanielRosenwasser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved if it's indeed the case that

usesUriStyleNodeCoreModules = oldProgram.usesUriStyleNodeCoreModules;

gets fixed up in later passes.

@andrewbranch andrewbranch merged commit 36225c3 into microsoft:main Jul 19, 2021
@andrewbranch andrewbranch deleted the feature/43842 branch July 19, 2021 16:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Milestone Bug PRs that fix a bug with a specific milestone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Figure out how to deal with annoying node: prefix in auto-imports from @types/node
4 participants