Support npm's allowScripts field in package.json

[calle2010]

Tell us more.

npm 11.17(?) introduced the approve-scripts command which manages the allowScripts field in package.json. See
https://docs.npmjs.com/cli/v11/commands/npm-approve-scripts

Since npm 12 scripts are disabled by default.

Now, when Renovate updates a dependency which is also in allowScripts then it should about it at both places. Otherwise the update may break because a required script is not executed anymore.

[calle2010]

Alternatively, while waiting for Renovate to support that out of the box, is it possible to write a regex rule for this? Perhaps someone has done it already and can post it here...

[jamietanna]

Can you share an example of this in use?

[calle2010]

That is an an example from one of our package.json:

    "allowScripts": {
        "esbuild@0.21.5": true,
        "@sap/hana-client@2.23.27": true,
        "esbuild@0.25.0": true,
        "protobufjs@8.4.2": true,
        "mbt@1.2.27": true,
        "protobufjs@7.6.1": true,
        "sqlite3@5.1.7": true,
        "xsd-schema-validator@0.11.0": true
    }

The packages may be dependencies, devDependencies or, in case of workspaces, be dependencies of workspace packages.

But while working on a custom regex manager I realized that this is not so easy as I thought:

• allowScripts entries must be pinned to the actually resolved version, or not pinned at all, but that defeats the purpose
• in case there are multiple versions in the tree (here: esbuild), then both must be kept in sync
• on lockfile maintenance an update to allowScripts would also be required if any of the allowed packages changes

So Renovate would have to run "npm approve-scripts " to update package.json after the resolved version of an approved package changes.

[jamietanna]

Thanks

IMO, we shouldn't do this by default, in case a package has introduced something malicious, but we can make it an opt-in feature if people would want to allow this to be updated

[calle2010]

I tend to agree. I just discovered npm post-upgrade-task and wondered if I should integrate "npm approve-scripts --allow-scripts-pending" here, failing and writing a PR comment if upgrades are pending.

But then, this should probably be part of our build pipeline anyways to also capture other instances of dependencies introduced without decision on the allowScripts.

So I think I take back this idea. Renovate should not manage allowScripts.

[WikiRik]

Opt-in would be fine. Malicious code can also be added outside of the scripts.

[ddbtrmatic]

npm deny-scripts can be used to block scripts for a dependency. I believe this includes all future versions of that dependency as well. The way I see this tool being useful is renovate will propose the update, and then check the lists

a. If a script has been allowed, it makes sense to propose updating the allowance to include the next version. A malicious script could sneak in, but the npm cooldown period helps prevent that issue as well. It probably makes sense to make this opt-in so users have full control and are aware of the risks.
b. If a script has been denied, then renovate will not propose adding the script to the approved scripts list. Maybe the MR description can even include some informational text for this scenario.