Walkthrough

Adds the prefix command to pnpm and pacquet, with command registration, prefix lookup, -g handling, dispatcher wiring, tests, and release metadata.

Changes

Prefix command implementation

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested reviewers

• zkochan

Poem

🐇 I hopped to the prefix, neat and true,
past node_modules, and up I flew.
-g said “nope,” so I nibbled a grin,
then printed the path where the roots begin.

• X
• Mastodon
• Reddit
• LinkedIn

• Add pnpm prefix command with -g/--global support and help text.
• Port prefix to pacquet with a filesystem walk-up local-prefix resolver.
• Add integration tests for both CLIs and ship a minor-version changeset.

graph TD
  U([User]) --> TS["pnpm CLI (TS)"] --> TSP["cmd/prefix.ts"] --> OUT["Print prefix"]
  U([User]) --> RS["pacquet CLI (Rust)"] --> RSP["cli_args/prefix.rs"] --> FS[(Filesystem)] --> OUT["Print prefix"]

  subgraph Legend
    direction LR
    _usr([User]) ~~~ _mod["CLI/module"] ~~~ _db[(Filesystem)]
  end

Loading

The following are alternative approaches to this PR:

1. Factor pacquet prefix/root into shared “global gating + print path” helper

• ➕ Reduces duplicated --global not supported yet error plumbing across similar commands
• ➕ Keeps CLI behavior consistent (diagnostic codes, messaging, exit semantics)
• ➖ May introduce an abstraction layer that is overkill until more path-query commands land
• ➖ Refactor risk (touches stable command wiring) for limited immediate gain

2. Use a reusable prefix-locator utility module in pacquet (instead of local function)

• ➕ Allows other commands to reuse the same prefix-discovery semantics (workspace detection, future --dir behaviors)
• ➕ Improves testability by isolating filesystem-walk logic
• ➖ Slightly more upfront structure for a single command today
• ➖ Needs careful API design to avoid leaking CLI concerns into utility code

Recommendation: The PR’s approach is solid: pnpm’s TS command prints the already-resolved dir and adds a robust global-prefix fallback chain, while pacquet correctly ports local prefix discovery and explicitly fails --global to avoid incorrect output. Consider a small follow-up refactor in pacquet to deduplicate the repeated “global unsupported” pattern shared with root and to centralize prefix-discovery utilities as more commands need similar path semantics.

Enhancement (8) +168 / -1

cli_args.rsExpose 'prefix' CLI args module +1/-0

Expose 'prefix' CLI args module

• Registers the new 'prefix' module in the pacquet CLI args module list so it can be referenced by the command enum.

pacquet/crates/cli/src/cli_args.rs

cli_command.rsAdd 'Prefix' subcommand to pacquet CLI +3/-0

Add 'Prefix' subcommand to pacquet CLI

• Imports 'PrefixArgs' and adds a 'Prefix' variant to the 'CliCommand' enum with help text. Enables clap to parse 'pacquet prefix' arguments.

pacquet/crates/cli/src/cli_args/cli_command.rs

dispatch.rsRoute 'prefix' subcommand to query dispatcher +1/-0

Route 'prefix' subcommand to query dispatcher

• Extends the dispatch router to map 'CliCommand::Prefix' to 'dispatch_query::prefix', making the command runnable end-to-end.

pacquet/crates/cli/src/cli_args/dispatch.rs

dispatch_query.rsImplement 'dispatch_query::prefix' entrypoint +6/-0

Implement 'dispatch_query::prefix' entrypoint

• Adds a synchronous query dispatcher function that calls 'PrefixArgs::run' and returns a ready future. Mirrors other read-only query commands like 'root'.

pacquet/crates/cli/src/cli_args/dispatch_query.rs

prefix.rsImplement pacquet 'prefix' command and local prefix discovery +85/-0

Implement pacquet 'prefix' command and local prefix discovery

• Adds 'PrefixArgs' with '-g/--global' flag, a diagnostic error for unsupported global mode, and a 'find_local_prefix' walk-up algorithm that looks for common prefix markers. Prints the resolved local prefix directory to stdout.

pacquet/crates/cli/src/cli_args/prefix.rs

index.tsRegister 'prefix' command in pnpm command list +2/-0

Register 'prefix' command in pnpm command list

• Imports the new 'cmd/prefix' module and adds it to the command registry so 'pnpm prefix' is recognized and dispatched.

