Is there an existing issue for this?
This issue exists in the latest npm version
This is not just a request to bump a dependency for a CVE
Current Behavior
I have a local tgz package (a local fork of electron-winstaller) with install scripts in devDependencies. npm v12.0.2 always blocks its install scripts no matter what I have added in allowScirpts inside package.json. I have tried
{
"allowScripts": {
"electron-winstaller": true,
"electron-winstaller@5.3.0": true,
"file:path/to/electron-winstaller-5.3.0.tgz": true,
"file:C:\\absolute\\path\\to\\electron-winstaller-5.3.0.tgz": true,
"file:C:/absolute/path/to/electron-winstaller-5.3.0.tgz": true
}
}
which still results in
npm warn install-scripts 1 package had install scripts blocked because they are not covered by allowScripts:
npm warn install-scripts electron-winstaller@5.3.0 (install: node ./script/select-7z-arch.js)
npm warn install-scripts
npm warn install-scripts Run `npm install-scripts ls` to review, or `npm install-scripts approve <pkg>` to allow.
Below is Claude's analysis:
npm 12's new install-scripts gate matches policy keys against node.resolved using npm-package-arg (npa). For a file: dependency, your lockfile stores the relative form (file:path/to/electron-winstaller-5.3.0.tgz), but when npm loads the actual installed tree (what install/install-scripts ls actually checks against), it re-derives resolved through consistentResolve() (consistent-resolve.js:22-26), which on Windows produces:
file:C:\absolute\path\to\electron-winstaller-5.3.0.tgz
— absolute, with backslashes, "file:" glued directly onto them.
The matcher (script-allowed.js:330-333) requires an exact string match against a key parsed by npa(). But npa() always normalizes its saveSpec to forward slashes, and its fetchSpec never carries the file: prefix.
Expected Behavior
npm should allow the scripts to run. Ideally with just the package name match, or relative path match.
Steps To Reproduce
run npm install to install a local tgz npm package with install scripts on Windows.
Environment
- npm: 12.0.2
- Node.js: 22.23.2
- OS Name: Windows 10
- System Model Name: Intel NUC
- npm config:
strict-ssl = false
allow-git = "all"
min-release-age = 7
Is there an existing issue for this?
This issue exists in the latest npm version
This is not just a request to bump a dependency for a CVE
Current Behavior
I have a local tgz package (a local fork of electron-winstaller) with install scripts in devDependencies. npm v12.0.2 always blocks its install scripts no matter what I have added in allowScirpts inside package.json. I have tried
{ "allowScripts": { "electron-winstaller": true, "electron-winstaller@5.3.0": true, "file:path/to/electron-winstaller-5.3.0.tgz": true, "file:C:\\absolute\\path\\to\\electron-winstaller-5.3.0.tgz": true, "file:C:/absolute/path/to/electron-winstaller-5.3.0.tgz": true } }which still results in
Below is Claude's analysis:
npm 12's new install-scripts gate matches policy keys against node.resolved using npm-package-arg (npa). For a file: dependency, your lockfile stores the relative form (file:path/to/electron-winstaller-5.3.0.tgz), but when npm loads the actual installed tree (what install/install-scripts ls actually checks against), it re-derives resolved through consistentResolve() (consistent-resolve.js:22-26), which on Windows produces:
file:C:\absolute\path\to\electron-winstaller-5.3.0.tgz
— absolute, with backslashes, "file:" glued directly onto them.
The matcher (script-allowed.js:330-333) requires an exact string match against a key parsed by npa(). But npa() always normalizes its saveSpec to forward slashes, and its fetchSpec never carries the file: prefix.
Expected Behavior
npm should allow the scripts to run. Ideally with just the package name match, or relative path match.
Steps To Reproduce
run
npm installto install a local tgz npm package with install scripts on Windows.Environment