fix: write registry allowScripts keys under install-strategy=linked - #9941
fix: write registry allowScripts keys under install-strategy=linked#9941manzoorwanijk wants to merge 1 commit into
Conversation
fc5be25 to
4b40b17
Compare
|
@reggi this probably needs a label for v11 backport. |
|
Thanks for the quick fix! However it doesn't add the version number in // expected:
"allowScripts": {
"esbuild@0.28.1": true
}
// actual
"allowScripts": {
"esbuild": true
}I installed the fix locally using a local copy of the repo with this branch: ➜ npm -v
11.19.0
➜ node npm/bin/npm-cli.js -v
12.0.2Then, both of these commands gave me the output above: ➜ node npm/bin/npm-cli.js install-script approve esbuild@0.28.1
➜ node npm/bin/npm-cli.js install-script approve esbuild |
It works perfectly fine Screen.Recording.2026-09-01.at.3.15.02.PM.mov
|
Let's chalk it up to me not setting up the npm version from this PR properly |
|
I see that #9940 has a fix solely for the deduping (same fix as you have in |
Yes, it covers many other cases as well. |
Under
install-strategy=linked,npm install-scripts approve <pkg>wrote verbose, duplicatedfile:entries pointing intonode_modules/.store(one per incoming symlink depth) instead ofname@versionpins, and those store-path entries never matched at install time.There are two root causes.
In
findNodesForArgs(allow-scripts-cmd.js), positional args matched everyLinkpointing at the store package; each Link's relativefile:.store/...resolved spec became its own policy key and could even strip the correct pin as stale.In
script-allowed.js, a store package has noedgesIn(they land on its incoming Links), soisRegistryNoderefused registry keys, andls, the post-install advisory, and prune treated a correctname@versionentry as matching nothing.The fix skips
Linknodes when matching positional args, mirroringcollectUnreviewedScriptsand prune, so approvals key off the real package's trusted registry identity.isRegistryNodeandnameFromEdgesnow delegate edge-based checks to a link target's incoming Links, which also coversomit-lockfile-registry-resolved(approve by name, like the hoisted #9558 path).resolvedSourceSpecsno longer fabricatesfile:specs from links into the store, so store packages are never keyed by store paths and prune cleans up the buggy entries while keeping the valid pin.References
Fixes #9939