Will Node 26 eventually ship with npm 12? Or will that wait until Node 27?

wondering the same, also can consider manually updating NPM to v12 in Node 24 if needed

We are hoping to backport npm 12 to Node 24 & 26. Though, ultimately, that decision lies with the Node release team. You can follow the discussion here: nodejs/Release#1161

hard agree

IMO The env var winning is a feature, not a gap. You set npm_config_ignore_scripts globally, which sits at the env level, and a project's package.json can't override that with allowScripts. Env outranks project, and ignore-scripts beats allowScripts regardless. If a user says "run nothing," a repo shouldn't be able to switch its own scripts back on.

Old npm keeping the blanket block while new npm uses the allowlist, is being discussed in npm/cli#9450. The migration half already landed: approve-scripts --allow-scripts-pending now lists packages even under ignore-scripts=true, so you can build the allowlist without dropping your global block first.

strict-allow-scripts is not the v12 default and won't be.

This is not what the "Try the breaking behavior now" section above says though.

I'll get that updated.

and strict is mentioned as the way to opt in for 11 because the more nuanced approach of the allowlist isn't supported there?

Yeah, 11 does enforce the true/false record keeping in allowScripts. But, at its core, the breaking change between 11 and 12 is that in 11 unreviewed scripts (absent from allowScripts) still run and in 12 they don't.

strict-allow-scripts does bring that breaking behaviour forward to 11, but it's even stricter than what 12 will be.

Thanks for this writeup and for the clarifications throughout the thread — particularly the confirmation that strict-allow-scripts is not the v12 default, and that Dependabot does not touch allowScripts. Both of those are important distinctions that deserve more prominence in the original post.

Pulling together a few threads from the discussion, I think there are a few connected follow-on priorities worth calling out. One note upfront: reading through the 12.0.0-pre.1 release notes, several real improvements have already landed — the ignore-scripts=true + --allow-scripts-pending listing bug is fixed, allowScripts is now enforced across prune, dedupe, uninstall, audit fix, and link, and bundled dependency hardening is in. That's meaningful progress. The gaps below are about what's still open.

The real gap in --allow-scripts-pending

The thread confirmed that the pending output shows the lifecycle script values from package.json. So if the script is node install.js, that is what you see. What you do not see is what is inside install.js, what it requires, what those files do, or whether any of them perform network calls, invoke child_process, read credentials from process.env, or write outside the package directory.

This is also visible in how arborist works: install scripts are read from actual files on disk. The code path runs through real files — install.js, setup.js, download.js, whatever the chain leads to. Those files are there. They are just not surfaced in the pending output.

@kimballa described this from real testing: a transitive dependency's install.js that just requires another file means opening an IDE and tracing a call stack through unfamiliar code. That is not just a workflow gap — it is a workflow that often will not happen in practice. The approval can easily become "node install.js — looks reasonable, approve."

This is the core limitation. --allow-scripts-pending identifies which packages need attention. It does not fully help answer: what exactly am I approving?

A review-report mode would help. Not to prove a script is safe, but to surface the obvious execution path so the decision is informed rather than reflexive. At minimum, that could include:

• lifecycle script name and exact command value
• local files directly referenced by that command, such as install.js, setup.js, shell scripts, or binaries
• obvious local files those scripts reference, where statically detectable
• risk signals such as child_process, eval, network calls, credential/env access, or writes outside the package directory
• a diff against the previously approved version's lifecycle scripts and referenced files, where one exists

The response was to open an issue in npm/cli or npm/rfcs, which makes sense — and I plan to do that. This feels like the feature that determines whether an allowScripts approval becomes a meaningful security decision or a renamed click-through.

Dev machine vs. CI/CD

The guidance that emerged here — do not necessarily run strict-allow-scripts on dev machines, but do run it in CI — is practical given the chicken-and-egg problem with new package installs under strict mode.

But the security implication is worth stating explicitly in the docs:

In the recommended local workflow, approvals are often created under the soft-skip model, then enforced by CI under strict mode. That means CI strict enforcement is only as trustworthy as the approval that was committed. The approval step may happen when a developer is simply trying to unblock a local install, with the least context and the most pressure to move forward.

That is not an argument against the recommended split — it is probably the right operational model. But it means the review-report feature above is not just nice-to-have; it is what makes the approval step trustworthy enough to rely on.

