Description

The workspace catalog pins @pnpm/npm-lifecycle to a GitHub PR head ref (refs/pull/59/head), which is
mutable; future installs/lockfile regenerations can silently resolve to different code than what was
reviewed. This is especially risky because @pnpm/exec.lifecycle depends on @pnpm/npm-lifecycle via
"catalog:", so the catalog directly controls production code used by lifecycle execution.

Code

pnpm-workspace.yaml[94]

+  '@pnpm/npm-lifecycle': https://github.com/pnpm/npm-lifecycle#refs/pull/59/head

Evidence

The catalog entry is a mutable PR head, and @pnpm/exec.lifecycle sources @pnpm/npm-lifecycle from
the catalog, so resolution drift can change runtime behavior. The lockfile also records the PR-head
specifier, reinforcing that future updates may re-resolve from the moving ref.

pnpm-workspace.yaml[93-95]
pnpm-lock.yaml[354-358]
exec/lifecycle/package.json[36-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pnpm-workspace.yaml` points `@pnpm/npm-lifecycle` at `https://github.com/pnpm/npm-lifecycle#refs/pull/59/head`, which can change over time. Even though the current `pnpm-lock.yaml` resolves to a specific commit tarball, any future resolution (e.g. lockfile refresh/update) may pull different code without an explicit version change.
### Issue Context
`@pnpm/exec.lifecycle` consumes `@pnpm/npm-lifecycle` via `catalog:`, so this affects lifecycle script execution behavior.
### Fix Focus Areas
- pnpm-workspace.yaml[93-95]
- pnpm-lock.yaml[354-358]
### Suggested fix
- Replace the PR head ref with an immutable identifier:
- Prefer a published version (once available), OR
- Pin to a commit SHA/ref (e.g. `https://github.com/pnpm/npm-lifecycle#<commitSha>`), then regenerate the lockfile so specifier+resolution are consistent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

inspect-npm-config-env/postinstall.js prints every npm_config_* variable from the parent
process, but the Jest test only sets npm_config_platform_arch and asserts the output is exactly
one line. If the developer/CI environment already has other user-defined npm_config_* variables
(e.g. npm_config_registry), this test can fail even though the implementation is correct.

Code

exec/lifecycle/test/index.ts[R65-87]

+test('runLifecycleHook() does not set npm_config env vars but preserves user-defined ones', async () => {
+  const pkgRoot = f.find('inspect-npm-config-env')
  await using server = await createTestIpcServer(path.join(pkgRoot, 'test.sock'))
  const { default: pkg } = await import(path.join(pkgRoot, 'package.json'))
-  await runLifecycleHook('postinstall', pkg, {
-    depPath: '/inspect-frozen-lockfile/1.0.0',
-    pkgRoot,
-    rootModulesDir,
-    unsafePerm: true,
-  })
-
-  expect(server.getLines()).toStrictEqual(['unset'])
+  const prevPlatformArch = process.env.npm_config_platform_arch
+  process.env.npm_config_platform_arch = 'x64'
+  try {
+    await runLifecycleHook('postinstall', pkg, {
+      depPath: '/inspect-npm-config-env/1.0.0',
+      pkgRoot,
+      rootModulesDir,
+      unsafePerm: true,
+    })
+  } finally {
+    if (prevPlatformArch === undefined) {
+      delete process.env.npm_config_platform_arch
+    } else {
+      process.env.npm_config_platform_arch = prevPlatformArch
+    }
+  }
+
+  expect(server.getLines()).toStrictEqual(['npm_config_platform_arch=x64'])
})

Evidence

The fixture prints all npm_config_* variables (except npm_config_node_gyp), while the test only
sets/restores npm_config_platform_arch and then asserts the output equals a single-line array; any
pre-existing npm_config_* vars will add extra lines and break the strict equality assertion.

exec/lifecycle/test/fixtures/inspect-npm-config-env/postinstall.js[1-5]
exec/lifecycle/test/index.ts[65-87]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The test `runLifecycleHook() does not set npm_config env vars but preserves user-defined ones` expects only `npm_config_platform_arch=x64` to be observed in the child, but the fixture emits *all* `npm_config_*` vars present in `process.env`. This makes the test non-deterministic when the parent environment already contains other user-defined `npm_config_*` variables.

## Issue Context
The fixture enumerates `process.env` and writes every `npm_config_*` key (excluding `npm_config_node_gyp`). The test currently only snapshots/restores `npm_config_platform_arch`, and does not sanitize other existing `npm_config_*` keys.

## Fix Focus Areas
- exec/lifecycle/test/index.ts[65-87]
- exec/lifecycle/test/fixtures/inspect-npm-config-env/postinstall.js[1-5]

## Suggested fix
In `exec/lifecycle/test/index.ts`, snapshot *all* existing `npm_config_*` variables (at least those the fixture would print), delete them before running `runLifecycleHook`, then set `npm_config_platform_arch='x64'`. In the `finally` block, restore the full snapshot (including removal of any vars that were originally absent).

(Alternative) Narrow the fixture to only print `npm_config_platform_arch` so the assertion cannot be affected by unrelated environment variables.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

On Windows, filter_parent_env() no longer strips most non-auth npm_* variables, but
build_env() later inserts several npm_* lifecycle stamps (e.g. npm_lifecycle_event,
npm_execpath, npm_lifecycle_script). If the parent environment contains a differently-cased
variant (e.g. NPM_LIFECYCLE_EVENT), the child may receive duplicates with an unspecified winner
and observe incorrect lifecycle values.

Code

pacquet/crates/executor/src/make_env.rs[R163-179]

fn is_stamping_key(key: &str, is_windows: bool) -> bool {
+    if strip_env_prefix(key, "npm_package_", is_windows).is_some() {
+        return true;
+    }
+    if let Some(rest) = strip_env_prefix(key, "npm_config_", is_windows)
+        .or_else(|| strip_env_prefix(key, "pnpm_config_", is_windows))
+        && (rest.starts_with(['_', '/', '@']) || rest.contains(":_"))
+    {
+        return true;
+    }
   if is_windows {
-        // Byte-level prefix check: `key[..4]` would panic if byte 4
-        // lands inside a multi-byte UTF-8 codepoint (e.g. a key
-        // containing `𐀀` whose first byte sits at index 0). Since
-        // the prefix we want is pure ASCII, comparing bytes
-        // sidesteps the UTF-8 boundary question entirely.
-        if key.as_bytes().get(..4).is_some_and(|b| b.eq_ignore_ascii_case(b"npm_")) {
-            return true;
-        }
       return ["NODE", "TMPDIR", "INIT_CWD", "PNPM_SCRIPT_SRC_DIR"]
           .iter()
           .any(|name| key.eq_ignore_ascii_case(name));
   }
-    if key.starts_with("npm_") {
-        return true;
-    }
   matches!(key, "NODE" | "TMPDIR" | "INIT_CWD" | "PNPM_SCRIPT_SRC_DIR")
}

Evidence

build_env() unconditionally inserts lifecycle-related npm_* keys into the env map, while
is_stamping_key() on Windows does not filter those families; on Windows, case-insensitive env-key
collapsing is explicitly called out as a hazard elsewhere in the same crate (for PATH),
demonstrating the same risk applies here.

pacquet/crates/executor/src/make_env.rs[52-129]
pacquet/crates/executor/src/make_env.rs[131-179]
pacquet/crates/executor/src/lifecycle.rs[327-335]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`filter_parent_env()` uses `is_stamping_key()` to remove parent env entries that would conflict with values later stamped by `build_env()`. After this PR, `is_stamping_key()` no longer strips lifecycle-related `npm_*` keys (only `npm_package_*`, auth-ish `(npm|pnpm)_config_*`, and a small fixed set of per-call stamps).
On Windows, env keys are case-insensitive at spawn time. If the parent env contains `NPM_LIFECYCLE_EVENT` (or other stamped keys) and `build_env()` inserts `npm_lifecycle_event`, the resulting `HashMap` can contain both keys (Rust key comparison is case-sensitive), and `Command::envs` will collapse them with an unspecified winner.
## Issue Context
`pacquet/crates/executor/src/lifecycle.rs` already has a special-case fix for this exact Windows hazard for `PATH`/`Path`, but the same risk exists for stamped lifecycle keys like `npm_lifecycle_event`, `npm_lifecycle_script`, `npm_execpath`, etc.
## Fix Focus Areas
- pacquet/crates/executor/src/make_env.rs[52-129]
- pacquet/crates/executor/src/make_env.rs[131-201]
- pacquet/crates/executor/src/lifecycle.rs[327-350]
## Suggested fix approach
1. Extend `is_stamping_key()` (Windows branch) to also strip any key that equals (case-insensitively) *all keys that `build_env()` may insert*, such as:
 - `npm_lifecycle_event`
 - `npm_lifecycle_script`
 - `npm_node_execpath`
 - `npm_execpath`
 - `npm_package_json`
 - `npm_config_node_gyp`
 - `npm_config_user_agent`
 - (keep existing `NODE`, `TMPDIR`, `INIT_CWD`, `PNPM_SCRIPT_SRC_DIR`)
 This avoids creating case-only duplicates when stamping.
2. (Alternative) Add a second retain pass in `run_lifecycle_hook()` similar to the existing PATH handling, removing case-insensitively any preexisting keys from the same stamped set before calling `.envs(&child_env)`.
Either approach should ensure that, on Windows, there is at most one logical value per stamped env var name.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new test sets process.env.npm_config_platform_arch and always deletes it in finally, which will
clobber any pre-existing value from the developer/CI environment. Because Jest runs multiple tests
in the same process for this test file, this can cause order-dependent or environment-dependent test
failures.

Code

exec/lifecycle/test/index.ts[R83-93]

+  process.env.npm_config_platform_arch = 'x64'
+  try {
+    await runLifecycleHook('postinstall', pkg, {
+      depPath: '/inspect-user-npm-config/1.0.0',
+      pkgRoot,
+      rootModulesDir,
+      unsafePerm: true,
+    })
+  } finally {
+    delete process.env.npm_config_platform_arch
+  }

Evidence

The added test explicitly mutates and deletes a global env var; Jest is used to run this test file,
so that mutation persists within the process unless properly restored.

exec/lifecycle/test/index.ts[79-96]
exec/lifecycle/package.json[28-35]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The test mutates `process.env.npm_config_platform_arch` and then unconditionally deletes it. If it was already set, the original value is lost for subsequent tests in the same Jest process.
### Issue Context
This test suite is executed by Jest (single process per test file by default). Global env mutations should be restored to avoid cross-test interference.
### Fix Focus Areas
- exec/lifecycle/test/index.ts[79-96]
### Suggested fix
Wrap the mutation with save/restore semantics:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0)