pnpm11/pnpm/src/cmd/index.ts

notImplemented.tsRemove 'prefix' from not-implemented commands +0/-1

Remove 'prefix' from not-implemented commands

• Drops 'prefix' from the 'NOT_IMPLEMENTED_COMMANDS' list now that it has a real implementation.

pnpm11/pnpm/src/cmd/notImplemented.ts

prefix.tsImplement 'pnpm prefix' handler and help +70/-0

Implement 'pnpm prefix' handler and help

• Adds a new command module defining CLI/rc options, help text, and a handler. Local mode returns 'opts.dir'; global mode returns 'globalPrefix'/'prefix' when provided, otherwise derives a prefix from 'PREFIX'/platform-specific defaults.

pnpm11/pnpm/src/cmd/prefix.ts

Tests (2) +156 / -0

prefix.rsAdd pacquet integration tests for 'prefix' +114/-0

Add pacquet integration tests for 'prefix'

• Adds tests asserting local prefix output, walk-up behavior from nested directories, and explicit failure for '-g' until global support is ported. Includes a parity test comparing pacquet output to 'pnpm prefix' (ignored on Windows due to shim resolution).

pacquet/crates/cli/tests/prefix.rs

prefix.tsAdd pnpm integration tests for 'prefix' +42/-0

Add pnpm integration tests for 'prefix'

• Adds Jest tests validating local prefix output in a project root and from a subdirectory. Adds a smoke test ensuring 'pnpm prefix -g' returns a non-empty value.

pnpm11/pnpm/test/prefix.ts

Other (1) +5 / -0

implement-prefix-command.mdAdd minor-version changeset for new 'prefix' command +5/-0

Add minor-version changeset for new 'prefix' command

• Introduces a changeset marking a minor bump for pnpm. Documents the new 'prefix' command behavior, including '--global' support.

.changeset/implement-prefix-command.md

Description

The PR adds issues as an alias of bugs, but pnpm still registers an issues not-implemented
stub afterwards, overwriting the alias handler. As a result, pnpm issues will throw
NOT_IMPLEMENTED instead of opening the bug tracker URL.

Code

pnpm11/deps/inspection/commands/src/bugs/index.ts[19]

+export const commandNames = ['bugs', 'issues']

Evidence

bugs now declares issues as a command name, but pnpm appends notImplementedCommandDefinitions
after bugs in its command list and overwrites handlers by command name in insertion order; since
issues is still listed as not implemented, the stub replaces the alias.

pnpm11/deps/inspection/commands/src/bugs/index.ts[15-26]
pnpm11/pnpm/src/cmd/index.ts[125-238]
pnpm11/pnpm/src/cmd/notImplemented.ts[5-14]

Agent prompt

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

## Issue description
`issues` was added as an alias for the `bugs` command, but pnpm’s command registry later registers a not-implemented `issues` command which overwrites the alias handler.
### Issue Context
The pnpm CLI builds `handlerByCommandName` by iterating through `commands` in order; later entries win. Since `...notImplementedCommandDefinitions` is appended after real commands, the `issues` stub overrides the alias.
### Fix Focus Areas
- pnpm11/pnpm/src/cmd/notImplemented.ts[5-14]
- pnpm11/pnpm/src/cmd/index.ts[125-204]
- pnpm11/deps/inspection/commands/src/bugs/index.ts[15-26]
### Expected fix
- Remove `'issues'` from `NOT_IMPLEMENTED_COMMANDS` (preferred, since the alias is now implemented via `bugs`).
- (Optional) Add/adjust a pnpm integration test ensuring `pnpm issues` routes to the `bugs` handler (opens URL / at least reaches same handler).

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

Description

pnpm prefix -g triggers global-mode config initialization which may throw PNPM_DIR_NOT_WRITABLE
because main.ts only disables the global-bin writability check for root. This makes the new
read-only prefix command fail in environments where the global bin dir is intentionally not
writable.

Code

pnpm11/pnpm/src/cmd/prefix.ts[R46-48]

+  if (opts.global) {
+    return opts.globalPkgDir ? path.dirname(opts.globalPkgDir) : ''
+  }

Evidence

The new prefix command supports --global, which makes getConfig() enter the global branch and
call checkGlobalBinDir() with shouldAllowWrite set from main.ts. Because main.ts only
disables that write-check for root, prefix -g can incorrectly fail with PNPM_DIR_NOT_WRITABLE
despite being read-only.

