Repository navigation
Handle npm v12 changes #5795
Description
NPM v12 makes some breaking changes to its default behaviour for improved security.
https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/
Specifically, it won't run npm scripts by default when installing modules. This is good for security, tricky for us.
I've examined the current state of the Node-RED library ecosystem to find there are 72 packages with install scripts. preinstall=14 install=9 postinstall=53. This only covers the top-level module - not the dependency trees. To disable scripts would risk breaking these nodes.
We have two choices.
Enable scripts by default
Essentially, maintain the existing behaviour for our users. This is the easy option; but that doesn't mean its the right option.
Update install workflow to include a script check
There is a good reason for disabling scripts by default. The npm cli will provide ways to approve scripts. We could update the install workflow to handle getting the user's consent before running any scripts. Not straight-forward to do. As far as I can tell, you have to run the npm install then check to see if there are any pending scripts. This will mean the files are on disk and can be loaded - node doesn't block the require/import if the scripts haven't run yet. Should NR refuse to start flows if there are pending scripts? Lots of lifecycle things to consider.
Activity
dceejay commentedon Jun 10, 2026
Can you attach the list ? Is it worth contacting the authors so they can be involved. Either to maybe fix/change, or update docs, deprecate, whatever.
TotallyInformation commentedon Jun 18, 2026
While I appreciate the thought of not breaking things, this is an important change to prevent the supply-chain security issues that have been so prevalent in the npm world right now.
An option might be to add warnings into a release with a target for a 2nd release that blocks?
Jakeshadow commentedon Jun 30, 2026
We've been tracking npm v12 migration across several projects. For Node-RED specifically, the main changes that affect builds:
allowScripts— if your build depends on native module compilation (serialport, bcrypt), add those packages to the allowScripts listworkspace:*replaces git+https referencesA full migration checklist for npm v12 is at installsafe.dev — covers the breaking changes, allowScripts config, CI/CD pipeline updates, and common build failures with fixes.
Happy to help with any specific build errors you're hitting.
knolleary commentedon Jun 30, 2026
@Jakeshadow in the Node-RED context, this isn't about our own local dev pipeline. Node-RED embeds npm as end-users can install one of 1000s of plugins into Node-RED that are packaged as npm modules. We need a workflow that is suitable for end-users of the low-code editor who may never touch the command-line.
Jakeshadow commentedon Jul 3, 2026
We went through this exercise already on a project with a similar dependency surface (~40 native packages). A few findings that might save you time:
On option 1 vs 2: The two aren't mutually exclusive. What worked for us was a phased rollout:
strict-allow-scriptsopt-in flag in your.npmrc. Power users who want security hardening can flip it.On the 72 packages:
npm approve-scripts --allow-scripts-pendingat the Node-RED install root will show only what's actually in the user's tree — not all 72 packages exist in every install. Most users will hit 5-15, not 72.The silent killer:
node-gyp rebuildruns implicitly for any package with abinding.gyp, even without an explicit install script. Those packages won't appear in--allow-scripts-pendingby name — you need to approvenode-gypitself. If you use serialport or any native serial bindings, that's where users will trip first.Refusing to start flows with pending scripts: This is the right UX. Print a clear message: "X packages have pending install scripts. Run: node-red approve-scripts" rather than silently running degraded. Users will blame Node-RED for the breakage otherwise, not npm.
I compiled a full migration guide covering CI/CD, native module edge cases, and monorepo strategies: https://installsafe.dev
hardillb commentedon Jul 3, 2026
@Jakeshadow You clearly have not read/understood Nick's comment, the problem is NOT with the Node-RED project it's self, it is with the fact that at runtime, Node-RED users can trigger the installation of 1000s of 3rd party nodes that may or may not require scripts to function properly.
This in addition to the fact that the average Node-RED user doesn't need to understand anything about npm and how it works.
I'm also not convinced Jake is not an agent.
GogoVega commentedon Sep 15, 2026
We can simplify the workflow using the catalogue: it adds a flag to modules that use scripts. The editor will then adjust the notification message accordingly and add an "Install/Update and approve" button.
For tarballs, we force an installation that allows scripts; since this originates from the user, they bear the responsibility.
We can also modify the library to indicate somewhere that the module uses scripts. Ideally, the module author could also include the reason for doing so.
hardillb commentedon Sep 15, 2026
But we don't know which modules require scripts, the scripts are normally on dependencies, so the only way to know would be to test install every node (regularly in case any dependencies with semver matches change) to discover if they require scripts.
GogoVega commentedon Sep 15, 2026
Yeah,
Since the catalog loads the tarball, it is entirely possible to install the package in a sandbox as well and use
npm query ":attr(scripts, [postinstall])"to check whether it requires scripts.knolleary commentedon Oct 8, 2026
The short term migration may well be to migrate to npm 12 and use the wonderfully named
--dangerously-allow-all-scriptsflag to maintain the existing behaviour. Otherwise we have to solve all the issues presented by this before we can move to npm 12. As it stands, we have outstanding security audit issues with npm 10 (4.x) and npm 11 (current 5.x) because they aren't publishing regular security fixes for the older streams.