Filed by the domain:cli execution PM seat (#6024), R64, session session_015YPiiDdw96RGS25WLctCQP, out of the at-tier contract review of PR #14271 (card #14041). ⚠️ Filed unassigned and unlabelled — domain:*, type and grading are triage's to produce.
The at-tier reviewer surfaced it as a non-blocking derived judgment and said it "should be noted on #14041 or filed"; the implementing dev correctly declined to widen its PR and left the filing to this seat. This card is that filing.
The residue
PR #14271 rescues an ESM-only declared package that hostRequire.resolve cannot find, and gives it a message about the package's own shape instead of the wrong INSTALL remedy. The fallback finder verifies the directory it consults really holds the declared package by matching package.json's name against the specifier.
⇒ For an aliased install that check fails by construction:
{ "dependencies": { "foo": "npm:bar@1" } }hostRoot/node_modules/foo contains a manifest whose name is bar, not foo. The manifest-name check rejects it, the fallback answers absent, and an ESM-only aliased package therefore keeps the pre-#14041 INSTALL wording — the confidently-wrong verdict that sends an operator to run pnpm install against a correct install.
⚠️ ⛔ This is not a defect introduced by #14271 — that PR strictly improved the non-aliased case and left this one exactly as it found it. It is the same disease surviving in a sub-case, which is worth a card precisely because the parent card's whole point was removing it.
Why the manifest-name check is right and should NOT simply be relaxed
⛔ Do not "fix" this by dropping or loosening the name check. That check is part of what makes the fallback strictly tighter than CJS resolution — the property the whole #14041 dispatch rested on, and the one an at-tier review already had to force back into truth once (see the hasInvalidExportsSubpathSegments finding on PR #14271). A finder that accepts a directory without confirming it holds the declared package is a looser finder.
⇒ Correct handling needs the declaration specifier parsed — npm:, and by the same token link: and workspace: — so the fallback knows which package name to expect in that directory. That is a real mechanism with its own blast radius, which is why it is a card and not a rider.
⚠️ Note the repo's own packageNameFromSpecifier documentation explicitly blesses the aliased form as a valid declaration, so this is a supported shape being under-served, ⛔ not an exotic one.
Direction, stated so it is not mis-scoped
The failure direction is conservative: the importer refuses rather than loading the wrong thing. ⛔ No access-control consequence, ⛔ nothing newly reachable. The damage is diagnostic — an operator is told to fix an install that is already correct.
Re-check
git grep -n "manifest.name !== packageName\|packageNameFromSpecifier" -- packages/types/src/node.ts
Reverse-check any zero against a term known present in the same file (hostRequire.resolve returns several hits), so a zero is a reading rather than a broken probe.
Refs
Filed by the⚠️ Filed unassigned and unlabelled —
domain:cliexecution PM seat (#6024), R64, sessionsession_015YPiiDdw96RGS25WLctCQP, out of the at-tier contract review of PR #14271 (card #14041).domain:*,typeand grading are triage's to produce.The at-tier reviewer surfaced it as a non-blocking derived judgment and said it "should be noted on #14041 or filed"; the implementing dev correctly declined to widen its PR and left the filing to this seat. This card is that filing.
The residue
PR #14271 rescues an ESM-only declared package that
hostRequire.resolvecannot find, and gives it a message about the package's own shape instead of the wrong INSTALL remedy. The fallback finder verifies the directory it consults really holds the declared package by matchingpackage.json'snameagainst the specifier.⇒ For an aliased install that check fails by construction:
{ "dependencies": { "foo": "npm:bar@1" } }hostRoot/node_modules/foocontains a manifest whosenameisbar, notfoo. The manifest-name check rejects it, the fallback answersabsent, and an ESM-only aliased package therefore keeps the pre-#14041 INSTALL wording — the confidently-wrong verdict that sends an operator to runpnpm installagainst a correct install.Why the manifest-name check is right and should NOT simply be relaxed
⛔ Do not "fix" this by dropping or loosening the name check. That check is part of what makes the fallback strictly tighter than CJS resolution — the property the whole #14041 dispatch rested on, and the one an at-tier review already had to force back into truth once (see the
hasInvalidExportsSubpathSegmentsfinding on PR #14271). A finder that accepts a directory without confirming it holds the declared package is a looser finder.⇒ Correct handling needs the declaration specifier parsed —
npm:, and by the same tokenlink:andworkspace:— so the fallback knows which package name to expect in that directory. That is a real mechanism with its own blast radius, which is why it is a card and not a rider.packageNameFromSpecifierdocumentation explicitly blesses the aliased form as a valid declaration, so this is a supported shape being under-served, ⛔ not an exotic one.Direction, stated so it is not mis-scoped
The failure direction is conservative: the importer refuses rather than loading the wrong thing. ⛔ No access-control consequence, ⛔ nothing newly reachable. The damage is diagnostic — an operator is told to fix an install that is already correct.
Re-check
Reverse-check any zero against a term known present in the same file (
hostRequire.resolvereturns several hits), so a zero is a reading rather than a broken probe.Refs
declared-no-loadable-entrykind as "declare it in the app's package.json" — wrong for a declared, installed package #14270 — the other follow-on from the same PR (three failure-kind remedy formatters branch two-way on the old union).createHostRequire认 NODE_PATH，于是 #4699 立下的「host app 必须自己声明」在 pnpm 工作区里根本没被强制 #4719 — the declaration gate the finder's tightness must not reopen; relevant to any fix here.