pnpm11/pnpm/src/cmd/prefix.ts[39-49]
pnpm11/pnpm/src/main.ts[100-114]
pnpm11/config/reader/src/index.ts[383-391]
pnpm11/config/reader/src/checkGlobalBinDir.ts[9-25]

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 prefix -g` is a read-only command but it currently runs through the same global-mode config path that can enforce global bin directory writability. This can cause `pnpm prefix -g` to fail with `PNPM_DIR_NOT_WRITABLE` even though it only needs to print the global prefix.
### Issue Context
- `main.ts` computes `globalDirShouldAllowWrite` as `cmd !== 'root'` and passes it into `getConfig()`.
- The config reader calls `checkGlobalBinDir(... shouldAllowWrite: opts.globalDirShouldAllowWrite)` when `--global` is set.
- `checkGlobalBinDir()` throws if `shouldAllowWrite` is true and the global bin dir is not writable.
### Fix Focus Areas
- pnpm11/pnpm/src/main.ts[100-114]
Suggested change:
- Treat `prefix` like `root` for this flag (or more precisely: when `cmd === 'prefix'` and `cliOptions.global === true`, pass `globalDirShouldAllowWrite: false`). This keeps global install commands protected while allowing `pnpm prefix -g` to remain a reliable query command.

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

Description

pnpm prefix -g returns opts.prefix / $PREFIX / execPath-derived values, which can diverge
from pnpm’s actual global install root (derived from pnpmHomeDir/global or globalDir). Because
project/workspace .npmrc is merged into config, this also allows repo-controlled config to
influence the printed “global” prefix.

Code

pnpm11/pnpm/src/cmd/prefix.ts[R47-67]

+  if (opts.global) {
+    if (opts.globalPrefix) {
+      return opts.globalPrefix
+    }
+    if (opts.prefix) {
+      return opts.prefix
+    }
+    let prefix = process.env.PREFIX
+    if (!prefix) {
+      if (process.platform === 'win32') {
+        prefix = process.env.APPDATA ? path.join(process.env.APPDATA, 'npm') : path.dirname(process.execPath)
+      } else {
+        const binDir = path.dirname(process.execPath)
+        if (path.basename(binDir) === 'bin') {
+          prefix = path.dirname(binDir)
+        } else {
+          prefix = binDir
+        }
+      }
+    }
+    return prefix

Evidence

The new handler explicitly prefers opts.prefix/env/execPath for --global, while pnpm’s config
reader derives the global install location from pnpmHomeDir/globalDir into globalPkgDir (whose
parent is the global root). Also, workspace .npmrc is merged into config, so prefix can come
from repo-controlled config.

pnpm11/pnpm/src/cmd/prefix.ts[39-70]
pnpm11/config/reader/src/index.ts[376-388]
pnpm11/config/reader/src/loadNpmrcFiles.ts[84-163]

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 prefix --global` currently falls back to `opts.prefix` / environment / `process.execPath` heuristics. This does not match pnpm’s real global install root (the parent of `globalPkgDir`) and also makes the output influenceable by project `.npmrc` configuration, despite `--global`.
### Issue Context
pnpm’s config reader computes `globalPkgDir` from `globalDirRoot`, and `globalDirRoot` is what should be considered the global prefix/root for pnpm global installs.
### Fix Focus Areas
- pnpm11/pnpm/src/cmd/prefix.ts[39-70]
- pnpm11/config/reader/src/index.ts[376-388]
### Suggested fix
- In the `opts.global` branch, return `path.dirname(opts.globalPkgDir)` (or an equivalent derivation), and remove/avoid using `opts.prefix` / `$PREFIX` / `execPath` fallbacks.
- Extend the handler opts type to include `globalPkgDir: string` (already present on pnpm Config) so this is type-safe.

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

Description

pnpm prefix currently runs through installConfigDepsAndLoadHooks() even though the handler only
prints a computed directory path, so it may install configDependencies and load pnpmfile hooks
first. This makes pnpm prefix unexpectedly side-effectful (possible network access / hook
execution) and can cause the command to fail if configDependencies cannot be fetched, despite not
needing them to print a prefix.

Code

pnpm11/pnpm/src/main.ts[103]

+    const globalDirShouldAllowWrite = cmd !== 'root' && cmd !== 'prefix'

