Description

install.handler() implements --dry-run by forcing frozenLockfile=true and lockfileOnly=true,
but if pnprServer is configured the deps-installer takes the pnpr server path which writes
pnpm-lock.yaml and inherently writes to the store. This violates the dry-run contract of “validate
without writing changes to disk” and can dirty workspaces in pre-commit/CI environments that have
pnpr enabled.

Code

installing/commands/src/install.ts[R425-432]

+  if (opts.dryRun) {
+    if (opts.resolutionOnly) {
+      throw new PnpmError('CONFIG_CONFLICT_DRY_RUN_WITH_RESOLUTION_ONLY',
+        'Cannot use --dry-run with --resolution-only')
+    }
+    installDepsOptions.frozenLockfile = true
+    installDepsOptions.lockfileOnly = true
+  }

Evidence

The new --dry-run mapping forces frozenLockfile and lockfileOnly in the install command
handler, but the deps-installer has an unconditional early dispatch to installViaPnprServer()
whenever opts.pnprServer is set; that pnpr path writes the lockfile via
writeWantedLockfileAndRecordVerified() and explicitly documents that it inherently writes to the
store. Therefore, --dry-run is not side-effect-free under pnprServer configuration.

installing/commands/src/install.ts[398-433]
installing/deps-installer/src/install/index.ts[174-185]
installing/deps-installer/src/install/index.ts[2487-2594]

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 install --dry-run` is intended to validate lockfile freshness without writing to disk. However, when `pnprServer` is configured, the deps-installer routes the install to `installViaPnprServer()`, which persists a lockfile and writes to the store, breaking dry-run’s side-effect-free contract.
## Issue Context
`--dry-run` is desugared to `frozenLockfile + lockfileOnly` in the install command handler. That desugaring does not prevent the pnpr-server dispatch, which happens before the normal flow and includes unconditional lockfile persistence.
## Fix Focus Areas
- installing/commands/src/install.ts[425-432]
## Proposed fix
- In the `if (opts.dryRun)` block, add a config conflict guard when `opts.pnprServer` (or equivalent config-derived value) is set.
- Throw a `PnpmError` with a new code like `CONFIG_CONFLICT_DRY_RUN_WITH_PNPR_SERVER` and a clear message (e.g. “Cannot use --dry-run with --pnpr-server / pnprServer because pnpr installs write lockfile/store state”).
- Alternatively (less strict), explicitly unset `installDepsOptions.pnprServer` when `dryRun` is set so the normal frozen validation path is used.

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

Description

pacquet’s new --dry-run sets lockfile_only = true, and the lockfile_only && take_frozen_path
branch persists pnpm-lock.yaml via save_to_path, so a successful dry run can still rewrite/touch
the lockfile on disk. This violates the intended dry-run semantics (validate without changing
workspace files) and can dirty/normalize lockfiles in pre-commit/CI workflows.

Code

pacquet/crates/cli/src/cli_args/install.rs[R289-292]

+        // --dry-run: validate lockfile is in sync without installing.
+        let frozen_lockfile = frozen_lockfile || dry_run;
+        let lockfile_only = lockfile_only || dry_run;
+

Evidence

The new CLI mapping makes --dry-run imply lockfile_only, and the package-manager’s lockfile-only
frozen path explicitly writes the wanted lockfile to disk, so the new flag can still cause workspace
writes.

pacquet/crates/cli/src/cli_args/install.rs[289-292]
pacquet/crates/package-manager/src/install.rs[775-803]

Agent prompt

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

## Issue description
`pacquet install --dry-run` is implemented by OR-ing `dry_run` into `frozen_lockfile` and `lockfile_only`. However, pacquet’s install pipeline writes `pnpm-lock.yaml` in the `lockfile_only && take_frozen_path` branch, so `--dry-run` can still perform on-disk writes.
### Issue Context
- The CLI mapping is in `pacquet/crates/cli/src/cli_args/install.rs`.
- The actual write occurs in `pacquet/crates/package-manager/src/install.rs` inside the `if lockfile_only && take_frozen_path { ... save_to_path(...) ... }` branch.
- Goal: `--dry-run` should validate freshness and exit status without modifying workspace files.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/install.rs[289-292]
- pacquet/crates/package-manager/src/install.rs[783-803]
### Implementation sketch
- Plumb a dedicated `dry_run` boolean into the package-manager `Install` options (not just derived `lockfile_only`).
- When `dry_run` is true, skip any persistence of `pnpm-lock.yaml` (and any other workspace files) on success; keep the freshness checks and non-zero exits when stale.
- Add/extend a test to assert `pnpm-lock.yaml` content (and ideally mtime) is unchanged after `pacquet install --dry-run` when the lockfile is already fresh.

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

Description

install.handler() implements --dry-run by forcing frozenLockfile=true and lockfileOnly=true,
but the frozen+lockfileOnly path unconditionally calls writeWantedLockfile, so a successful dry
run still writes pnpm-lock.yaml to disk (at least updating mtime and potentially normalizing
content). This breaks the documented/expected “validate without writing changes to disk” behavior
for pre-commit/CI usage.

Code

installing/commands/src/install.ts[R419-426]

+  if (opts.dryRun) {
+    if (opts.resolutionOnly) {
+      throw new PnpmError('CONFIG_CONFLICT_DRY_RUN_WITH_RESOLUTION_ONLY',
+        'Cannot use --dry-run with --resolution-only')
+    }
+    installDepsOptions.frozenLockfile = true
+    installDepsOptions.lockfileOnly = true
+  }

Evidence

The PR makes --dry-run set lockfileOnly=true. In the installer, lockfileOnly triggers an
unconditional call to writeWantedLockfile, and writeWantedLockfile always writes via
writeFileAtomic, so dry-run will still write the lockfile even when up-to-date.

installing/commands/src/install.ts[392-427]
installing/deps-installer/src/install/index.ts[948-992]
lockfile/fs/src/write.ts[34-90]

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 install --dry-run` currently sets `lockfileOnly=true`, which routes the install into a code path that **always writes** `pnpm-lock.yaml` even when the lockfile is already up-to-date. This violates the intended semantics of dry-run (no disk writes) and can dirty working trees or trigger filesystem watchers.
## Issue Context
The installer’s frozen+lockfileOnly early-return branch calls `writeWantedLockfile(...)`, and `writeWantedLockfile` always uses `writeFileAtomic(...)` (no content-diff guard), so it will replace/touch the file.
## Fix Focus Areas
- installing/commands/src/install.ts[419-426]
### Suggested approach
1. Introduce/propagate a dedicated `dryRun`/`noWrite` flag into the deps-installer layer (or reuse an existing “check-only” mechanism) so you can:
- keep `frozenLockfile=true` (to validate lockfile freshness)
- avoid `node_modules` materialization
- **avoid calling any lockfile write functions** when `--dry-run` is set.
2. Concretely, gate the `writeWantedLockfile(...)` call in the frozen+lockfileOnly branch on a new option (e.g. `saveLockfile !== false` / `dryRun !== true`). Then set that option from the CLI when `--dry-run` is used.
3. Add a test assertion that `pnpm-lock.yaml` mtime/content does not change on a successful `--dry-run` run.

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

