-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Conversation
@@ -29,8 +29,9 @@ namespace ts.JsTyping { | |||
return availableVersion.compareTo(cachedTyping.version) <= 0; | |||
} | |||
|
|||
export const nodeCoreModuleList: readonly string[] = [ | |||
const unprefixedNodeCoreModuleList = [ |
There was a problem hiding this comment.
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:"); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There’s a test that shows editing back and forth: https://github.com/microsoft/TypeScript/pull/45080/files#diff-0694f66b155b0b58bf9818822b2ff472fb62409216c1ad39dbdbede5064de2f7R20
There was a problem hiding this 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.
Fixes #43842
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 thenode:
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 thenode:
flavor if it finds somenode:
-prefixed imports/re-exports and no unprefixed ones, if we’re more comfortable with that.