Walkthrough

Two bugs are fixed in checkDepsStatus: (1) pnpm install with optimisticRepeatInstall now detects when only pnpm-lock.yaml was modified and no longer falsely reports Already up to date; (2) when useGitBranchLockfile is enabled, the correct branch-specific lockfile name is stat'd instead of always using pnpm-lock.yaml. The mergeGitBranchLockfiles option is threaded through the relevant types and call sites. Git branch detection is optimized to read .git/HEAD directly rather than spawning a subprocess.

Changes

Lockfile Modification Detection Fix

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• pnpm/pnpm#11605: Both PRs modify deps/status/src/checkDepsStatus.ts to detect merge-conflicted wanted lockfiles using lockfile/fs/src/read.ts conflict-marker helpers to prevent optimisticRepeatInstall from incorrectly skipping lockfile resolution.
• pnpm/pnpm#11943: The main PR modifies the pacquet optimistic_repeat_install fast-path logic and its tests to change the "UpToDate" decision when only the lockfile changes, which directly builds on this PR's new optimistic repeat-install fast path implementation.
• pnpm/pnpm#11945: Both PRs modify pacquet/crates/package-manager/src/optimistic_repeat_install.rs's optimistic repeat-install fast-path decision logic around pnpm-lock.yaml existence/mtime handling.

Suggested labels

area: lockfile

Suggested reviewers

• zkochan

Poem

🐰 Hop, hop — the lockfile changed, but pnpm stayed asleep,
A git checkout swapped the file, with not a peep!
Now we read .git/HEAD direct, no subprocess spawned in vain,
And checkDepsStatus scans the mtime, detects the file's change refrain,
The bunny fixed the fast path, now the branch lockfile's right,
No more false "Already up to date" — installs ring true each night! 🌙

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

• X
• Mastodon
• Reddit
• LinkedIn

• Fix checkDepsStatus falsely returning upToDate: true when only pnpm-lock.yaml changed (no
  manifest modifications), causing pnpm install --optimisticRepeatInstall to skip validation.
• Fix checkDepsStatus hardcoding pnpm-lock.yaml path instead of using the branch-specific
  lockfile name when useGitBranchLockfile is enabled.
• Optimize getCurrentBranch to read .git/HEAD directly instead of spawning a git symbolic-ref
  subprocess, and propagate cwd through the entire lockfile-name resolution chain.
• Merge the conflict-detection and lockfile-modification stat passes into a single
  scanWantedLockfiles loop to reduce redundant synchronous I/O on the fast path.

The PR's approach is optimal. Checking lockfile mtimes in the same synchronous stat loop that already checks for merge conflicts (merged into scanWantedLockfiles) is the minimal, zero-overhead change needed. Reading .git/HEAD directly instead of spawning a subprocess is the standard fast-path used by many tools (e.g., Vite, Turborepo). Alternatives like inotify/file watchers or storing the lockfile hash in workspace state would add significant complexity for marginal benefit.

lockfileName.ts Add cwd support to getWantedLockfileName and forward it to getCurrentBranch +3/-2

Add cwd support to getWantedLockfileName and forward it to getCurrentBranch

• Adds an optional 'cwd' field to 'GetWantedLockfileNameOptions' and passes it to 'getCurrentBranch'. Simplifies the default parameter to an empty object. This ensures branch resolution uses the workspace directory rather than 'process.cwd()'.

lockfile/fs/src/lockfileName.ts

---

index.ts Read .git/HEAD directly to resolve branch without spawning git subprocess +43/-0

Read .git/HEAD directly to resolve branch without spawning git subprocess

• Adds a private 'readBranchFromHeadFile' function that synchronously reads '.git/HEAD' (handling both directory and worktree/submodule file layouts) to extract the current branch name. 'getCurrentBranch' tries this fast path first and only falls back to spawning 'git symbolic-ref' if the file cannot be read.

network/git-utils/src/index.ts

---

installDeps.ts Expose mergeGitBranchLockfiles in InstallDepsOptions +1/-1