Walkthrough

The parent-environment filtering in the Rust executor (make_env.rs) is reworked so that only npm_package_* stamps, auth-related (npm|pnpm)_config_* credential keys, and per-call re-derived keys are removed; user-defined npm_config_* values are now preserved. The JS lifecycle test fixture is renamed and updated to report surviving npm_config_* keys. Tests in both languages are updated to assert the new behavior. The @pnpm/npm-lifecycle catalog entry is widened and a changeset entry is added.

Changes

Preserve user npm_config_* env vars in lifecycle scripts

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• pnpm/pnpm#12338: Both PRs center on npm_config_* environment-variable handling—this PR changes the lifecycle make_env filtering to preserve user-defined npm_config_* values instead of stripping them, which is directly relevant to new URL-scoped auth support carried via npm_config_//… env vars.

Suggested reviewers

• zkochan

Poem

🐇 Hop hop, the config vars stay!
No more stripping them away,
npm_config_platform_arch lives on,
While auth tokens — poof — are gone.
The rabbit twitched its nose with glee,
"User settings should roam free!" 🥕

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

• Preserve user-defined npm_config_* variables when spawning lifecycle scripts.
• Continue stripping (npm|pnpm)_config_* auth-related keys to avoid credential leaks.
• Add/port TS and Rust tests to prevent regressions; bump @pnpm/npm-lifecycle.