Description

pnpm install --dry-run still calls installDeps(), which unconditionally initializes the store
controller and can create the configured store directory via fs.mkdir(..., { recursive: true }).
This breaks the dry-run “no writes” expectation and can dirty fresh CI/pre-commit environments by
creating storeDir even though no install artifacts are produced.

Code

installing/commands/src/install.ts[R425-436]

+  if (opts.dryRun) {
+    if (opts.resolutionOnly) {
+      throw new PnpmError('CONFIG_CONFLICT_DRY_RUN_WITH_RESOLUTION_ONLY',
+        'Cannot use --dry-run with --resolution-only')
+    }
+    if (opts.pnprServer) {
+      throw new PnpmError('CONFIG_CONFLICT_DRY_RUN_WITH_PNPR_SERVER',
+        'Cannot use --dry-run with a configured pnpr server because pnpr installs resolve through the server and write the lockfile and store')
+    }
+    installDepsOptions.frozenLockfile = true
+    installDepsOptions.lockfileOnly = true
+  }

Evidence

The new --dry-run path in install.ts delegates into installDeps(). installDeps() always
initializes the store controller, and store controller creation explicitly creates the store
directory on disk when frozenStore is not enabled—so dry-run can still write to disk even though
it sets lockfileOnly/frozenLockfile.

