Install-script behavior became an explicit repository decision.
CyberChef issue #2639 tracked preparation for npm v12. PR #2682, authored by Zain Nadeem, added an allowScripts policy directly to package.json. The contribution is limited to dependency installation behavior; the existing Docker workflow was intentionally left unchanged.
The policy records which packages need their install-time scripts for the project’s tooling and which known dependency scripts should not run. That moves the decision from an implicit package-manager side effect into reviewable repository configuration.
Allow two required tooling scripts and deny four others.
The merged configuration permits scripts for chromedriver and @nightwatch/nightwatch-inspector. It denies scripts for core-js, core-js-pure, fsevents, and tesseract.js. No application code or dependency versions were changed.
| Policy | Packages |
|---|---|
| Allowed | chromedriver, @nightwatch/nightwatch-inspector |
| Denied | core-js, core-js-pure, fsevents, tesseract.js |
The page does not infer why each denied package exposes a script; the upstream patch establishes only that those scripts were not needed for this project’s installation path.
Exercise installation and the project test suite.
The PR record documents a successful npm ci run under npm 12 and a successful npm test run. The patch contains eight configuration lines in one file, making the validation proportional to the change: verify that dependency installation completes under the target package-manager behavior, then verify the repository’s existing tests.
Dependency execution should be explicit and reviewable.
- Package-manager migrations can surface execution policy that was previously implicit.
- A narrow allow/deny list communicates intent better than permitting every transitive script.
- Configuration-only changes still need both installation and application-level validation.
- Scope control matters: unrelated workflows should remain untouched when the evidence does not require changes.