The following are alternative approaches to this PR:

Recommendation: The PR’s approach (bump to the fixed @pnpm/npm-lifecycle and port the upstream parent-env filter into pacquet) is the most compatible and least disruptive. The key review focus should be the auth-key detection rules (prefix _, /, @, or containing :_) to ensure credentials remain stripped while not regressing user-defined npm_config_* propagation.

tests.rs Update executor e2e test to preserve user config and strip auth +15/-9

Update executor e2e test to preserve user config and strip auth

• Renames and rewrites the Unix end-to-end lifecycle spawn test to validate two behaviors: a user-defined 'npm_config_*' var is preserved, and an auth-like 'npm_config_*' var is stripped (empty in child). Uses RAII guards to avoid leaking env between tests.

pacquet/crates/executor/src/lifecycle/tests.rs

---

make_env.rs Refine parent env filtering to preserve user npm_config_* +61/-31

Refine parent env filtering to preserve user npm_config_*

• Changes env filtering to stop stripping all 'npm_*' keys and instead strip only 'npm_package_*' (regenerated) plus auth-like '(npm|pnpm)_config_*' keys. Adds a robust prefix matcher supporting Windows case-insensitivity without UTF-8 boundary panics.

pacquet/crates/executor/src/make_env.rs

---

package.json Rename fixture package for npm_config_* env inspection +1/-1