installing/commands/src/install.ts[398-437]
installing/commands/src/installDeps.ts[201-214]
store/connection-manager/src/createNewStoreController.ts[67-79]

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 install --dry-run` is intended to validate an up-to-date lockfile without writing to disk, but the current implementation still goes through `installDeps()`, which eagerly creates the store controller and may create the store directory (`fs.mkdir(storeDir, { recursive: true })`). This means `--dry-run` can still have observable filesystem side effects in new/clean environments.

## Issue Context
- `--dry-run` is implemented in the install command handler by forcing `frozenLockfile=true` and `lockfileOnly=true`.
- `installDeps()` always initializes the store controller early.
- Store controller creation (`createNewStoreController`) creates `opts.storeDir` unless `frozenStore` is enabled.

## Fix Focus Areas
- installing/commands/src/install.ts[425-436]
- installing/commands/src/installDeps.ts[201-214]
- store/connection-manager/src/createNewStoreController.ts[67-79]

## Suggested fix
1. In `installing/commands/src/install.ts`, when `opts.dryRun` is true, also set `installDepsOptions.frozenStore = true` (and/or introduce a dedicated flag to skip store initialization) so that `createNewStoreController()` will not create the store directory.
2. If setting `frozenStore` for dry-run is not acceptable globally, refactor `installDeps()` to defer `createStoreController(opts)` until it is actually needed (i.e., after any early-return validation paths), so the dry-run validation path can exit without initializing store machinery.
3. Add a targeted test that runs `install.handler({ dryRun: true, ... })` with a fresh `storeDir` (temp dir) and asserts the directory is not created.

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

Description

HeadlessOptions.dryRun is documented as “skip writing to disk (lockfile and node_modules)”, but
headlessInstall still unconditionally writes .modules.yaml and lockfiles without checking
opts.dryRun. This documentation/behavior mismatch can cause callers to rely on dryRun for
side-effect-free execution when it is not actually enforced.

Code

installing/deps-restorer/src/index.ts[R119-120]

+  /** When true, skip writing to disk (lockfile and node_modules). */
+  dryRun?: boolean

Evidence

The interface comment promises no disk writes, but the implementation still performs unconditional
writes to modules/lockfile state without checking opts.dryRun anywhere in that write path.

installing/deps-restorer/src/index.ts[109-120]
installing/deps-restorer/src/index.ts[664-699]

Agent prompt

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

## Issue description
`HeadlessOptions.dryRun` is documented as preventing writes to disk, but `headlessInstall` still writes `.modules.yaml` and lockfiles regardless. This creates a misleading contract and risks future misuse.
### Issue Context
In `headlessInstall`, `dryRun` is currently only threaded into pruning and script execution options, while the core write operations (`writeModulesManifest`, `writeLockfiles`/`writeCurrentLockfile`) are not gated.
### Fix Focus Areas
- installing/deps-restorer/src/index.ts[119-120]
- installing/deps-restorer/src/index.ts[664-699]
### Implementation options
- **Preferred (if dryRun is meant to be real):** Gate the write calls (`writeModulesManifest`, `writeLockfiles`, `writeCurrentLockfile`, and any other workspace writes) behind `if (!opts.dryRun)`.
- **Alternative (if dryRun is only meant to skip pruning):** Update the doc comment to reflect actual behavior (e.g., “skip pruning orphan packages / destructive operations”) and consider renaming the flag to avoid implying a full no-write dry run.

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

Description

The new pnpm/dev/pnpm-workspace.yaml causes findWorkspaceDir() to treat pnpm/dev as the
workspace root when invoked from that subtree. pnpm/dev/pd.js relies on discovering the repo
workspace from pnpm/dev, so this changes its behavior (and may break it) by reading a manifest
without packages and scanning the wrong scope.

Code

pnpm/dev/pnpm-workspace.yaml[R1-2]

+overrides:
+  pd: 'link:'

Evidence

findWorkspaceDir() resolves the nearest pnpm-workspace.yaml. Since the PR adds one inside
pnpm/dev, the pd script (which searches from pnpm/dev) will resolve the nested workspace root
and read a manifest that lacks packages, changing or breaking its workspace package discovery.

pnpm/dev/pnpm-workspace.yaml[1-2]
workspace/root-finder/src/index.ts[19-28]
pnpm/dev/pd.js[13-17]

Agent prompt

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

## Issue description
A new `pnpm/dev/pnpm-workspace.yaml` changes workspace-root discovery: tooling executed from `pnpm/dev` will now stop at this nested manifest rather than the repo root. The `pd` dev script (`pnpm/dev/pd.js`) calls `findWorkspaceDir(import.meta.dirname)` and then reads `workspaceManifest.packages`, so this nested manifest can cause incorrect package discovery or failures.
## Issue Context
`findWorkspaceDir()` returns the *nearest* `pnpm-workspace.yaml` found by walking up the directory tree. The new file contains only `overrides` (no `packages`), and it is placed exactly where the `pd` script starts searching.
## Fix Focus Areas
- pnpm/dev/pnpm-workspace.yaml[1-2]
### Suggested approach
- Prefer removing this file entirely unless it is strictly required.
- If an override for `pd` is needed, move it to the repo-root `pnpm-workspace.yaml` (workspace-level overrides belong there).
- If you truly need a separate workspace under `pnpm/dev`, ensure the file contains a valid `packages:` list and that `pd.js` explicitly targets the repo root workspace (instead of “nearest manifest”).

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

🐞 Bugs (4) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0)

Walkthrough

Adds a --dry-run option to pnpm and pacquet install commands that validates lockfile freshness without installing or writing changes by forcing frozenLockfile + lockfileOnly; propagates a dryRun flag through install types, updates frozen-path behavior, and adds unit/integration tests and a changeset.

Changes

Dry-run feature for install command

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

• #7340: dry-run option for install — This PR implements the requested dry-run install behavior with exit codes for stale lockfiles.
• Frozen-lockfile freshness check: error when package.json drifts from pnpm-lock.yaml pacquet#447 — Related issue describing a dry-run flag that forces frozenLockfile/lockfileOnly and frozen-install behavior.

Possibly related PRs

• pnpm/pnpm#12046 — Related work touching pacquet install lockfile-only plumbing used by dry-run semantics.
• fix(installing.commands): forward pnpm install flags to pacquet #11781 — Overlaps on forwarding of install options and pacquet delegation plumbing.
• perf: record locally-resolved lockfile in verification cache #11714 — Related changes around lockfile write/verification interactions with frozen-lockfile flows.

Suggested reviewers

• zkochan

Poem

🐇 I nibble lockfiles, gentle and spry,
I check without fetching, then give a small sigh.
Fresh — I hop forward; stale — I thump once and stay,
No installs, no writes, just a tidy relay.
🥕

❌ Failed checks (1 warning)

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

• X
• Mastodon
• Reddit
• LinkedIn

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