Expose mergeGitBranchLockfiles in InstallDepsOptions

• Adds 'mergeGitBranchLockfiles' to the 'Partial<Pick<Config, ...>>' intersection in 'InstallDepsOptions' so it can be passed through to 'checkDepsStatus'.

installing/commands/src/installDeps.ts

---

checkDepsStatus.ts Include lockfile mtime in fast-path guard and use correct branch lockfile name +50/-22

Include lockfile mtime in fast-path guard and use correct branch lockfile name

• Refactors 'findConflictedLockfileDir' into 'scanWantedLockfiles' which returns both 'conflictedDir' and 'anyModified'. The fast-path early return now requires both zero modified manifests AND no modified lockfiles. All 'stat' and 'readWantedLockfile' calls are updated to use the dynamically resolved 'wantedLockfileName' instead of the hardcoded 'WANTED_LOCKFILE' constant, fixing the 'useGitBranchLockfile' path. 'mergeGitBranchLockfiles' is also forwarded to 'readWantedLockfile' calls.

deps/status/src/checkDepsStatus.ts

---

checkDepsStatus.test.ts Add regression tests for lockfile-only change detection and git-branch lockfile path +207/-1

Add regression tests for lockfile-only change detection and git-branch lockfile path

• Adds a new 'checkDepsStatus - lockfile modification' describe block with three tests: one proving a lockfile-only change triggers validation (regression for the bug), one verifying no error when a git-branch lockfile exists but is unmodified, and one asserting 'getWantedLockfileName' is called with the workspace dir as 'cwd'. Also adds 'ProjectId' type import and mocks 'getWantedLockfileName'.

deps/status/test/checkDepsStatus.test.ts

---

lockfileName.test.ts Test that cwd is forwarded from getWantedLockfileName to getCurrentBranch +6/-0

Test that cwd is forwarded from getWantedLockfileName to getCurrentBranch

• Adds a test asserting that when 'cwd' is passed to 'getWantedLockfileName', it is forwarded to the 'getCurrentBranch' call.

lockfile/fs/test/lockfileName.test.ts

---

index.test.ts Add tests for .git/HEAD-based branch resolution (normal, detached, non-repo) +28/-0

Add tests for .git/HEAD-based branch resolution (normal, detached, non-repo)

• Adds three new tests covering: reading branch from '.git/HEAD' in a real git repo, returning 'null' for a detached HEAD, and returning 'null' outside a git repository.

network/git-utils/test/index.test.ts

---

multiProjectWorkspace.ts Update e2e test assertions to match new debug log messages +16/-16

Update e2e test assertions to match new debug log messages

• Updates all string assertions that matched the old ''No manifest files were modified...'' and ''Some manifest files were modified...'' debug messages to match the updated ''...or lockfiles...'' wording.

pnpm/test/verifyDepsBeforeRun/multiProjectWorkspace.ts

---

fix-optimistic-repeat-install-lockfile.md Add patch changeset for deps.status, lockfile.fs, network.git-utils, and pnpm +10/-0

Add patch changeset for deps.status, lockfile.fs, network.git-utils, and pnpm

• Documents the bug fix and the git-branch lockfile path correction as a patch release for the four affected packages.

.changeset/fix-optimistic-repeat-install-lockfile.md

---

eslint.config.mjs Exclude bench-work-env from ESLint +1/-1

Exclude bench-work-env from ESLint

• Adds 'bench-work-env/**' to the ESLint ignore list to prevent false-positive parser errors from local benchmark clones.

eslint.config.mjs

---

cspell.json Exclude bench-work-env from cspell +2/-1

Exclude bench-work-env from cspell

• Adds 'bench-work-env/**' to cspell's 'ignorePaths' to avoid wasted scans on gitignored benchmark directories.

cspell.json

---

Description

scanWantedLockfiles() ignores ENOENT, so a deleted wanted lockfile does not set lockfilesModified
and the workspace fast-path can return upToDate=true without ever validating lockfile presence. This
is inconsistent with later logic that treats missing wanted lockfiles as an error in git-branch
mode, so missing pnpm-lock.<branch>.yaml (or per-project lockfiles) can be silently skipped.

