Detect preference for node:-prefixed node core modules#45080
Detect preference for node:-prefixed node core modules#45080andrewbranch merged 1 commit intomicrosoft:mainfrom
node:-prefixed node core modules#45080Conversation
| } | ||
|
|
||
| export const nodeCoreModuleList: readonly string[] = [ | ||
| const unprefixedNodeCoreModuleList = [ |
There was a problem hiding this comment.
This was missing a few entries; I scraped the latest from DefinitelyTyped via
grep -r "declare module ['\"]node:" types/node | sort
| 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.
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.
|
|
||
| sourceFileToPackageName = oldProgram.sourceFileToPackageName; | ||
| redirectTargetsMap = oldProgram.redirectTargetsMap; | ||
| usesUriStyleNodeCoreModules = oldProgram.usesUriStyleNodeCoreModules; |
There was a problem hiding this comment.
Does this get fixed up on subsequent builds? Or does it "stick"?
There was a problem hiding this comment.
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.
There’s a test that shows editing back and forth: https://github.com/microsoft/TypeScript/pull/45080/files#diff-0694f66b155b0b58bf9818822b2ff472fb62409216c1ad39dbdbede5064de2f7R20
DanielRosenwasser
left a comment
There was a problem hiding this comment.
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.