Description

The new --dry-run path forces lockfileOnly, which causes the resolver to set skipFetch and the
installer to skip the link/build phases. As a result, pnpm install --dry-run can exit successfully
even when a real install would fail during tarball fetch, linking, or lifecycle/build steps, so it
does not reliably simulate install validity for automation.

Code

installing/commands/src/install.ts[R440-453]

+async function dryRunInstall (installDepsOptions: InstallDepsOptions, opts: InstallCommandOptions): Promise<string> {
+  if (opts.pnprServer) {
+    throw new PnpmError('CONFIG_CONFLICT_DRY_RUN_WITH_PNPR_SERVER',
+      'Cannot use --dry-run with a configured pnpr server because the pnpr install path resolves and links through the server')
+  }
+  // `dryRun` makes the installer resolve fully and return the before/after
+  // wanted lockfile without writing anything. `lockfileOnly` keeps it from
+  // materializing `node_modules` and skips the metadata cache (resolution
+  // skips fetching). The optimistic fast path is disabled so resolution
+  // always runs.
+  installDepsOptions.optimisticRepeatInstall = false
+  installDepsOptions.lockfileOnly = true
+  installDepsOptions.dryRun = true
+  const dryRunResult = await installDeps(installDepsOptions, [])

Evidence

dryRunInstall() explicitly sets installDepsOptions.lockfileOnly = true, which flows into the
deps-installer and resolver. The resolver uses skipFetch: ctx.dryRun, and deps-installer sets
dryRun: opts.lockfileOnly in resolution and gates the link/build pipeline on !opts.lockfileOnly,
so dry-run omits phases where real installs can fail.

pnpm install supports a dry-run mode
Dry-run mode yields meaningful success and failure exit codes
installing/commands/src/install.ts[440-453]
installing/deps-installer/src/install/index.ts[1534-1562]
installing/deps-installer/src/install/index.ts[1671-1775]
installing/deps-resolver/src/resolveDependencies.ts[1689-1723]

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 forces `lockfileOnly`, which sets `skipFetch` in dependency requests and skips the link/build phases. This means dry-run can report success even when a real install would fail later (fetch/link/scripts), so it is not a reliable install-validity check for automation.
## Issue Context
The compliance requirement expects dry-run to perform the same validations needed to determine whether a real install would succeed, while avoiding side effects.
## Fix Focus Areas
- installing/commands/src/install.ts[440-453]
- installing/deps-installer/src/install/index.ts[1560-1560]
- installing/deps-installer/src/install/index.ts[1671-1775]
- installing/deps-resolver/src/resolveDependencies.ts[1689-1723]

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

Description

dryRunInstall() does not disable save, so installDeps() can still persist policy-driven
updates (e.g. minimumReleaseAgeExclude) to pnpm-workspace.yaml, violating the “writes nothing to
disk” dry-run guarantee.

Code

installing/commands/src/install.ts[R440-453]

+async function dryRunInstall (installDepsOptions: InstallDepsOptions, opts: InstallCommandOptions): Promise<string> {
+  if (opts.pnprServer) {
+    throw new PnpmError('CONFIG_CONFLICT_DRY_RUN_WITH_PNPR_SERVER',
+      'Cannot use --dry-run with a configured pnpr server because the pnpr install path resolves and links through the server')
+  }
+  // `dryRun` makes the installer resolve fully and return the before/after
+  // wanted lockfile without writing anything. `lockfileOnly` keeps it from
+  // materializing `node_modules` and skips the metadata cache (resolution
+  // skips fetching). The optimistic fast path is disabled so resolution
+  // always runs.
+  installDepsOptions.optimisticRepeatInstall = false
+  installDepsOptions.lockfileOnly = true
+  installDepsOptions.dryRun = true
+  const dryRunResult = await installDeps(installDepsOptions, [])

Evidence

The dry-run wrapper enables check-only mode but doesn’t disable save, while installDeps() will
still write pnpm-workspace.yaml when policy updates are produced; minimumReleaseAge policy
explicitly generates such persisted updates.

installing/commands/src/install.ts[440-453]
installing/commands/src/installDeps.ts[447-469]
installing/commands/src/policyHandlers.ts[161-196]

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 write nothing to disk, but the current dry-run wrapper only sets `lockfileOnly` and `dryRun`. This still allows `installDeps()` to perform workspace-manifest writes (and potentially other persistence guarded by `opts.save !== false`) when policy handlers produce updates.
## Issue Context
- `dryRunInstall()` sets `lockfileOnly`/`dryRun` but does not set `save: false`.
- `installDeps()` may call `updateWorkspaceManifest()` even for a plain install when `policyUpdates != null`.
## Fix Focus Areas
- installing/commands/src/install.ts[440-453]
- installing/commands/src/installDeps.ts[447-469]
- installing/commands/src/policyHandlers.ts[161-196]
## Expected change
- In `dryRunInstall()`, explicitly disable persistence by setting `installDepsOptions.save = false` (and consider also `installDepsOptions.saveLockfile = false` for belt-and-suspenders).
- Add (or consider adding) a defensive guard in `installDeps()` to skip `writeProjectManifest()` / `updateWorkspaceManifest()` when `opts.dryRun === true`, so future dry-run entrypoints can’t accidentally persist.

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

Description

install --dry-run determines “up to date” status using a dedupe-oriented diff that only checks
importer dependency fields and package dependency wiring, not other lockfile changes like importer
specifiers. This can incorrectly report pnpm-lock.yaml is up to date when a real install would
still rewrite the lockfile, undermining its use for detecting outdated lockfiles in hook automation.

Code

installing/commands/src/install.ts[R461-467]

+function renderDryRunReport (changes: Array<ReturnType<typeof calcDedupeCheckIssues>>): string {
+  const reports = changes
+    .filter((issues) => countDedupeCheckIssues(issues) > 0)
+    .map(renderDedupeCheckIssues)
+  if (reports.length === 0) {
+    return `Dry run complete. ${WANTED_LOCKFILE} is up to date; a real install would make no changes.`
+  }

Evidence

The compliance objective requires dry-run to detect outdated lockfiles without performing a real
installation. The current dry-run “up to date” message is driven by countDedupeCheckIssues(), but
the underlying diff (calcDedupeCheckIssues) only compares importer dependency fields and limited
package wiring fields, so lockfile changes outside those fields (notably importer specifiers) will
not be detected and can yield an incorrect “up to date” result.

Add a dry-run option for the install command
installing/commands/src/install.ts[461-467]
installing/dedupe/check/src/dedupeDiffCheck.ts[11-23]

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` may print `pnpm-lock.yaml is up to date` even when a real install would rewrite the lockfile, because the diff logic used for the report does not account for importer `specifiers` (and potentially other non-dependency-wiring lockfile changes).
## Issue Context
The dry-run report is generated from `calcDedupeCheckIssues()` / `countDedupeCheckIssues()`, which only diffs importer `dependencies`/`devDependencies`/`optionalDependencies` and package snapshot `dependencies`/`optionalDependencies`. Importer `specifiers` are not included, so specifier-only manifest drift (or other lockfile-only rewrites) can be missed while still reporting “up to date”.
## Fix Focus Areas
- installing/commands/src/install.ts[461-467]
- installing/dedupe/check/src/dedupeDiffCheck.ts[11-23]

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

Description

In pacquet, diff_lockfiles() only diffs lockfile.packages keys and never inspects
lockfile.snapshots, even though v9 lockfiles store dependency wiring and peer-variant state in
snapshots. As a result, pacquet install --dry-run can incorrectly report “pnpm-lock.yaml is up
to date” while a real install would change the lockfile (e.g., snapshot/peer-variant rewrites).

Code

pacquet/crates/package-manager/src/dry_run.rs[R75-88]

+    let new_keys = package_keys(Some(new));
+    let old_keys = package_keys(old);
+    diff.added_packages = new_keys.difference(&old_keys).cloned().collect();
+    diff.removed_packages = old_keys.difference(&new_keys).cloned().collect();
+
+    diff
+}
+
+fn package_keys(lockfile: Option<&Lockfile>) -> BTreeSet<String> {
+    lockfile
+        .and_then(|lockfile| lockfile.packages.as_ref())
+        .map(|packages| packages.keys().map(ToString::to_string).collect())
+        .unwrap_or_default()
+}

Evidence

The dry-run diff only collects key sets from lockfile.packages, but pacquet’s v9 lockfile schema
has a separate snapshots map that contains dependency wiring
(dependencies/optional_dependencies). Since peer-specific wiring lives in snapshots (not
packages), snapshot-only changes are invisible to the current diff and can produce a false empty
diff.

pacquet/crates/package-manager/src/dry_run.rs[53-88]
pacquet/crates/lockfile/src/lib.rs[188-206]
pacquet/crates/lockfile/src/package_metadata.rs[5-8]
pacquet/crates/lockfile/src/snapshot_entry.rs[17-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
`pacquet install --dry-run` determines whether the lockfile would change by comparing importer direct-deps and the set of keys in `lockfile.packages`. However, in pacquet’s v9 lockfile model, dependency wiring and peer-variant information is stored under `lockfile.snapshots` (`SnapshotEntry`). Because the dry-run diff never reads `snapshots`, it can miss lockfile changes that are confined to snapshots and incorrectly print the “up to date” message.
### Issue Context
- `Lockfile` has both `packages` (per-version metadata) and `snapshots` (per-peer wiring).
- `SnapshotEntry` contains dependency maps that can change without the `packages` set changing.
### Fix Focus Areas
- pacquet/crates/package-manager/src/dry_run.rs[53-88]
### Suggested fix approach
1. Extend `LockfileDiff` to account for `snapshots` changes:
- At minimum, include added/removed snapshot keys (`snapshots` key set diff).
- Preferably also detect updated snapshot entries for keys present in both old and new by diffing `SnapshotEntry.dependencies` and `SnapshotEntry.optional_dependencies` (mirroring pnpm’s dedupe diff behavior).
2. Update `LockfileDiff::is_empty()` to consider snapshot changes.
3. Update `render_dry_run_report()` to render snapshot-related changes (can be under the existing “Packages” section or a new “Snapshots” section), ensuring the report is non-empty whenever `pnpm-lock.yaml` would be rewritten.
4. Add/extend a unit/integration test that creates a snapshot-only change (e.g., peer-variant change) and asserts `--dry-run` does not report “up to date”.

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

Description

The new --dry-run implementation is explicitly designed to “exit successfully regardless of
whether changes were found”, so a stale/out-of-date lockfile cannot be detected via exit code. This
violates the requirement that dry-run exit codes distinguish a successful would-be install from a
failing one (including outdated lockfile cases).

Code

installing/commands/src/install.ts[R434-458]

+/**
+ * Runs a full resolution but writes nothing to disk (no lockfile, no
+ * `node_modules`), then reports what a real install would change. Exits
+ * successfully regardless of whether changes were found — mirroring the
+ * preview semantics of `npm install --dry-run`.
+ */
+async function dryRunInstall (installDepsOptions: InstallDepsOptions, opts: InstallCommandOptions): Promise<string> {
+  if (opts.pnprServer) {
+    throw new PnpmError('CONFIG_CONFLICT_DRY_RUN_WITH_PNPR_SERVER',
+      'Cannot use --dry-run with a configured pnpr server because the pnpr install path resolves and links through the server')
+  }
+  // `lockfileCheck` makes the installer resolve fully but skip the lockfile
+  // write and hand back the wanted lockfile before and after resolution.
+  // `lockfileOnly` suppresses every other write — node_modules linking, the
+  // workspace-state file, and even the metadata cache (resolution skips
+  // fetching). Together they make the run side-effect-free. The optimistic
+  // fast path is disabled so the comparison always runs.
+  installDepsOptions.optimisticRepeatInstall = false
+  installDepsOptions.lockfileOnly = true
+  const changes: ReturnType<typeof calcDedupeCheckIssues>[] = []
+  installDepsOptions.lockfileCheck = (prev: LockfileObject, next: LockfileObject) => {
+    changes.push(calcDedupeCheckIssues(prev, next))
+  }
+  await installDeps(installDepsOptions, [])
+  return renderDryRunReport(changes)

Evidence

The checklist requires dry-run to return a failure exit code when the would-be install fails
(including outdated lockfile). The PR explicitly documents and implements --dry-run as always
succeeding when changes are found, so exit codes do not distinguish lockfile drift from a clean
state.

Add dry-run option to pnpm install with meaningful exit codes
installing/commands/src/install.ts[434-458]
.changeset/dry-run-install.md[8-8]

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 always exits successfully even when it detects that a real install would change the lockfile (i.e. the lockfile is stale). Compliance requires meaningful exit codes: dry-run must return non-zero when the would-be install would fail (including outdated lockfile cases).
## Issue Context
The PR documentation and code comment state that `--dry-run` “always exits with code 0” / “exits successfully regardless of whether changes were found”, which prevents using it in pre-commit/pre-push hooks to block lockfile drift.
## Fix Focus Areas
- installing/commands/src/install.ts[434-473]
- .changeset/dry-run-install.md[1-8]

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

Description

pnpm install --dry-run diffs importer changes using only the lockfile specifiers map, so moving
a dependency between dependencies/devDependencies/optionalDependencies without changing its
specifier can be reported as “up to date” even though a real install would rewrite the lockfile
importer sections.

Code

installing/dedupe/check/src/dedupeDiffCheck.ts[R13-43]

+// A direct dependency's manifest `specifier` is the reliable signal of a
+// would-be importer change: it always reflects the current `package.json`,
+// whereas the resolved-version fields are cleared in memory for any dep whose
+// specifier no longer matches the lockfile (they're about to be re-resolved).
+// For a direct dependency the resolved version only changes when the
+// specifier does, so comparing specifiers captures every importer-level
+// change a real install would persist.
+const IMPORTER_DRY_RUN_FIELDS = ['specifiers'] as const
+
+/**
+ * Compute the changes between two lockfiles, as added/removed/updated
+ * importer and package snapshots. Unlike {@link dedupeDiffCheck} this never
+ * throws — callers that only want to report the diff (e.g. `install
+ * --dry-run`) consume the result directly.
+ *
+ * `includeImporterSpecifiers` diffs each importer by its direct dependencies'
+ * `specifier` instead of their resolved versions. `pnpm install --dry-run`
+ * sets it so a specifier-only manifest edit (which a real install would
+ * persist to the lockfile) is reported; `dedupe --check` leaves it off
+ * because a specifier change is irrelevant to deduplication.
+ */
+export function calcDedupeCheckIssues (
+  prev: LockfileObject,
+  next: LockfileObject,
+  opts?: { includeImporterSpecifiers?: boolean }
+): DedupeCheckIssues {
+  const importerFields = opts?.includeImporterSpecifiers ? IMPORTER_DRY_RUN_FIELDS : DEPENDENCIES_FIELDS
+  return {
+    importerIssuesByImporterId: diffSnapshots(prev.importers, next.importers, importerFields),
packageIssuesByDepPath: diffSnapshots(prev.packages ?? {}, next.packages ?? {}, PACKAGE_SNAPSHOT_DEP_FIELDS),
}

Evidence

The dry-run report explicitly enables includeImporterSpecifiers, which makes
calcDedupeCheckIssues compare only importers[*].specifiers (IMPORTER_DRY_RUN_FIELDS). Since
dependency-group moves change importers[*].dependencies/devDependencies/optionalDependencies (the
fields enumerated by DEPENDENCIES_FIELDS) but do not necessarily change specifiers, the current
logic can miss real lockfile rewrites and incorrectly return an “up to date” message.

installing/commands/src/install.ts[457-463]
installing/dedupe/check/src/dedupeDiffCheck.ts[13-43]
core/types/src/misc.ts[1-10]

Agent prompt

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

## Issue description
`calcDedupeCheckIssues(..., { includeImporterSpecifiers: true })` switches importer diffing to `['specifiers']` only. This detects specifier-only edits, but it *misses* dependency-group moves (e.g. `devDependencies` → `dependencies`) where the specifier stays the same; those moves still change `importers.{id}.dependencies/devDependencies/...` and will be persisted by a real install.
### Issue Context
`install --dry-run` calls `calcDedupeCheckIssues` with `includeImporterSpecifiers: true`, so the specifiers-only importer diff is used for the dry-run report.
### Fix Focus Areas
- installing/dedupe/check/src/dedupeDiffCheck.ts[13-43]
- installing/commands/src/install.ts[457-463]
### Suggested fix
When `includeImporterSpecifiers` is enabled, diff importers using **both**:
- dependency-group fields (`DEPENDENCIES_FIELDS`: dependencies/devDependencies/optionalDependencies)
- and `specifiers`
This can be done by combining the field sets (or by diffing twice and merging) so dry-run reports both specifier-only edits and group moves.

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

Description

pnpm install --dry-run renders importer IDs and package depPaths directly into terminal output via
renderDedupeCheckIssues without stripping control characters, allowing terminal
escape/output-spoofing if a repo contains a crafted lockfile. This is a new user-facing printing
path for untrusted lockfile strings and can be abused to mislead users (e.g., hidden text, forged
lines, clickable links).

Code

installing/commands/src/install.ts[R461-465]

+function renderDryRunReport (changes: Array<ReturnType<typeof calcDedupeCheckIssues>>): string {
+  const reports = changes
+    .filter((issues) => countDedupeCheckIssues(issues) > 0)
+    .map(renderDedupeCheckIssues)
+  if (reports.length === 0) {

Evidence

The dry-run handler returns a report composed from renderDedupeCheckIssues, whose implementation
inserts snapshot IDs and aliases directly into output strings; these identifiers originate from
lockfile maps keyed by string-like project IDs/depPaths.

installing/commands/src/install.ts[461-472]
installing/dedupe/issues-renderer/src/index.ts[32-37]
installing/dedupe/issues-renderer/src/index.ts[40-55]
lockfile/types/src/index.ts[29-32]

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` returns a human report built from lockfile keys (importer IDs / depPaths) and prints them as-is. If those keys contain VT/ANSI control characters (possible via a crafted `pnpm-lock.yaml`), the terminal output can be spoofed/injected.
### Issue Context
The dry-run report is created by mapping `renderDedupeCheckIssues` over lockfile diffs. The renderer interpolates snapshot IDs/aliases directly into output strings.
### Fix Focus Areas
- installing/commands/src/install.ts[461-465]
- installing/dedupe/issues-renderer/src/index.ts[32-55]
- lockfile/types/src/index.ts[29-32]
### Suggested fix
Sanitize *untrusted* labels before rendering/printing:
- Strip VT control chars from importer IDs, depPaths, and alias strings (e.g., `node:util.stripVTControlCharacters`) before concatenating into output.
- Do this inside `renderDedupeCheckIssues` (preferred, centralizes for all callers) or immediately before printing the dry-run report, but avoid stripping chalk formatting globally (sanitize only the interpolated labels).

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

Description

pacquet install --dry-run prints importer IDs and package keys from the parsed lockfile directly
to stdout without escaping control characters, enabling terminal escape/output-spoofing from a
crafted pnpm-lock.yaml. This can mislead users reading the dry-run report (e.g., hiding/remapping
lines or creating deceptive hyperlinks).

Code

pacquet/crates/package-manager/src/dry_run.rs[R194-224]

+    if !diff.importers.is_empty() {
+        lines.push("Importers".to_string());
+        for importer in &diff.importers {
+            lines.push(importer.id.clone());
+            for (alias, version) in &importer.added {
+                lines.push(format!("  + {alias} {version}"));
+            }
+            for (alias, version) in &importer.removed {
+                lines.push(format!("  - {alias} {version}"));
+            }
+            for (alias, old, new) in &importer.updated {
+                lines.push(format!("  {alias} {old} -> {new}"));
+            }
+        }
+        lines.push(String::new());
+    }
+
+    if !diff.added_packages.is_empty()
+        || !diff.removed_packages.is_empty()
+        || !diff.updated_packages.is_empty()
+    {
+        lines.push("Packages".to_string());
+        for key in &diff.added_packages {
+            lines.push(format!("+ {key}"));
+        }
+        for key in &diff.removed_packages {
+            lines.push(format!("- {key}"));
+        }
+        for key in &diff.updated_packages {
+            lines.push(format!("~ {key}"));
+        }

Evidence

The dry-run report code pushes importer IDs and package snapshot keys straight into output lines,
and the lockfile model stores importer keys as arbitrary strings parsed from YAML.

pacquet/crates/package-manager/src/dry_run.rs[182-228]
pacquet/crates/lockfile/src/lib.rs[188-205]

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 new `pacquet install --dry-run` report renders lockfile-derived strings (importer IDs and package snapshot keys) directly into stdout. A crafted lockfile can include terminal control sequences in these strings, causing output injection/spoofing.
### Issue Context
`Lockfile.importers` is keyed by `String` (parsed from YAML). The dry-run reporter prints `importer.id` and snapshot keys with `format!("{key}")` without sanitization.
### Fix Focus Areas
- pacquet/crates/package-manager/src/dry_run.rs[194-224]
- pacquet/crates/lockfile/src/lib.rs[188-205]
### Suggested fix
Before pushing any lockfile-derived identifier into `lines`, sanitize it:
- Implement a small helper like `fn sanitize_label(s: &str) -> Cow<str>` that removes VT control characters (e.g., filter out `c.is_control()` except `\n`/`\t`, and specifically remove ESC `\x1b`).
- Apply it to `importer.id`, dependency aliases, versions (defensive), and snapshot keys.
- Keep the rest of the report formatting unchanged.

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

Description

In pacquet, diff_importer only compares ResolvedDependencySpec.version and collapses
prod/dev/optional dependency maps, so pacquet install --dry-run can report “up to date” even when
a real install would rewrite pnpm-lock.yaml due to specifier changes or dependency group moves.

Code

pacquet/crates/package-manager/src/dry_run.rs[R118-135]

+/// Flatten an importer's prod / dev / optional dependency maps into a
+/// single `alias -> version` map.
+fn collect_direct_deps(snapshot: Option<&ProjectSnapshot>) -> BTreeMap<String, String> {
+    let mut map = BTreeMap::new();
+    let Some(snapshot) = snapshot else {
+        return map;
+    };
+    for deps in
+        [&snapshot.dependencies, &snapshot.dev_dependencies, &snapshot.optional_dependencies]
+            .into_iter()
+            .flatten()
+    {
+        for (name, spec) in deps {
+            map.insert(name.to_string(), spec.version.to_string());
+        }
+    }
+    map
+}

Evidence

collect_direct_deps only inserts spec.version into the comparison map, so specifier-only changes
and dependency-group moves are invisible to the diff. This is incorrect because the lockfile’s
importer dependency entries include a specifier field in addition to version.

pacquet/crates/package-manager/src/dry_run.rs[118-135]
pacquet/crates/lockfile/src/resolved_dependency.rs[16-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
`pacquet install --dry-run` builds and diffs lockfiles, but the importer diff currently only tracks `version` (and merges prod/dev/optional into one map). This can hide lockfile changes where the resolved version is unchanged but the lockfile entry’s `specifier` changes, or when a dependency moves between dependency groups.
### Issue Context
In the lockfile model, importer dependencies are `ResolvedDependencySpec { specifier, version }`. The dry-run report should treat specifier/group changes as meaningful because a real install would persist them into `pnpm-lock.yaml`.
### Fix Focus Areas
- pacquet/crates/package-manager/src/dry_run.rs[90-135]
### What to implement
- Change the importer diff collection to preserve **(group, specifier, version)** per alias (or diff each dependency group map separately).
- Mark entries as updated if either `specifier` or `version` changes.
- Ensure the rendered report reflects these changes (either by showing specifier changes explicitly or by treating them as updates so the diff is non-empty).
- Add/extend unit tests to cover a specifier-only change and a dependency moving between groups (dev→prod) with identical version resolution.

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

• Create PR with unit tests
• Commit unit tests in branch feat/dry-run-install-v2

• ➕ Avoid exporting new diff/count helpers from the dedupe check module
• ➕ Keeps dedupe check API surface smaller (error remains the primary artifact)
• ➖ Relies on an exception path for normal control flow (dry-run preview)
• ➖ Harder to support 'no changes' without throwing
• ➖ Less composable if multiple importer reports are needed

• ➕ Single canonical diff model for all commands (dedupe --check, install --dry-run, future CI checks)
• ➕ Could standardize rendering and reduce duplicated report logic
• ➖ Bigger upfront refactor; more risk and churn than this PR’s targeted exports
• ➖ May delay shipping the user-facing flag

• ➕ Very small implementation; mostly wiring existing options
• ➖ Does not match npm/yarn dry-run semantics (would fail on drift)
• ➖ Duplicates existing behavior users can already invoke explicitly
• ➖ Doesn’t provide a 'would change' preview report