Code

deps/status/src/checkDepsStatus.ts[R686-694]

try {
-      mtime = fs.statSync(path.join(lockfileDir, WANTED_LOCKFILE)).mtime.valueOf()
+      mtime = fs.statSync(path.join(lockfileDir, wantedLockfileName)).mtime.valueOf()
} catch (err: unknown) {
  if (util.types.isNativeError(err) && 'code' in err && err.code === 'ENOENT') continue
  throw err
}
-    // If the lockfile hasn't been modified since the last successful install, it can't have
-    // grown conflict markers — skip the read to preserve the optimistic fast-path.
if (mtime <= lastValidatedTimestamp) continue
-    if (wantedLockfileHasMergeConflictsSync(lockfileDir)) return lockfileDir
+    anyModified = true
+    if (wantedLockfileHasMergeConflictsSync(lockfileDir)) {

Evidence

The scan explicitly ignores missing lockfiles, while the early-exit relies on the scan result; later
code shows missing lockfiles are supposed to be handled/errored, but that code is bypassed by the
early return.

deps/status/src/checkDepsStatus.ts[280-291]
deps/status/src/checkDepsStatus.ts[300-323]
deps/status/src/checkDepsStatus.ts[678-700]

Agent prompt

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

## Issue description
`scanWantedLockfiles()` currently `continue`s on ENOENT and never reports the wanted lockfile as “modified/missing”. Because the optimistic early-exit is gated on `!lockfilesModified`, `checkDepsStatus()` can return `upToDate: true` even when the wanted lockfile is missing (especially problematic when `useGitBranchLockfile=true`, where later code expects to throw `RUN_CHECK_DEPS_LOCKFILE_NOT_FOUND`).
### Issue Context
The PR’s intent (per description) is to treat missing wanted lockfiles as a signal to avoid the optimistic fast-path. Right now, missing lockfiles are indistinguishable from “unchanged” in the scan.
### Fix Focus Areas
- deps/status/src/checkDepsStatus.ts[678-700]
- deps/status/src/checkDepsStatus.ts[285-291]
- deps/status/src/checkDepsStatus.ts[300-323]
### Suggested fix
- Change `scanWantedLockfiles()` to report missing wanted lockfiles (e.g., return `{ anyMissing: boolean }` or treat ENOENT as `anyModified=true`).
- Update the early-exit condition to also require “no wanted lockfiles missing”.
- Preserve existing behavior for the non-branch stand-in path if desired (i.e., if `!useGitBranchLockfile` and the current-lockfile stand-in is available, you may still return early with `wantedLockfileToRestore`).

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

Description

checkDepsStatus() now computes wantedLockfileName via getWantedLockfileName(), which
determines the current git branch using process.cwd() rather than the workspace/lockfile directory
being validated. With useGitBranchLockfile=true and pnpm invoked via --dir (or from outside the
repo), this can make checkDepsStatus() stat/read the wrong lockfile name and incorrectly report
status or throw RUN_CHECK_DEPS_LOCKFILE_NOT_FOUND.

Code

deps/status/src/checkDepsStatus.ts[R190-194]

+  const wantedLockfileName = await getWantedLockfileName({
+    useGitBranchLockfile: opts.useGitBranchLockfile,
+    mergeGitBranchLockfiles: opts.mergeGitBranchLockfiles,
+  })
+  const { conflictedDir: conflictedLockfileDir, anyModified: lockfilesModified } = scanWantedLockfiles(lockfileDirs, workspaceState.lastValidatedTimestamp, wantedLockfileName)

Evidence

checkDepsStatus() now computes wantedLockfileName up-front and uses it for lockfile stat/read
paths under the workspace, but getWantedLockfileName() derives branch names by invoking git
without a cwd, which defaults to process.cwd(). Callers like runDepsStatusCheck carry a logical
dir for the command, but the lockfile-name resolution is not anchored to it, so the wrong repo can
be queried when cwd differs from the workspace being checked.

deps/status/src/checkDepsStatus.ts[183-195]
deps/status/src/checkDepsStatus.ts[299-305]
lockfile/fs/src/lockfileName.ts[1-17]
network/git-utils/src/index.ts[18-26]
exec/commands/src/runDepsStatusCheck.ts[14-26]

Agent prompt

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

## Issue description
`checkDepsStatus()` resolves `wantedLockfileName` using `getWantedLockfileName()`, which shells out to `git` using the default working directory. When pnpm is run with `--dir` (or otherwise checks a workspace different from `process.cwd()`), the branch lookup can target the wrong repo/detached HEAD and compute the wrong lockfile filename.
### Issue Context
This affects `useGitBranchLockfile` mode, where lockfile names are branch-derived (`pnpm-lock.<branch>.yaml`). `checkDepsStatus()` then uses that name to stat/read lockfiles under `workspaceDir` / project dirs.
### Fix Focus Areas
- lockfile/fs/src/lockfileName.ts[1-17]
- deps/status/src/checkDepsStatus.ts[183-195]
- exec/commands/src/runDepsStatusCheck.ts[14-26]
### Suggested fix
1. Extend `GetWantedLockfileNameOptions` to accept an optional `cwd` (or `dir`) and pass it through to `getCurrentBranch({ cwd })`.
2. In `checkDepsStatus()`, call `getWantedLockfileName({ useGitBranchLockfile, mergeGitBranchLockfiles, cwd: workspaceDir ?? lockfileDir ?? rootProjectManifestDir })` so the branch is resolved in the repo that owns the lockfile.
3. Add/adjust a regression test that runs `checkDepsStatus()` with `useGitBranchLockfile=true` and a simulated mismatched `process.cwd()` vs `workspaceDir`, proving the correct lockfile name is used.

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

Description

scanWantedLockfiles() stats the computed wantedLockfileName but calls
wantedLockfileHasMergeConflictsSync(lockfileDir), which always reads pnpm-lock.yaml, so merge
conflicts in pnpm-lock..yaml are not detected and the intended early error is skipped.

Code

deps/status/src/checkDepsStatus.ts[R691-695]

if (mtime <= lastValidatedTimestamp) continue
-    if (wantedLockfileHasMergeConflictsSync(lockfileDir)) return lockfileDir
+    anyModified = true
+    if (wantedLockfileHasMergeConflictsSync(lockfileDir)) {
+      conflictedDir = lockfileDir
+      break

Evidence

scanWantedLockfiles() is driven by wantedLockfileName, but the merge-conflict helper it calls
always reads pnpm-lock.yaml (WANTED_LOCKFILE), so conflict detection can be applied to the wrong
file when the wanted lockfile name is branch-specific.

deps/status/src/checkDepsStatus.ts[677-699]
lockfile/fs/src/read.ts[87-97]

Agent prompt

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

## Issue description
`scanWantedLockfiles()` uses `wantedLockfileName` to decide whether a lockfile is modified, but it checks merge conflicts via `wantedLockfileHasMergeConflictsSync(lockfileDir)`, which reads the hardcoded `pnpm-lock.yaml`. In git-branch-lockfile mode, this misses conflicts in `pnpm-lock.<branch>.yaml`.
## Issue Context
- `wantedLockfileHasMergeConflictsSync()` currently reads `path.join(pkgPath, WANTED_LOCKFILE)`.
- `checkDepsStatus` now computes `wantedLockfileName` and should use it consistently for conflict checks.
## Fix Focus Areas
- deps/status/src/checkDepsStatus.ts[677-697]
- lockfile/fs/src/read.ts[87-97]
### Suggested approach
- Update `wantedLockfileHasMergeConflictsSync` to accept a `lockfileName` (or full path), defaulting to `WANTED_LOCKFILE` for backwards compatibility.
- Call it from `scanWantedLockfiles()` with `wantedLockfileName` so branch-specific lockfiles are checked.
- Add/adjust a unit test that creates a conflicted `pnpm-lock.<branch>.yaml` and asserts `checkDepsStatus` returns the merge-conflict issue.

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

Description

The git-branch lockfile filename regex does not escape '.' characters, so non-branch files can match
and be treated as branch lockfiles. This can trigger incorrect modification/conflict detection and,
with mergeGitBranchLockfiles enabled, can delete unintended files during cleanGitBranchLockfiles().

Code

lockfile/fs/src/gitBranchLockfile.ts[R4-15]

+// eslint-disable-next-line regexp/no-useless-non-capturing-group
+const GIT_BRANCH_LOCKFILE_NAME = /^pnpm-lock.(?:.*).yaml$/
+
export async function getGitBranchLockfileNames (lockfileDir: string): Promise<string[]> {
-  const files = await fs.readdir(lockfileDir)
-  // eslint-disable-next-line regexp/no-useless-non-capturing-group
-  const gitBranchLockfileNames: string[] = files.filter(file => file.match(/^pnpm-lock.(?:.*).yaml$/))
-  return gitBranchLockfileNames
+  const files = await fsp.readdir(lockfileDir)
+  return files.filter(file => GIT_BRANCH_LOCKFILE_NAME.test(file))
+}
+
+export function getGitBranchLockfileNamesSync (lockfileDir: string): string[] {
+  const files = fs.readdirSync(lockfileDir)
+  return files.filter(file => GIT_BRANCH_LOCKFILE_NAME.test(file))
}

Evidence

The regex is used to decide which files are considered git-branch lockfiles. Because the intended
filename format uses literal dots, an unescaped-dot regex can match unintended filenames; those
matches can then be unlinked during merge cleanup.

lockfile/fs/src/gitBranchLockfile.ts[1-25]
lockfile/fs/src/lockfileName.ts[10-18]
installing/deps-installer/src/install/index.ts[496-505]

Agent prompt

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

## Issue description
`GIT_BRANCH_LOCKFILE_NAME` currently uses unescaped `.` and an unescaped `.yaml` segment, making the match overly permissive. This can include unrelated files in `getGitBranchLockfileNames*()` results, which are later used for scanning and cleanup.
## Issue Context
- Branch lockfiles are generated as `pnpm-lock.<branch>.yaml` (literal dots).
- When `mergeGitBranchLockfiles` is enabled, pnpm calls `cleanGitBranchLockfiles(lockfileDir)` which unlinks every matched file.
## Fix Focus Areas
- lockfile/fs/src/gitBranchLockfile.ts[4-15]
- lockfile/fs/src/lockfileName.ts[10-18]
- installing/deps-installer/src/install/index.ts[502-504]
## Proposed fix
Change the regex to require literal dots and a non-empty branch segment, e.g.:
- `const GIT_BRANCH_LOCKFILE_NAME = /^pnpm-lock\..+\.yaml$/`
Optionally add a small unit test that asserts the matcher does *not* match strings like `pnpm-lockxmainyaml` and does match `pnpm-lock.main.yaml`.

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

Description

getCurrentBranch() now calls readBranchFromHeadFile() which readFileSync()s /.git whenever
it is not a directory, without ensuring it is a regular file. If .git is a FIFO/device/special
file (or unexpectedly huge) in an attacker-controlled working directory, this can block/hang pnpm
(local DoS) before it falls back to spawning git.

Code

network/git-utils/src/index.ts[R69-83]

+function readBranchFromHeadFile (cwd?: string): string | null | undefined {
+  const baseDir = cwd ?? process.cwd()
+  const dotGitPath = path.join(baseDir, '.git')
+  let gitDir: string
+  try {
+    const stat = fs.statSync(dotGitPath)
+    if (stat.isDirectory()) {
+      gitDir = dotGitPath
+    } else {
+      // `.git` is a file — worktree or submodule. It contains `gitdir: <path>`.
+      const content = fs.readFileSync(dotGitPath, 'utf8').trim()
+      const match = content.match(/^gitdir:\s*(.+)/)
+      if (!match) return undefined
+      gitDir = path.isAbsolute(match[1]!) ? match[1]! : path.resolve(baseDir, match[1]!)
+    }

Evidence

The new helper reads .git and HEAD synchronously, and the .git read is gated only by “is not a
directory”, not by “is a regular file”, so special filesystem objects can cause blocking behavior
before fallback logic runs.

network/git-utils/src/index.ts[21-30]
network/git-utils/src/index.ts[69-94]

Agent prompt

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

## Issue description
`readBranchFromHeadFile()` treats any non-directory `.git` path as a text file and synchronously reads it. This can block or be abused for local DoS if `.git` is a FIFO/device/special file (or very large), because `readFileSync()` may hang or consume excessive resources.
### Issue Context
This helper runs on the `getCurrentBranch()` hot path before falling back to `git symbolic-ref`, so the synchronous read happens even when not in a real git repo.
### Fix Focus Areas
- network/git-utils/src/index.ts[69-93]
### Suggested fix
- After `fs.statSync(dotGitPath)`, branch as:
- if `stat.isDirectory()` -> ok
- else if `stat.isFile()` -> ok to `readFileSync()`
- else -> return `undefined` (fall back to `git symbolic-ref`)
- (Optional hardening) add a small size cap before reading (e.g. if `stat.size` is unexpectedly large, return `undefined`).
- Consider applying the same `isFile()` guard (or a try+stat) for `gitDir/HEAD` before reading it.

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

Description

With useGitBranchLockfile=true (and mergeGitBranchLockfiles=false), checkDepsStatus() will now
spawn git to resolve wantedLockfileName before it can take the optimistic early-exit, adding
overhead to verify-deps-before-run hot paths even when nothing changed. This can increase latency
for pnpm run/pnpm exec when git-branch lockfiles are enabled.

Code

deps/status/src/checkDepsStatus.ts[R190-195]

+  const wantedLockfileName = await getWantedLockfileName({
+    useGitBranchLockfile: opts.useGitBranchLockfile,
+    mergeGitBranchLockfiles: opts.mergeGitBranchLockfiles,
+  })
+  const { conflictedDir: conflictedLockfileDir, anyModified: lockfilesModified } = scanWantedLockfiles(lockfileDirs, workspaceState.lastValidatedTimestamp, wantedLockfileName)
if (conflictedLockfileDir != null) {

Evidence

The new code resolves wantedLockfileName before the fast-path early return, and in git-branch
lockfile mode that resolution calls git symbolic-ref via execa. Since runDepsStatusCheck() calls
checkDepsStatus() on every run/exec, this adds a git process spawn to that hot path in the
relevant configuration.

deps/status/src/checkDepsStatus.ts[183-195]
deps/status/src/checkDepsStatus.ts[284-290]
lockfile/fs/src/lockfileName.ts[9-16]
network/git-utils/src/index.ts[18-25]
exec/commands/src/runDepsStatusCheck.ts[14-22]

Agent prompt

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

## Issue description
`checkDepsStatus()` awaits `getWantedLockfileName()` before the `(modifiedProjects.length === 0 && !lockfilesModified)` early return. In git-branch lockfile mode, `getWantedLockfileName()` shells out to `git`, so even fully up-to-date runs pay a process spawn.
### Issue Context
This affects the verify-deps-before-run pathway (`runDepsStatusCheck`), which is invoked for `pnpm run` / `pnpm exec`.
### Fix Focus Areas
- deps/status/src/checkDepsStatus.ts[183-195]
- lockfile/fs/src/lockfileName.ts[1-17]
- network/git-utils/src/index.ts[18-26]
### Suggested fix
- Prefer a non-spawning branch resolution approach for lockfile naming (e.g., read and parse `.git/HEAD`/`packed-refs` when available) or otherwise reduce spawning.
- If adding `cwd` support (see other finding), consider using it to avoid failures and to enable more efficient repo-local branch lookup.
- Document (or gate) the behavior so that `useGitBranchLockfile` users are aware that verify-deps-before-run may consult git.

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

🐞 Bugs (9) 📘 Rule violations (0)

• ❄️ 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.