v10.23.0
Breaking Changes📦 pnpmView on GitHub →
⚠ 2 breaking✨ 2 features🐛 4 fixes🔧 5 symbols
Summary
This release adds a new `--lockfile-only` flag to `pnpm list`, improves self‑update handling, displays npm protocols for aliased packages, and includes several bug fixes and stricter trust‑policy enforcement.
⚠️ Breaking Changes
- `pnpm self-update` now always installs the non-executable pnpm package from the registry and never the `@pnpm/exe` package when updating to v11 or newer. Projects that relied on the executable package must adjust scripts to use the standard pnpm binary.
- Installation now fails if an optional dependency cannot be installed due to a trust policy check failure, which may break installations that previously ignored such failures.
Migration Steps
- If you have scripts that explicitly install `@pnpm/exe` during self-update, modify them to rely on the standard pnpm package.
- Review any CI/CD pipelines that ignore optional dependency failures; they may now abort due to trust policy checks.
- No other migration steps required.
✨ New Features
- Added `--lockfile-only` option to `pnpm list`.
- `pnpm list` and `pnpm why` now display the `npm:` protocol for aliased packages (e.g., `foo npm:is-odd@3.0.1`).
🐛 Bug Fixes
- `pnpm self-update` now downloads pnpm from the configured npm registry.
- Node.js runtime is no longer added to `dependencies` on `pnpm add` when an `engines.runtime` field is present in `package.json`.
- Removed extra slash from the Node.js mirror URL.
- `pnpm store prune` no longer fails if the store contains Node.js packages.
🔧 Affected Symbols
pnpm listpnpm self-updatepnpm addpnpm whypnpm store prune