Maintenance: Prepare for npm v12 install-script allowlist (allowScripts opt-in)

[svozza]

Summary

npm v12 (estimated July 2026) flips three npm install defaults from opt-out to opt-in. These are already live as warnings in npm 11.16.0+:

1. allowScripts off — dependency install scripts (preinstall/install/postinstall) won't run unless explicitly allowlisted in package.json.
2. --allow-git none — git dependencies won't resolve.
3. --allow-remote none — remote/tarball dependencies won't resolve.

Of these, only #1 affects this repo. Our lockfile contains no git or remote/tarball dependencies (everything resolves from registry.npmjs.org or local workspaces), so #2 and #3 are non-issues.

For #1, exactly three dependency packages run install scripts (confirmed via npm approve-scripts --allow-scripts-pending):

Package	Script	Role	Action
esbuild@0.28.0	postinstall	our bundler for layers/packages/testing/examples/app	approve
protobufjs@7.5.8	postinstall	transitive under kafka's @valkey/valkey-glide	approve
fsevents@2.3.3	node-gyp native, macOS-only optional file-watching	all our devs develop on macOS, so this affects local builds	approve

Why is this needed?

Once npm v12 ships, installs without an allowlist will silently skip these postinstall scripts. Skipping esbuild and protobufjs postinstall would break bundling and the kafka transitive dependency; skipping fsevents would degrade local file-watching for our developers, who all work on macOS. Committing the allowlist to the root package.json now is the portable fix — it works regardless of how deps are installed, including CI, which installs via the external composite action aws-powertools/actions/.github/actions/cached-node-modules.

Consumers of our published packages are unaffected. None of the workspace packages (packages/*, layers, examples/*) declare preinstall/install/postinstall/prepare scripts, so @aws-lambda-powertools/* installs cleanly under npm v12 with zero action required from users.

Which area does this relate to?

Automation, Governance

Solution

Once on npm 11.16+, run from the repo root (the command is workspace-unaware by design — it writes to the package.json of wherever you run it, which is why root is correct: one allowlist covers all workspaces):

npm approve-scripts --no-allow-scripts-pin esbuild fsevents
npm approve-scripts protobufjs   # pinned is fine; entry dies with valkey-glide's next protobufjs major

Commit the resulting change to root package.json. Target: land before npm v12 ships (~July 2026).

Two notes for whoever picks this up:

• Version-pinned approvals vs. dependabot churn. By default approve-scripts pins the exact version (e.g. esbuild@0.28.0), but dependabot bumps esbuild and fsevents regularly and won't update the allowlist pin — so each bump would strand a stale pin and (under v12) silently re-block the script. For these we use --no-allow-scripts-pin (name-only, any version). The trade-off is trusting future versions' scripts sight-unseen, but a perpetually-stale pin protects nothing either.
• protobufjs is on its way out, so pinning it is fine. Only the nested protobufjs@7.5.8 (under @valkey/valkey-glide) has a postinstall; the root protobufjs@8.6.0 has no install script (removed in v8). When valkey-glide moves to protobufjs 8, this approval entry becomes dead weight and can be removed.

Reference: GitHub changelog "Upcoming breaking changes for npm v12" (2026-06-09).

Acknowledgment

• This request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages?

---

Please react with 👍 and your use case to help us understand customer demand.