install: set npm_config_local_prefix and npm_package_config_* for lifecycle scripts

[robobun]

Problem

• Lifecycle scripts run by bun install (and bun pm trust) no longer see npm_config_local_prefix or npm_package_config_<key>. Bun 1.3.14 and npm set both; 1.4.0 prints prefix=[] cfg=[] for the repro below.
• Real consumers: install scripts locate the project they are being installed into through npm_config_local_prefix, and packages read their own package.json config through npm_package_config_* (for example sharp's install check reads npm_package_config_libvips).
• Cause: PackageManager::configure_env_for_scripts_run (src/install/PackageManager.rs:1136) calls the install-tier shim RunCommand::configure_env_for_run in src/install/lib.rs. The shim only seeds npm_config_user_agent, npm_execpath and BUN_FEATURE_FLAG_NO_ORPHANS; its closing comment deferred the rest to the runtime implementation, which the install path never calls. In 1.3.14 the package manager called the full RunCommand.configureEnvForRun, which also exported the prefix and the root package.json's config.
• npm_package_name / npm_package_version / npm_package_json went missing in the same way; install: set npm_package_name/version/json for dependency lifecycle scripts #36690 (open) adds those, so this PR leaves them alone.

Fix

• src/install/lib.rs: the shim now sets npm_config_local_prefix to top_level_dir. PackageManager::init has already moved that to the project root (the workspace root when installing from inside a workspace member), which is the directory npm exports, and it is the same value INIT_CWD is derived from a few lines later.
• It is written with put, not put_default, because npm overwrites this variable on every run and the only way a value is already present is an outer bun run / npm run, possibly from a different project; inheriting it would send scripts to the wrong root. run: set npm_package_name/version/json and npm_config_local_prefix per run #38071 makes the same change for bun run.
• src/install/PackageManager/PackageManagerLifecycle.rs: spawn_package_lifecycle_scripts reads the package.json at the script's cwd and exports its config entries as npm_package_config_<key> into that package's script env. Reading the manifest of the package being run (rather than exporting the root's config into the shared base env as 1.3.14 did) is what npm does: a dependency's install script sees the dependency's own config, and the root's keys do not leak into it. The root's scripts get the root's config exactly as before.
• Exported subset is the one bun run already uses (bun_resolver::PackageJSON::config, also what 1.3.14 exported): top-level entries whose key and string value are non-empty. Nested objects and non-string values are skipped here as they are for bun run; changing that would be a separate change to both paths.
• The read and parse follow Scripts::fill_from_package_json in the same crate (initialize_store() + ParsedJson::parse_package_json); a missing or unparsable manifest just leaves the variables unset. This runs once per package that actually has scripts to run, after PATH is built, so every caller (install_with_manager root scripts, PackageInstaller / runTasks dependency and workspace scripts, bun pm trust) gets it.
• Test: test/cli/install/bun-install-lifecycle-scripts.test.ts, "npm_config_local_prefix and npm_package_config_* are set for root and dependency scripts". One install with a root config (string, number, nested object, empty string) and a trusted file: dependency with its own config sharing one key with the root; each postinstall dumps npm_config_local_prefix and every npm_package_config_* variable, and the test compares the exact sets. The install is spawned with a stale npm_config_local_prefix in its environment to cover the overwrite. Before the fix it fails with config: {} and the stale prefix; with the fix it passes in both the default and waiter-thread variants.
• Also run: the rest of bun-install-lifecycle-scripts.test.ts (the three PATH="" tests fail identically without this change in this container and pass in CI on main), the $npm_package_config_* tests in bun-run.test.ts and bun-workspaces.test.ts, cargo fmt, cargo clippy -p bun_install.

Background

• npm_config_local_prefix is npm's name for the project root an install operates on; npm exports it to every lifecycle script, including dependencies' scripts, and npm_package_config_<key> is how npm exposes a package.json config object to that package's own scripts.
• Lifecycle script env in the install path: configure_env_for_scripts_run builds one base env map once per process (PATH additions, INIT_CWD, node-gyp setup, the shim above); spawn_package_lifecycle_scripts clones it per package with scripts, adds that package's PATH, and hands the result to the subprocess. Process-wide values belong in the shim, per-package values in the spawn function, which is why the two variables land in different files.
• The install crate cannot call the runtime's configure_env_for_run (the runtime crate depends on the install crate), hence the shim.
• initialize_store() creates or resets the thread-local AST store that parsed JSON values are materialized into; every transient package.json parse during an install calls it first, and the long-lived manifests (WorkspacePackageJSONCache) are deep-cloned into their own arenas so these resets cannot invalidate them.

Repro

mkdir /tmp/inst && cd /tmp/inst
cat > package.json <<'EOF'
{"name":"inst-root","version":"3.3.3","config":{"port":"8080"},
 "scripts":{"postinstall":"echo prefix=[$npm_config_local_prefix] cfg=[$npm_package_config_port]"}}
EOF
bun install

bun 1.3.14 and npm: prefix=[/tmp/inst] cfg=[8080]
bun 1.4.0: prefix=[] cfg=[]
this branch: prefix=[/tmp/inst] cfg=[8080]; a trusted dependency with its own config sees its own keys and the project root as the prefix.

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 6 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: fc0d9110-5518-4373-b02e-73a26171af2f

📥 Commits

Reviewing files that changed from the base of the PR and between b7a0431 and d299d23.

📒 Files selected for processing (3)

• src/install/PackageManager/PackageManagerLifecycle.rs
• src/install/lib.rs
• test/cli/install/bun-install-lifecycle-scripts.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

^{Updated 7:30 AM PT - Aug 13th, 2026}

❌ @robobun, your commit d299d23 has 1 failures in Build #94394 (All Failures):

• test/js/web/timers/setInterval.test.js - code 1 on 🐧 13 x64-asan

---

🧪   To try this PR locally:

bunx bun-pr 38110

That installs a local version of the PR into your bun-38110 executable, so you can run:

bun-38110 --bun

[robobun]

Status: reproduced and fixed; self-review in progress, then waiting on CI.

Reproduced with the released 1.4.0 binary and a debug build of main using the repro in the description (prefix=[] cfg=[]). The new test in test/cli/install/bun-install-lifecycle-scripts.test.ts fails on main with config: {} and the stale prefix, and passes with this branch in both the default and waiter-thread variants.

Related: #36690 adds npm_package_name / npm_package_version / npm_package_json to the same spawn path; #38071 makes the matching overwrite change for bun run.

[github-actions]

This PR may be a duplicate of:

1. install: set npm_package_name/version/json for dependency lifecycle scripts #36690 - Adds per-package env seeding at the same insertion point in spawn_package_lifecycle_scripts (same file, same function, same test file), reading the script cwd's package.json to export a different slice of npm_package_*.
2. run: set npm_package_name/version/json and npm_config_local_prefix per run #38071 - Makes the same put_default -> put change for npm_config_local_prefix with the same stale-value rationale, but in the bun run path (configure_env_for_run_impl) instead of the install-side shim.

🤖 Generated with Claude Code

[robobun]

Not duplicates, for anyone triaging: #36690 exports a different set of variables (npm_package_name / npm_package_version / npm_package_json) from the same spawn point and this PR deliberately leaves those to it, so the two compose (whichever lands second gets a small conflict in spawn_package_lifecycle_scripts and in the test file). #38071 changes bun run (src/runtime/cli/run_command.rs), which bun install does not go through; this PR is the install-side counterpart and neither touches the other's files.

[claude]

LGTM — focused regression fix restoring npm_config_local_prefix and npm_package_config_* for install lifecycle scripts.

What was reviewed:

• put_npm_package_config_env follows the existing Scripts::fill_from_package_json parse pattern (read_from → initialize_store() → parse_package_json); ScriptsList fields are owned (Box<[u8]>/ZBox) so the store reset can't invalidate them.
• npm_config_local_prefix uses the same top_level_dir value the runtime's configure_env_for_run already exports; put (not put_default) matches npm's overwrite semantics and the test's stale-value check.
• Ruled out: trailing separator on top_level_dir() (test asserts exact equality with packageDir); inherited npm_package_config_* leaking into dependency scripts (per-package clone + put gives each package its own values, matching npm and improving on 1.3.14's root-only export).

Extended reasoning...

Overview

This PR restores two npm environment variables that regressed when the package manager stopped calling the full runtime RunCommand.configureEnvForRun: npm_config_local_prefix (project root) and npm_package_config_<key> (the package's own package.json config entries). The fix touches two files in src/install/: the install-tier configure_env_for_run shim in lib.rs seeds the process-wide prefix, and spawn_package_lifecycle_scripts in PackageManagerLifecycle.rs reads each package's own manifest to seed the per-package config vars into that package's cloned env map. A ~90-line test exercises root + trusted dependency, overwrite of a stale inherited prefix, and filtering of non-string/nested/empty config values.

Security risks

None. Lifecycle scripts already execute arbitrary code with the install's environment; adding two more npm-compatible variables (project root path and the package's own declared config strings) does not expand attack surface. No parsing of untrusted input reaches a new sink — parse_package_json is the same parser already invoked for these manifests elsewhere in the install path, and read/parse failures degrade to leaving the vars unset rather than propagating.

Level of scrutiny

Low-to-medium. This is a targeted regression fix restoring pre-existing (1.3.14) behavior with a narrower, more npm-correct semantics (each package sees its own config, not the root's). The Rust changes follow established in-crate patterns exactly: the JSON-parse sequence mirrors Scripts::fill_from_package_json in the same crate, and the env-var seeding mirrors the runtime's run_command.rs. The initialize_store() call is safe here because everything held across it (ScriptsList.items, cwd, the cloned script_env) is owned, and this pattern is used in ~20 other places in the crate.

Other factors

The test is thorough: it asserts exact env-var sets via toEqual (not toContain), covers both the default and waiter-thread variants via the enclosing for loop, verifies overwrite of an inherited stale prefix, verifies a dependency sees its own config keys and not the root's (including a shared key with different values), and verifies the non-string/nested/empty filtering matches bun run. Two candidate issues were raised and refuted: a trailing separator on top_level_dir() (the test's exact-equality check on localPrefix: packageDir would catch it, and the runtime uses the same unstripped value), and inherited npm_package_config_* leaking (the per-package env is cloned fresh from the base map and the test filters these from the install's own env). No prior human review comments to address.