Evidence

The new prefix command is now part of the normal command flow, which always runs
configDependencies installation + hook loading; repo-controlled workspace manifest settings can
supply configDependencies, so the new command inherits those side effects even though it doesn’t
need them to print the prefix.

pnpm11/pnpm/src/main.ts[100-153]
pnpm11/pnpm/src/getConfig.ts[45-97]
pnpm11/config/reader/src/index.ts[458-469]
pnpm11/config/reader/src/index.ts[1040-1060]
pnpm11/config/reader/src/getOptionsFromRootManifest.ts[16-28]
pnpm11/pnpm/src/cmd/prefix.ts[40-54]

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 prefix` is a read-only “print a path” command, but it still executes the generic pnpm startup pipeline that installs `configDependencies` and loads pnpmfile hooks. This introduces unexpected side effects (including potential network fetches and execution of hook code) and can also make `pnpm prefix` fail when configDependencies cannot be installed.
## Issue Context
- `main.ts` always calls `installConfigDepsAndLoadHooks()` before dispatching the command.
- `installConfigDepsAndLoadHooks()` may install `configDependencies` and then calls `requireHooks()`.
- Repo-controlled `pnpm-workspace.yaml` settings are applied into config (including `configDependencies`).
## Fix Focus Areas
- pnpm11/pnpm/src/main.ts[100-153]
- pnpm11/pnpm/src/getConfig.ts[45-97]
- pnpm11/config/reader/src/index.ts[458-469]
- pnpm11/config/reader/src/index.ts[1040-1060]
### Suggested fix direction
Add a small command-level gate in `main.ts` so that for `cmd === 'prefix'` (and potentially other pure-query commands), pnpm does **not** call `installConfigDepsAndLoadHooks()` (or calls a variant that skips both configDependencies installation and hook loading). This keeps `pnpm prefix` fast and avoids unexpected side effects for a command that only prints a path.

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

Description

pacquet prefix prints via println!, which can panic if stdout write fails (notably when piped to
a consumer that exits early, causing EPIPE). This makes the new command brittle in shell pipelines
and can turn a normal early-termination into a crash.

Code

pacquet/crates/cli/src/cli_args/prefix.rs[R86-88]

+        let prefix_dir = find_local_prefix(dir)?;
+        println!("{}", prefix_dir.display());
+        Ok(())

Evidence

The new pacquet prefix command prints using println! (panic-prone on stdout write failure),
while pnpm explicitly prevents crashes when pipes close early, and other pacquet code uses explicit
stdout writes that avoid panicking on write errors.

pacquet/crates/cli/src/cli_args/prefix.rs[81-89]
pnpm11/pnpm/src/main.ts[52-59]
pacquet/crates/cli/src/cli_args/cat_index.rs[68-74]

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 prefix` implementation uses `println!` to write the machine-readable prefix path. In Rust, the standard print macros can panic on stdout write errors (e.g. broken pipe when output is piped into `head`), causing the command to crash instead of exiting cleanly.
### Issue Context
pnpm’s TypeScript CLI explicitly guards against EPIPE on stdout to keep machine-readable commands safe in pipelines. pacquet has other call sites that write to stdout using `writeln!`/`flush` and ignore write errors, avoiding panic-on-print.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/prefix.rs[81-89]
### Suggested fix approach
Replace `println!("{}", prefix_dir.display())` with an explicit stdout write that does **not** panic on error. One simple pattern consistent with other pacquet code:
- use `let mut stdout = std::io::stdout();`
- `let _ = writeln!(stdout, "{}", prefix_dir.display());`
- optionally `let _ = stdout.flush();`
If you’d prefer stricter handling, detect `BrokenPipe` and return `Ok(())` while still surfacing other IO errors.

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

Description

The new prefix command is meant to emit a single machine-readable path, but it is not included in
COMMANDS_WITH_STDERR_REPORTER, so reporter output (e.g. --force warnings) can go to stdout and
corrupt pnpm prefix output in scripts.

Code

pnpm11/pnpm/src/cmd/prefix.ts[R39-70]