One additional note on urgency: the npm team is actively pursuing backporting npm 12 to Node 24 and Node 26 (see nodejs/Release#1161). If that lands, these defaults reach the two active LTS lines rather than waiting for Node 27. That is the right call for security, but it also means the tooling needs to be ready for a much larger audience on a shorter timeline.

Version bump vs. new script

Something @kimballa raised that deserves more attention: pending output should distinguish between very different cases:

• a version bump where the lifecycle script is unchanged
• a version bump where the lifecycle script changed
• a package that previously had no lifecycle script and now does

Those are very different risk signals. If they all appear as the same kind of pending approval, developers are pushed toward reflexive approve/reject on the package name alone.

Even simple labels would help:

[new lifecycle script]
[lifecycle script changed since last approved version]
[lifecycle script unchanged since last approved version]

That would make the approval list easier to triage and less likely to collapse into bulk approval.

Bots and AI agents modifying allowScripts

The thread confirmed that Dependabot does not currently touch allowScripts, which is the right behavior.

The broader issue is that IDE extensions, AI coding agents, and automated "fix the build" workflows already modify package.json. As allowScripts becomes a normal part of that file, there will be natural pressure for tools to resolve pending approval warnings by updating the allowlist — because resolving warnings is what they are built to do.

The docs should state explicitly that allowScripts is a code-execution permission list, not ordinary package metadata. Automated modification of it should be treated as security-sensitive.

Because allowScripts lives inside package.json, CODEOWNERS alone may not be enough to protect it at field level. A CI check may be needed to flag PRs that expand allowScripts, remove denyScripts entries, change false to true, or add name-only approvals without a deliberate human approval commit.

None of this is a v12 blocker. The core change is the right call and a real improvement to the ecosystem's default security posture, and the pre.1 progress shows the team is actively tightening the edges.

These feel like the layer that determines whether allowScripts becomes a real audit trail or a list developers learn to clear as quickly as possible. The foundation is solid — I plan to open an issue in npm/cli to track the review-report idea specifically, and will link back here when that's up.

See npm/rfcs#897

Also see the work in vbjay/npm-cli#1. Copilot keeps mucking with the description and title but it's my attempt at adding the reporting to npm. Eventually when I get this to where I see it I will merge into finalized pr branch that I can submit to npm repo. Feel free to review or send feedback. If you feel the rfc needs work send feedback on that too. I'm just kicking the ball around trying to showcase my vision on the reporting.

Example from my smoke test in the work

✅ PASS — approve-scripts smoke report

All packages with lifecycle scripts are correctly identified as pending approval.

{
  "install": "node ./scripts/install.js"
}

{
  "install": "node-gyp rebuild"
}

{
  "postinstall": "node install.js"
}

{
  "packages": [
    {
      "name": "@sentry/cli",
      "version": "1.77.3",
      "location": "node_modules/@sentry/cli",
      "approvalStatus": "pending",
      "dependencyType": "transitive",
      "introducedBy": [
        [
          "allow-scripts-demo",
          "@sentry/webpack-plugin@1.21.0",
          "@sentry/cli@1.77.3"
        ],
        [
          "allow-scripts-demo",
          "ember-cli-deploy-sentry-cli@3.1.0",
          "@sentry/cli@1.77.3"
        ]
      ],
      "lifecycleScripts": {
        "install": "node ./scripts/install.js"
      },
      "referencedFiles": [
        {
          "path": "scripts/install.js",
          "reason": "referenced by lifecycle script: `install`",
          "sha256": "f693c46a257952dd4f4c76cc7f7c3ab4536599e2ad0548a27d7a8183536f6c93",
          "sizeBytes": 839,
          "signals": [
            "reads-process-env",
            "network-access",
            "writes-outside-package",
            "requires-local-file"
          ],
          "references": [
            "js/install.js"
          ]
        },
        {
          "path": "js/install.js",
          "reason": "required by ./scripts/install.js",
          "sha256": "a15ee1c659fe9f3368eb99cde08f424f4b44cf963fa8b9c6427458a970a95e2c",
          "sizeBytes": 8907,
          "signals": [
            "reads-process-env",
            "network-access",
            "writes-file",
            "writes-outside-package",
            "external-url",
            "requires-local-file"
          ],
          "references": [
            "js/helper.js",
            "package.json",
            "js/logger.js"
          ]
        },
        {
          "path": "js/helper.js",
          "reason": "required by ./js/install.js",
          "sha256": "76f511fd75cf4cb2afc251a9ba62ecbbc8aeb571233d13e4958a4d82f2a1359c",
          "sizeBytes": 6128,
          "signals": [
            "uses-child-process",
            "reads-process-env"
          ],
          "references": []
        },
        {
          "path": "package.json",
          "reason": "required by ./js/install.js",
          "sha256": "8ab62ccee75956b622201e5d16bccec41c6883b0771146310bc6ded8e26f5a9d",
          "sizeBytes": 1903,
          "signals": [
            "external-url"
          ],
          "references": []
        },
        {
          "path": "js/logger.js",
          "reason": "required by ./js/install.js",
          "sha256": "d7d63601d3347efc93425f4f93049cfb9ed2b9ead1dce662c9c1bed3cba302e0",
          "sizeBytes": 253,
          "signals": [],
          "references": []
        }
      ],
      "nativeBuildInfo": null,
      "changeClassification": {
        "status": "new",
        "previousApprovedVersion": null
      },
      "riskSummary": [
        "makes network requests",
        "may write outside the package directory",
        "uses child_process (can spawn external commands)"
      ],
      "suggestedReviewFocus": [
        "confirm what remote endpoints are contacted and whether responses are verified",
        "confirm whether file writes are scoped to the package directory",
        "confirm what external commands are executed and whether they are constrained"
      ]
    },
    {
      "name": "canvas",
      "version": "2.11.2",
      "location": "node_modules/canvas",
      "approvalStatus": "pending",
      "dependencyType": "direct",
      "introducedBy": [
        [
          "allow-scripts-demo",
          "canvas@2.11.2"
        ]
      ],
      "lifecycleScripts": {
        "install": "node-gyp rebuild"
      },
      "referencedFiles": [
        {
          "path": null,
          "reason": "inline lifecycle script: `install`",
          "sha256": null,
          "sizeBytes": null,
          "signals": [
            "native-build"
          ],
          "references": []
        }
      ],
      "nativeBuildInfo": {
        "sha256": "684e491f30b36151ebc98bef3eef17a1078b1227003ceaea6fec355441813666",
        "targets": [],
        "parseError": "Expected ',' or ']' after array element in JSON at position 680 (line 26 column 5)"
      },
      "changeClassification": {
        "status": "new",
        "previousApprovedVersion": null
      },
      "riskSummary": [
        "builds native code (node-gyp / binding.gyp)"
      ],
      "suggestedReviewFocus": [
        "review the binding.gyp targets — inspect native source files for unsafe C/C++ operations, verify external library dependencies are expected, and check platform-specific conditions"
      ]
    },
    {
      "name": "esbuild",
      "version": "0.20.0",
      "location": "node_modules/esbuild",
      "approvalStatus": "pending",
      "dependencyType": "direct",
      "introducedBy": [
        [
          "allow-scripts-demo",
          "esbuild@0.20.0"
        ]
      ],
      "lifecycleScripts": {
        "postinstall": "node install.js"
      },
      "referencedFiles": [
        {
          "path": "install.js",
          "reason": "referenced by lifecycle script: `postinstall`",
          "sha256": "a061231445c23fe8ed9f1f102a639adc796982541b3cc5976beb7544dca24a77",
          "sizeBytes": 10963,
          "signals": [
            "uses-child-process",
            "reads-process-env",
            "network-access",
            "external-url"
          ],
          "references": []
        }
      ],
      "nativeBuildInfo": null,
      "changeClassification": {
        "status": "new",
        "previousApprovedVersion": null
      },
      "riskSummary": [
        "uses child_process (can spawn external commands)",
        "makes network requests"
      ],
      "suggestedReviewFocus": [
        "confirm what external commands are executed and whether they are constrained",
        "confirm what remote endpoints are contacted and whether responses are verified"
      ]
    }
  ]
}

Asked github copilot Claude Sonnet 4.6 to review the lifecycle scripts from this json.

{
  "packages": [
    {
      "name": "@sentry/cli",
      "version": "1.77.3",
      "location": "node_modules/@sentry/cli",
      "approvalStatus": "pending",
      "dependencyType": "transitive",
      "introducedBy": [
        [
          "allow-scripts-demo",
          "@sentry/webpack-plugin@1.21.0",
          "@sentry/cli@1.77.3"
        ],
        [
          "allow-scripts-demo",
          "ember-cli-deploy-sentry-cli@3.1.0",
          "@sentry/cli@1.77.3"
        ]
      ],
      "lifecycleScripts": {
        "install": "node ./scripts/install.js"
      },
      "referencedFiles": [
        {
          "path": "scripts/install.js",
          "reason": "referenced by lifecycle script: `install`",
          "sha256": "f693c46a257952dd4f4c76cc7f7c3ab4536599e2ad0548a27d7a8183536f6c93",
          "sizeBytes": 839,
          "signals": [
            "reads-process-env",
            "network-access",
            "writes-outside-package",
            "requires-local-file"
          ],
          "references": [
            "js/install.js"
          ]
        },
        {
          "path": "js/install.js",
          "reason": "required by ./scripts/install.js",
          "sha256": "a15ee1c659fe9f3368eb99cde08f424f4b44cf963fa8b9c6427458a970a95e2c",
          "sizeBytes": 8907,
          "signals": [
            "reads-process-env",
            "network-access",
            "writes-file",
            "writes-outside-package",
            "external-url",
            "requires-local-file"
          ],
          "references": [
            "js/helper.js",
            "package.json",
            "js/logger.js"
          ]
        },
        {
          "path": "js/helper.js",
          "reason": "required by ./js/install.js",
          "sha256": "76f511fd75cf4cb2afc251a9ba62ecbbc8aeb571233d13e4958a4d82f2a1359c",
          "sizeBytes": 6128,
          "signals": [
            "uses-child-process",
            "reads-process-env"
          ],
          "references": []
        },
        {
          "path": "package.json",
          "reason": "required by ./js/install.js",
          "sha256": "8ab62ccee75956b622201e5d16bccec41c6883b0771146310bc6ded8e26f5a9d",
          "sizeBytes": 1903,
          "signals": [
            "external-url"
          ],
          "references": []
        },
        {
          "path": "js/logger.js",
          "reason": "required by ./js/install.js",
          "sha256": "d7d63601d3347efc93425f4f93049cfb9ed2b9ead1dce662c9c1bed3cba302e0",
          "sizeBytes": 253,
          "signals": [],
          "references": []
        }
      ],
      "nativeBuildInfo": null,
      "changeClassification": {
        "status": "new",
        "previousApprovedVersion": null,
        "hasPreviousDeny": false
      },
      "riskSummary": [
        "makes network requests",
        "may write outside the package directory",
        "uses child_process (can spawn external commands)"
      ],
      "suggestedReviewFocus": [
        "confirm what remote endpoints are contacted and whether responses are verified",
        "confirm whether file writes are scoped to the package directory",
        "confirm what external commands are executed and whether they are constrained"
      ]
    },
    {
      "name": "canvas",
      "version": "2.11.2",
      "location": "node_modules/canvas",
      "approvalStatus": "pending",
      "dependencyType": "direct",
      "introducedBy": [
        [
          "allow-scripts-demo",
          "canvas@2.11.2"
        ]
      ],
      "lifecycleScripts": {
        "install": "node-gyp rebuild"
      },
      "referencedFiles": [
        {
          "path": null,
          "reason": "inline lifecycle script: `install`",
          "sha256": null,
          "sizeBytes": null,
          "signals": [
            "native-build"
          ],
          "references": []
        }
      ],
      "nativeBuildInfo": {
        "sha256": "684e491f30b36151ebc98bef3eef17a1078b1227003ceaea6fec355441813666",
        "targets": [
          {
            "name": "canvas-postbuild",
            "sources": [],
            "libraries": [],
            "includeDirs": [],
            "hasConditions": true
          },
          {
            "name": "canvas",
            "sources": [
              "src/backend/Backend.cc",
              "src/backend/ImageBackend.cc",
              "src/backend/PdfBackend.cc",
              "src/backend/SvgBackend.cc",
              "src/bmp/BMPParser.cc",
              "src/Backends.cc",
              "src/Canvas.cc",
              "src/CanvasGradient.cc",
              "src/CanvasPattern.cc",
              "src/CanvasRenderingContext2d.cc",
              "src/closure.cc",
              "src/color.cc",
              "src/Image.cc",
              "src/ImageData.cc",
              "src/init.cc",
              "src/register_font.cc"
            ],
            "libraries": [
              "-l<(GTK_Root)/lib/cairo.lib",
              "-l<(GTK_Root)/lib/libpng.lib",
              "-l<(GTK_Root)/lib/pangocairo-1.0.lib",
              "-l<(GTK_Root)/lib/pango-1.0.lib",
              "-l<(GTK_Root)/lib/freetype.lib",
              "-l<(GTK_Root)/lib/glib-2.0.lib",
              "-l<(GTK_Root)/lib/gobject-2.0.lib",
              "<!@(pkg-config pixman-1 --libs)",
              "<!@(pkg-config cairo --libs)",
              "<!@(pkg-config libpng --libs)",
              "<!@(pkg-config pangocairo --libs)",
              "<!@(pkg-config freetype2 --libs)",
              "-l<(jpeg_root)/lib/jpeg.lib",
              "<!@(pkg-config libjpeg --libs)",
              "-l<(GTK_Root)/lib/gif.lib",
              "-L/opt/homebrew/lib",
              "-lgif",
              "-l<(GTK_Root)/lib/librsvg-2-2.lib",
              "<!@(pkg-config librsvg-2.0 --libs)"
            ],
            "includeDirs": [
              "<!(node -e \"require('nan')\")",
              "<(GTK_Root)/include",
              "<(GTK_Root)/include/cairo",
              "<(GTK_Root)/include/pango-1.0",
              "<(GTK_Root)/include/glib-2.0",
              "<(GTK_Root)/include/freetype2",
              "<(GTK_Root)/lib/glib-2.0/include",
              "<!@(pkg-config cairo --cflags-only-I | sed s/-I//g)",
              "<!@(pkg-config libpng --cflags-only-I | sed s/-I//g)",
              "<!@(pkg-config pangocairo --cflags-only-I | sed s/-I//g)",
              "<!@(pkg-config freetype2 --cflags-only-I | sed s/-I//g)",
              "<(jpeg_root)/include",
              "<!@(pkg-config libjpeg --cflags-only-I | sed s/-I//g)",
              "/opt/homebrew/include",
              "<!@(pkg-config librsvg-2.0 --cflags-only-I | sed s/-I//g)"
            ],
            "hasConditions": true
          }
        ],
        "parseError": null
      },
      "changeClassification": {
        "status": "new",
        "previousApprovedVersion": null,
        "hasPreviousDeny": false
      },
      "riskSummary": [
        "builds native code (node-gyp / binding.gyp)"
      ],
      "suggestedReviewFocus": [
        "review the binding.gyp targets — inspect native source files for unsafe C/C++ operations, verify external library dependencies are expected, and check platform-specific conditions"
      ]
    },
    {
      "name": "esbuild",
      "version": "0.20.0",
      "location": "node_modules/esbuild",
      "approvalStatus": "pending",
      "dependencyType": "direct",
      "introducedBy": [
        [
          "allow-scripts-demo",
          "esbuild@0.20.0"
        ]
      ],
      "lifecycleScripts": {
        "postinstall": "node install.js"
      },
      "referencedFiles": [
        {
          "path": "install.js",
          "reason": "referenced by lifecycle script: `postinstall`",
          "sha256": "a061231445c23fe8ed9f1f102a639adc796982541b3cc5976beb7544dca24a77",
          "sizeBytes": 10963,
          "signals": [
            "uses-child-process",
            "reads-process-env",
            "network-access",
            "external-url"
          ],
          "references": []
        }
      ],
      "nativeBuildInfo": null,
      "changeClassification": {
        "status": "new",
        "previousApprovedVersion": null,
        "hasPreviousDeny": false
      },
      "riskSummary": [
        "uses child_process (can spawn external commands)",
        "makes network requests"
      ],
      "suggestedReviewFocus": [
        "confirm what external commands are executed and whether they are constrained",
        "confirm what remote endpoints are contacted and whether responses are verified"
      ]
    }
  ]
}

npm Lifecycle Script Approval Review

Note: This report is best-effort and does not claim to prove a package is safe. A human must review this evidence before approving or denying any package.

Package: @sentry/cli@1.77.3

Introduced by:

• allow-scripts-demo → @sentry/webpack-plugin@1.21.0 → @sentry/cli@1.77.3
• allow-scripts-demo → ember-cli-deploy-sentry-cli@3.1.0 → @sentry/cli@1.77.3

Lifecycle scripts:

install: node ./scripts/install.js

Risk summary

• ⚠️ Makes network requests
• ⚠️ May write outside the package directory
• ⚠️ Uses child_process (can spawn external commands)

Referenced files

scripts/install.js — 839 bytes

SHA-256: f693c46a...
Reason: Referenced by lifecycle script install

Thin entry-point shim. All significant risk lives in the files it requires.

js/install.js — 8,907 bytes

SHA-256: a15ee1c6...
Reason: Required by ./scripts/install.js

This is the canonical binary-downloader pattern. The package ships no native binary; the install script fetches the correct platform binary from an external CDN.

js/helper.js — 6,128 bytes

SHA-256: 76f511fd...
Reason: Required by ./js/install.js

No further references — chain terminates here.

package.json — 1,903 bytes

SHA-256: 8ab62cce...
Reason: Required by ./js/install.js

js/logger.js — 253 bytes

SHA-256: d7d63601...
Reason: Required by ./js/install.js

No signals detected. Logging utility only — no independent risk.

Suggested review focus

1. Confirm remote endpoints — open js/install.js and verify the download URL is pinned to 1.77.3 and points to a Sentry-owned domain. Check package.json for the base URL.
2. Verify integrity checking — does js/install.js or js/helper.js verify a checksum or signature of the downloaded binary before writing it?
3. Confirm write path — trace writes-outside-package to the exact destination directory.
4. Confirm child process scope — check js/helper.js to see what command is spawned; expected to be chmod +x <binary> or similar, not an arbitrary shell command.

Package: canvas@2.11.2

Introduced by:

• allow-scripts-demo → canvas@2.11.2

Lifecycle scripts:

install: node-gyp rebuild

Risk summary

• ⚠️ Builds native code (node-gyp / binding.gyp)

Referenced files

(inline: node-gyp rebuild)

Reason: Inline lifecycle script install

No separate install script — the command is inline. All risk is in the native build targets.

Native build (binding.gyp)

SHA-256: 684e491f... — parseError: null — parsed successfully

Targets (2):

Target: canvas-postbuild

• Sources: none listed
• Libraries: none listed
• Include dirs: none listed
• Has platform conditions: yes

Post-build step with platform conditions. Likely runs a post-compile fixup (e.g. stripping debug symbols or copying a prebuilt binary). Verify what the conditions control.

Target: canvas

• 16 C++ source files — all under src/ (Canvas, Image, PDF/SVG backends, BMP parser, gradients, patterns, fonts, color)
• Has platform conditions: yes

Libraries linked:

Include dirs: All map to standard system headers for the above libraries plus nan (Node addon helper). None are unexpected.

Suggested review focus

1. Platform conditions — both targets have hasConditions: true. Review the conditions in binding.gyp directly to confirm no condition activates a remote download or unexpected code path.
2. <!@(pkg-config …) shell expansions — GYP evaluates these at build time. Confirm none of the pkg-config invocations have been tampered with (supply-chain check: does the binding.gyp SHA-256 match the published tarball?).
3. Source file audit — 16 .cc files compile directly on the target machine. For a security-critical environment, spot-check src/Canvas.cc and src/init.cc for any dynamic code loading, eval-equivalent patterns, or network calls from C++.
4. nan dependency — verify the nan version is pinned and not itself a lifecycle-script risk.

Package: esbuild@0.20.0

Introduced by:

• allow-scripts-demo → esbuild@0.20.0

Lifecycle scripts:

postinstall: node install.js

Risk summary

• ⚠️ Uses child_process (can spawn external commands)
• ⚠️ Makes network requests

Referenced files

install.js — 10,963 bytes

SHA-256: a061231445...
Reason: Referenced by lifecycle script postinstall

No further references — install.js does not chain to other local files.

Suggested review focus

1. Confirm child process command — esbuild's install.js in 0.20.0 typically calls child_process.execFileSync with a platform-specific npm package name. Verify the spawned command is npm install --prefer-offline <platform-pkg> or similar — not an arbitrary shell string.
2. Confirm external URL — verify the URL points to the official npm registry or the esbuild GitHub releases page, and that it includes the pinned version 0.20.0.
3. No writes-outside-package signal — unlike @sentry/cli, esbuild does not report writes outside its package directory. This is consistent with the optionalDependencies pattern where the binary lands inside node_modules/. Confirm this is still the case for 0.20.0.

Overall approval recommendation

All three packages are well-known, widely-used, and their install-script patterns are publicly documented. None show signals outside what is expected for their respective patterns. The primary human verification step for each is confirming the exact download URLs and child process invocations match the published package source.

This is what I was trying to get to. Not just saying go review these packages but having it help you review. Json for cli and ai bot analysis and markdown for the Github comments and human report view.

See this comment You aren't wrong aren't wrong on the includes. I am working on a more detailed reporting and have a couple more things to go though before making a pr for npm. We need a better full analysis of npm and other package systems. See he RFC I wrote for the gist of what I am going for. Interested in your ideas. based on the commit work you referenced.