fix(arborist): gate allowScripts on inDepBundle, not inBundle (#9679)

[Sanjays2402]

Description

Fixes #9679.

isScriptAllowed and collectUnreviewedScripts were keying off node.inBundle. That bit is also true for deps the root project lists in its own bundleDependencies, but those deps are still fetched from the registry at install time, run their install scripts during reify, and have a trusted resolved URL (no manifest confusion). The gate was therefore:

• always returning null from isScriptAllowed for a root-bundled dep, so the user could not add an allowScripts entry that would actually match, and
• skipping the same node in collectUnreviewedScripts, so it never appeared in the "pending review" output or the --strict-allow-scripts preflight.

The net effect, as described in the issue, was that install scripts were silently dropped for root-bundled deps with no way to surface or approve them.

Changes

Both call sites now use a new isBundledByDependency(node) predicate:

• For real Node (workspaces/arborist/lib/node.js), it reads inDepBundle directly. That getter walks getBundler() and only returns true when the bundler is not the root, which is exactly the "bundled inside another package's tarball" case the security comment was trying to describe.
• For IsolatedNode (linked / isolated mode), inDepBundle is hardcoded to false because the class does not track root-vs-dep bundling. To preserve the existing security gate (no allowlisting of bundled IsolatedNodes, since their identity comes from the bundling tarball), the predicate falls back to inBundle when getBundler() is null. Real Node's getBundler() returns the bundling parent (the root, for root-bundled), so this discriminator does not affect real-Node semantics.

inDepBundle is also used by diff.js, edge.js, reify.js, etc. in real-Node code paths, so changing the IsolatedNode getter itself would have regressed isolated-mode reify; that's why the discriminator lives in script-allowed.js instead.

lib/commands/rebuild.js's inBundle check is left alone: that one gates npm rebuild <name> from targeting a bundled directory by name, which is a separate concern from script approval.

Test Coverage

workspaces/arborist/test/script-allowed.js:

• Existing "bundled deps cannot be allowlisted" tests are renamed to "dep-bundled deps..." and switched to inDepBundle: true fixtures, since the dep-bundled case is what the security comment is actually about.
• New root-bundled deps remain allowlistable (npm/cli#9679) test asserts that a node with inBundle: true, inDepBundle: false and a registry resolved URL:
  • matches a name-only allow entry,
  • matches a versioned allow entry,
  • is blocked by a deny entry, and
  • still returns null (unreviewed) when no policy entry covers it, so its scripts stay blocked until the user explicitly approves them.
• isolated mode (linked): bundled IsolatedNode is blocked now also asserts inDepBundle === false on the IsolatedNode and verifies the getBundler()===null fallback keeps the gate closed.

workspaces/arborist/test/unreviewed-scripts.js:

• The "skips ... bundled nodes" fixture is updated to inDepBundle: true (the dep-bundled case).
• New root-bundled deps are still listed as pending (npm/cli#9679) test asserts a root-bundled dep with an install script shows up in the unreviewed list with the right script content.

Both regression tests were verified to fail on latest and pass with this patch. Ran test/script-allowed.js, test/unreviewed-scripts.js, test/node.js, test/isolated-mode.js, and test/arborist/rebuild.js locally with the patch applied: all green. (The pre-existing test/arborist/reify.js failures in global style / global / global install ignores a per-call linked strategy reproduce on unpatched latest, so they are not from this change.) Coverage for the two touched lib files stays at 100% lines/branches/functions/statements.

Lint clean (eslint on the four changed files).

AI Disclosure

This change was written with the assistance of Claude. I have reviewed the diff and the tests and take responsibility for the code.

[JamieMagee]

The predicate and both call sites are sound. I built real Node and IsolatedNode instances and ran them through the gate: root-bundled deps become reviewable, while dep-bundled and isolated-bundled nodes stay blocked even when the policy explicitly allows name@version. That part I'm happy with.

The problem is the change stops at the listing. collectUnreviewedScripts now shows root-bundled deps as pending, and both the advisory and the strict preflight tell people to approve them by name. But the command layer that handles approve <name> and prune still filters on node.inBundle, so those same deps fall through. Result: approve --all works, but approve <name> throws ENOMATCH and prune quietly deletes the entry you just wrote. I'd like both sorted before this lands.

[JamieMagee]

This fixture is a plain object with no getBundler, so it only exercises the typeof getBundler !== 'function' fallback, not the real-Node getBundler() === root path that actually runs in production. I checked the real path by hand and it's fine, but nothing here would catch a regression on that branch. Could you add a case built from an actual Node with the root listing it in bundleDependencies? The IsolatedNode test already uses a real instance, so this is the last uncovered branch.