+export async function handler (
+  opts: {
+    dir: string
+    global?: boolean
+    globalPrefix?: string
+    prefix?: string
+  }
+): Promise<string> {
+  if (opts.global) {
+    if (opts.globalPrefix) {
+      return opts.globalPrefix
+    }
+    if (opts.prefix) {
+      return opts.prefix
+    }
+    let prefix = process.env.PREFIX
+    if (!prefix) {
+      if (process.platform === 'win32') {
+        prefix = process.env.APPDATA ? path.join(process.env.APPDATA, 'npm') : path.dirname(process.execPath)
+      } else {
+        const binDir = path.dirname(process.execPath)
+        if (path.basename(binDir) === 'bin') {
+          prefix = path.dirname(binDir)
+        } else {
+          prefix = binDir
+        }
+      }
+    }
+    return prefix
+  }
+  return opts.dir
+}

Evidence

COMMANDS_WITH_STDERR_REPORTER exists specifically to keep stdout machine-readable. --force
triggers a warning via the logger, and the reporter honors config.useStderr; since prefix is not
in the set, those messages can go to stdout alongside the prefix result.

pnpm11/pnpm/src/main.ts[39-45]
pnpm11/pnpm/src/main.ts[344-349]
pnpm11/pnpm/src/reporter/index.ts[18-41]

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 prefix` returns a single path string that users commonly capture in scripts. However, pnpm routes reporter output to stdout by default, and `prefix` is not in the allowlist that forces reporter output to stderr. This can mix warnings/progress into stdout and break consumers.
### Issue Context
The code comment in `main.ts` explicitly calls out commands that must keep stdout clean; `prefix` fits that contract.
### Fix Focus Areas
- pnpm11/pnpm/src/main.ts[39-45]
### Suggested fix
- Add `'prefix'` to `COMMANDS_WITH_STDERR_REPORTER`.
- (Optional, if you want consistent behavior) consider whether `'root'` should also be in this set, but keep the PR scope focused if desired.

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

Description

The new pacquet integration tests call dbg!(&output), which prints to stderr and adds noisy,
non-asserted output to test runs. This makes CI logs harder to read and can bury real failures in
large output streams.

Code

pacquet/crates/cli/tests/prefix.rs[R21-23]

+    let output = pacquet.with_args(["prefix"]).output().expect("run pacquet prefix");
+    dbg!(&output);
+    assert!(output.status.success(), "pacquet prefix should succeed");

Evidence

The cited lines show two dbg!(&output) statements in the newly-added test file; dbg! writes to
stderr and will pollute test output.

pacquet/crates/cli/tests/prefix.rs[15-29]
pacquet/crates/cli/tests/prefix.rs[77-89]

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/crates/cli/tests/prefix.rs` includes `dbg!(&output)` calls that print debug output to stderr during normal test execution.
### Issue Context
These were likely added during development but are not needed for assertions and add noise to CI logs.
### Fix Focus Areas
- Remove the `dbg!(&output);` lines.
- pacquet/crates/cli/tests/prefix.rs[21-23]
- pacquet/crates/cli/tests/prefix.rs[81-83]

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

Description

pacquet’s find_prefix_up walks ancestors via recursion, which is avoidable and less robust than
an iterative loop (unnecessary stack growth for deep paths).

Code

pacquet/crates/cli/src/cli_args/prefix.rs[R53-74]

+fn find_prefix_up(name: &Path, original: &Path) -> PathBuf {
+    if name.parent().is_none() {
+        return original.to_path_buf();
+    }
+
+    let targets =
+        ["node_modules", "package.json", "package.json5", "package.yaml", "pnpm-workspace.yaml"];
+    for target in &targets {
+        if name.join(target).exists() {
+            return name.to_path_buf();
+        }
+    }
+
+    if let Some(parent) = name.parent() {
+        if parent == name {
+            return original.to_path_buf();
+        }
+        find_prefix_up(parent, original)
+    } else {
+        original.to_path_buf()
+    }
+}

Evidence

The current implementation clearly recurses on find_prefix_up(parent, original), adding one stack
frame per directory level until root/marker detection returns.

pacquet/crates/cli/src/cli_args/prefix.rs[53-74]

Agent prompt

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

## Issue description
`find_prefix_up` is recursive and calls itself once per parent directory. While depth is usually small, an iterative implementation is more robust and avoids stack growth.
### Issue Context
This is a CLI-only path (not an install hot path), so it’s not urgent, but it’s cheap to harden.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/prefix.rs[53-74]
### Suggested fix
- Rewrite `find_prefix_up` as a `loop { ... }` that updates `name = parent` until root/marker found, returning `original` as today on termination conditions.

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

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