Rename fixture package for npm_config_* env inspection

• Updates the fixture package name from the old frozen-lockfile inspector to a new npm-config env inspector. Keeps the postinstall script wiring to the IPC-based test harness.

exec/lifecycle/test/fixtures/inspect-npm-config-env/package.json

---

postinstall.js Add fixture script to print npm_config_* env values +5/-0

Add fixture script to print npm_config_* env values

• Adds a postinstall script that enumerates 'npm_config_*' env vars and prints them (excluding 'npm_config_node_gyp'). This allows tests to assert which config keys reach the child lifecycle process.

exec/lifecycle/test/fixtures/inspect-npm-config-env/postinstall.js

---

index.ts Ensure runLifecycleHook preserves user-defined npm_config_* +20/-10

Ensure runLifecycleHook preserves user-defined npm_config_*

• Replaces the prior assertion that no npm_config env vars are present with a stronger invariant: pnpm must not inject config vars, but must preserve user-defined ones. The test now seeds 'npm_config_platform_arch', runs the hook, asserts it is observed, and restores the original env value.

exec/lifecycle/test/index.ts

---

tests.rs Expand make_env tests for preserved user config and stripped auth +79/-22

Expand make_env tests for preserved user config and stripped auth

• Updates the ported upstream test expectations: user 'npm_config_platform_arch' must pass through, multiple auth-like keys must be stripped, and leaked 'npm_package_*' must be regenerated. Extends POSIX/Windows stamping-key tests to cover the new rules.

pacquet/crates/executor/src/make_env/tests.rs

---

preserve-user-npm-config-vars.md Add changeset describing npm_config_* preservation fix +6/-0

Add changeset describing npm_config_* preservation fix

• Introduces a changeset marking patch releases for affected packages. Documents that user-defined 'npm_config_*' vars are preserved during lifecycle scripts and references the linked issue.

.changeset/preserve-user-npm-config-vars.md

---

pnpm-lock.yaml Regenerate lockfile for released @pnpm/npm-lifecycle 1100.0.0 +6/-6

Regenerate lockfile for released @pnpm/npm-lifecycle 1100.0.0

• Pins the catalog dependency from a pre-release '1100.0.0-1' to the released '^1100.0.0' and updates the resolved package entries accordingly. Ensures the repo consumes an immutable registry tarball.

pnpm-lock.yaml

---

pnpm-workspace.yaml Bump workspace catalog @pnpm/npm-lifecycle to ^1100.0.0 +1/-1

Bump workspace catalog @pnpm/npm-lifecycle to ^1100.0.0

• Updates the workspace catalog to depend on the released '@pnpm/npm-lifecycle' version range. Aligns the workspace with the lockfile update.

pnpm-workspace.yaml

---

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.