mirror of
https://github.com/pnpm/pnpm.git
synced 2026-07-14 17:52:44 -04:00
4cd45a3e15
* feat(pacquet-cli): apply --filter selection in recursive run and exec The recursive `run` / `exec` command path operated on every workspace project; the `--filter` / `--filter-prod` selectors were parsed into `Config::filter` / `Config::filter_prod` but never narrowed the set. Add `select_recursive_projects`, a shared helper that builds the workspace graph over all projects and restricts it to the selectors' selection — include selectors unioned, `!`-prefixed excludes subtracted — mirroring the `selectedProjectsGraph` pnpm hands its recursive handlers in main.ts. With no selectors every project is selected, so the unfiltered behavior is unchanged. The recursive `run` no-script error now distinguishes "None of the packages" from "None of the selected packages" the way pnpm does, keyed on whether the filter narrowed the set. Refs https://github.com/pnpm/pnpm/issues/12711 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MgEs4dECzHdR3aj19DLxiD * fix(pacquet-cli): no-op recursive run/exec on an empty --filter selection Address review feedback on the --filter wiring: - When --filter narrows a non-empty workspace to no projects, recursive run/exec now exit 0 instead of erroring on --resume-from or writing an empty --report-summary summary, matching pnpm's main-dispatch exit-0 for an empty selectedProjectsGraph (main.ts). - Resolve the selectors against the same graph options used for the topological sort, so the selected set and the run order agree on edges (upstream reads one linkWorkspacePackages-aware graph for both). Empty-workspace handling (recursive run -> no-script error, exec -> NO_PACKAGE) is left as-is; it predates --filter and is orthogonal. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MgEs4dECzHdR3aj19DLxiD * feat(pacquet-cli): apply --filter to recursive pack via the shared path Route `pack -r`'s workspace sweep through the shared `select_recursive_projects` helper that `run -r` / `exec -r` use, so `pack -r --filter` narrows which projects are packed instead of silently packing every project. Keeps `--filter` a single cross-cutting selection path across all recursive commands. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MgEs4dECzHdR3aj19DLxiD * test(pacquet-cli): cover the --filter-prod selector path in recursive run Add a recursive-run integration test that narrows the workspace with `--filter-prod`, exercising the `follow_prod_deps_only: true` branch of `select_recursive_projects` that the `--filter`-only tests never reached (flagged uncovered by Codecov). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MgEs4dECzHdR3aj19DLxiD * docs(pacquet-cli): trim verbose comments in the recursive filter path Per review, make the comments added for `--filter` selection succinct: keep the non-obvious "why", drop restatement of self-documenting code and narration of pnpm's behavior. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MgEs4dECzHdR3aj19DLxiD * docs(pacquet-cli): correct stale "every project" recursive doc comments The recursive `run` / `exec` / `pack` function- and module-level doc comments still said the command runs over "every workspace project"; with `--filter` wired in they run over the selected subset. Update them to match the code. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MgEs4dECzHdR3aj19DLxiD * docs(pacquet-cli): correct remaining "every project" recursive dispatcher docs Follow-up: the `RunArgs::run_recursive` / `ExecArgs::run_recursive` dispatcher docs and the `PackArgs::run` summary still said the recursive command runs over "every project"; with `--filter` wired in they run over the selected subset. The global `--recursive` flag help is left as-is — it describes `-r`'s workspace-wide-vs-single behavior, and `--filter` narrowing is a separate flag. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MgEs4dECzHdR3aj19DLxiD * test(pacquet-cli): prove --filter-prod prod-only walk in recursive run The flat-workspace fixture passed even if `follow_prod_deps_only` were ignored: with no dependency edges, `--filter-prod app` and `--filter app` select the same set, so the test could not tell them apart. Replace it with a dev-only edge (`app` devDependencies `lib`) and the `app...` ellipsis selector, so `--filter-prod`'s production-only dependency walk must drop the dev edge. The test runs `app` and asserts `lib` is skipped, failing if `--filter-prod` collapses to `--filter`. --------- Co-authored-by: Claude <noreply@anthropic.com>
简体中文 | 日本語 | 한국어 | Italiano | Português Brasileiro
Fast, disk space efficient package manager:
- Fast. Up to 2x faster than the alternatives (see benchmark).
- Efficient. Files inside
node_modulesare linked from a single content-addressable storage. - Great for monorepos.
- Strict. A package can access only dependencies that are specified in its
package.json. - Deterministic. Has a lockfile called
pnpm-lock.yaml. - Works as a Node.js version manager. See pnpm runtime.
- Works everywhere. Supports Windows, Linux, and macOS.
- Battle-tested. Used in production by teams of all sizes since 2016.
- Experimental Rust port. Includes pacquet, an experimental port of the CLI written in Rust.
- See the full feature comparison with npm and Yarn.
To quote the Rush team:
Microsoft uses pnpm in Rush repos with hundreds of projects and hundreds of PRs per day, and we’ve found it to be very fast and reliable.
Platinum Sponsors
|
|
Gold Sponsors
|
|
|
|
|
|
|
|
Silver Sponsors
|
|
|
|
|
|
|
|
|
| ⏱️ Time.now |
Support this project by becoming a sponsor.
Background
pnpm uses a content-addressable filesystem to store all files from all module directories on a disk. When using npm, if you have 100 projects using lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be stored in a content-addressable storage, so:
- If you depend on different versions of lodash, only the files that differ are added to the store.
If lodash has 100 files, and a new version has a change only in one of those files,
pnpm updatewill only add 1 new file to the storage. - All the files are saved in a single place on the disk. When packages are installed, their files are linked from that single place consuming no additional disk space. Linking is performed using either hard-links or reflinks (copy-on-write).
As a result, you save gigabytes of space on your disk and you have a lot faster installations!
If you'd like more details about the unique node_modules structure that pnpm creates and
why it works fine with the Node.js ecosystem, read this small article: Flat node_modules is not the only way.
💖 Like this project? Let people know with a tweet
Getting Started
Benchmark
pnpm is up to 2x faster than npm and Yarn classic. See all benchmarks here.
Benchmarks on an app with lots of dependencies:
License
MIT, except the pnpr/ directory, which is source-available under the PolyForm Shield License 1.0.0.