* feat(self-update): point users at the migration guide across major bumps
When `pnpm self-update <version>` crosses a pnpm major (upward) from
the version being upgraded from, print a one-line pointer to the
versioned migration guide on pnpm.io.
The "from" version is the project's `packageManager` pin when present
(via the existing `managePackageManagerVersions` gate), falling back
to the running binary's version otherwise. No-op updates
(target === previous) are silent.
v11 points at https://pnpm.io/11.x/migration. Future majors register
an entry in the in-file `MAJOR_UPGRADE_HINTS` table.
This is the v10-line backport of the corresponding main-branch change
in #11354.
* fix: update lockfile
* fix: prevent fork-bomb during packageManager-driven version switching
When pnpm was installed via one method (e.g. `npm install -g pnpm@A`)
and run in a project whose package.json's packageManager field selected
a different pnpm version (pnpm@B), and a pnpm-workspace.yaml existed at
the project root, the install-child spawned by `installPnpmToTools` to
fetch pnpm@B inherited a cwd under the pnpm home directory. pnpm's
workspace walk-up from there discovered the ancestor pnpm-workspace.yaml,
adopted the root package.json, and re-triggered switchCliVersion inside
the child. Because the target tool dir had not yet been symlinked in, the
recursive installPnpmToTools call saw alreadyExisted === false and kicked
off another nested install, recursing forever at 100% CPU.
Force the install-child's environment to disable its own version handling:
- `npm_config_manage_package_manager_versions=false` (v10 setting name)
- `pnpm_config_pm_on_fail=ignore` (v11+ setting name)
Also set the v11 setting on the final spawn at the end of switchCliVersion,
so when v10 hands off to a v11 target the child's check/download paths stay
disabled regardless of which env-var convention the child reads.
Closes#11337.
* test: add v11-switch and same-version regression tests for #11337
- v11 switch with a root pnpm-workspace.yaml: covers the primary #11337
reproducer (target major differs from running major). Before the fix this
fork-bombed via the install-child's workspace walk-up; now it reaches the
terminal spawn and `installPnpmToTools` completes.
- Same-version short-circuit: with a root pnpm-workspace.yaml and
`packageManager: pnpm@<current>`, `switchCliVersion` must return at the
`pm.version === packageManager.version` guard, and the tool dir must not
be created. Guards against a future regression where the ancestor
pnpm-workspace.yaml alone accidentally triggers an install.
* fix(installPnpmToTools): isolate the install-child from the caller's workspace
Pass `--ignore-workspace` to the child pnpm so it doesn't walk up from the
stage directory and adopt the caller's pnpm-workspace.yaml as its own root.
That walk-up was both (a) the mechanism that caused the #11337 fork-bomb
(the child would rediscover the caller's packageManager field and re-enter
switchCliVersion) and (b) a correctness problem in its own right: once the
child treats the caller's project as its workspace, `pnpm add` runs with
semantics that don't match an isolated tool-dir install. The env-var guards
from the previous commit stay in place as a defense-in-depth measure in
case any future code path surfaces a wantedPackageManager without going
through workspace discovery.
Also fold the new v11-switch regression into the existing v11 test rather
than adding a second v11 install, so CI doesn't fetch pnpm@11.0.0-rc.5
from the real npmjs registry twice. The tool-dir assertion in that test
now doubles as a fork-bomb regression check for the v11-target path.
* fix(installation): skip pnpm exe when no Node.js is on PATH
When pnpm is installed as @pnpm/exe (a Single Executable Application
that bundles Node.js into the pnpm binary) and the user has no separate
Node.js on PATH, `which('node')` fails and `getNodeExecPath` used to
fall back to `process.execPath` - which in @pnpm/exe is the pnpm binary
itself, not a Node binary. That path got baked into generated global
bin shims via nodeExecPath, so running any globally-installed CLI
invoked pnpm with the target script as its first positional arg,
producing `ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND` from the current
working directory.
Detect the @pnpm/exe case via `detectIfCurrentPkgIsExecutable` and
return undefined from the fallback so the shim emits a plain
`exec node <target>` instead.
Closes#11291
Refs #4645
* Update pkg-manager/plugin-commands-installation/src/nodeExecPath.ts
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
sveltejs/action-deploy-docs was deleted/privated, causing git clone to
prompt for credentials and fail in non-interactive CI. Matches the repo
already used on the v11 branch.
The previous overrides `minimatch@<3.1.4: '>=3.1.4'` and
`minimatch@>=9.0.0 <9.0.7: '>=9.0.7'` were unbounded on the upper end
and resolved to minimatch@10.x, which breaks consumers built against
v3's CJS export shape (e.g. @verdaccio/utils fails with
`Cannot read properties of undefined (reading 'makeRe')`).
* fix: defer npm-passthrough commands to main() when packageManager wants pnpm v11+
The argv[0] passthrough in pnpm.ts runs before main() loads config and calls
switchCliVersion, so users with packageManager=pnpm@11 on a v10 host hit npm
directly for commands like `version`, bypassing v11's native implementations.
Walk up from cwd to the nearest package.json; if its packageManager field
selects pnpm v11 or newer, skip the passthrough and let main() switch.
Fixes#11328.
* test: add e2e test for v11 deferral, and only read package.json on passthrough
Move the shouldSkipNpmPassthrough check inside the passthrough switch case
so non-passthrough commands (install, add, run, etc.) don't pay for the
cwd-to-/ walk when their own config loading will discover packageManager
anyway.
Add an e2e test that pairs packageManager=pnpm@11.0.0-rc.3 with
manage-package-manager-versions=false so the assertion verifies main()
took over (command falls through to the `run` fallback and fails with
'Command "version" not found') without actually downloading pnpm v11 —
that keeps the test fast and network-independent.
* fix: walk up past workspace leaf manifests when detecting wanted pnpm major
- Continue walking up when package.json lacks a string packageManager field,
so workspace leaves (which typically omit it) correctly pick up the root's
pnpm@11+ declaration.
- Only treat ENOENT/ENOTDIR as "keep walking" — other fs errors now surface
as null instead of silently consulting an ancestor manifest.
- Lazy-load readWantedPnpmMajor in pnpm.ts to keep cold start unaffected for
non-passthrough commands.
* fix: honor manage-package-manager-versions when deciding to skip npm passthrough
When a user pinned pnpm v11 in packageManager but disabled version switching
(via .npmrc or an explicit `npm_config_manage_package_manager_versions` env
var), pnpm v10's main() won't switch to the wanted pnpm — so bypassing the
legacy argv[0] npm passthrough would leave commands like `version` stranded
with "Command not found". Fall back to the passthrough in that case.
Also:
- Treat a non-string `packageManager` field as malformed (return null) rather
than conflating it with "missing" and walking up to an ancestor manifest.
- Extract the decision into a testable `shouldSkipNpmPassthrough(env, cwd)`
helper and unit-test the full matrix.
* test: add e2e coverage for the v11+ switching-enabled passthrough skip
Covers the primary #11328 fix scenario end-to-end: when packageManager pins
pnpm v11+ and switching is enabled, the argv[0] passthrough is skipped and
main() hands off to switchCliVersion, which installs pnpm v11 and runs its
native `version` command (not npm's). Also updates the stale comment on the
v10 test that referenced a now-different adjacent test.
The test uses the real npmjs registry for this one install; the registry
mock's proxy is slow and flaky for pnpm's full dep tree, and the
end-to-end assertion only needs a real v11 tarball to prove the handoff.
* test: assert pnpm v11's version header in the switch-e2e test
* test: use v11's ERR_PNPM_INVALID_VERSION_BUMP marker and assert on combined streams
The --help-based assertion worked locally but failed in CI with stdout="", which
obscured the cause. Switching to `pnpm version` (no args) triggers v11's native
ERR_PNPM_INVALID_VERSION_BUMP error — a marker that only pnpm v11 can produce —
and asserting on stdout+stderr combined makes any install/switch failure
visible in the diff instead of a silent "expected substring not found".
* test: assert tool-dir presence instead of v11 executing in CI
pnpm v11 requires Node.js >= 22.13 but the GH Actions workflow runs on 22.12,
so v11 errors out at its own Node-version check before reaching the `version`
command. The tool dir's presence is a lower-level but direct proof that
installPnpmToTools ran — which is reached only from main() → switchCliVersion,
so the argv[0] passthrough must have been skipped. Combined with asserting
the absence of npm's `Bump a package version` help line, the test covers
the #11328 fix without depending on v11 actually executing a command.
Allow skipping the lockfile settings validation during frozen and
preferFrozenLockfile installs. When enabled, pnpm proceeds as if the
lockfile settings are up to date.
Cherry-picked from main (6557dc09f9).
Adapted for v10: use pMemoize.clear() (p-memoize v4 API) instead of
pMemoizeClear, and fix test imports for v10 package names.
v11 lockfiles may contain two YAML documents separated by `---`. The
first document is the env lockfile metadata; the second is the actual
lockfile data. The reader now strips the first document before parsing.
When enabled, peer dependency suffixes use version-only identifiers
(name@version) instead of full dep paths, eliminating nested suffixes
like (foo@1.0.0(bar@2.0.0)). Transitive peers are still tracked but
identified by version instead of full dep path.
Backport of #11071 to v10.
Closes#11070
Global Virtual Store (#10939)
Content-verified skip in GVS mode, tolerate EPERM during
bin creation on Windows, handle EPERM in DLX cache symlink.
(cherry picked from commit 62f760ec3d)
* fix: restore ['.'] default for workspacePackagePatterns when packages field is missing
Commit 6eedf828b removed the ['.'] fallback for workspacePackagePatterns
when pnpm-workspace.yaml has no packages field. This caused findPackages
to default to ['.', '**'], discovering ALL directories with package.json
as workspace projects. This is the same regression that was previously
reverted in 595cd414f (close#10571), reintroduced by #10127.
Projects like cdxgen that use pnpm-workspace.yaml only for settings
(e.g. minimumReleaseAge) without a packages field were broken because
test data directories were picked up as workspace projects.
close#10909
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: remove unknown word from changeset
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* test(config): verify workspacePackagePatterns defaults to ['.'] without packages field
Adds a regression test to ensure pnpm-workspace.yaml without a packages
field defaults workspacePackagePatterns to ['.'] (root only), preventing
all directories from being discovered as workspace projects.
Allow approving all pending build dependencies at once without
interactive selection, useful for CI/CD pipelines and project
bootstrapping scenarios where interactive prompts are not feasible.
close#10136
Cherry-pick of 2b14c742e from main, adapted for v10:
- Use CJS module type for @pnpm/yaml.document-sync
- Use ramda/src/equals import style (v10 CJS)
- Remove GLOBAL_CONFIG_YAML_FILENAME (v11-only)
- Replace write-yaml-file with yaml + write-file-atomic + patchDocument
Co-Authored-By: Brandon Cheng <gluxon@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
v10 doesn't support pnpm_config_* env vars (added in v11 via #10029).
Use npm_config_frozen_lockfile instead, which is supported by the
npm-conf-based config loader in v10.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Git on Windows (Git for Windows / MSYS2) understands Unix-style
'/dev/null' but cannot access the native Windows null device '\\.\nul'
as a file path, causing "fatal: unable to access '\\.\nul'" errors.
This is a manual backport of the fix from #10757 on main.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Use self-contained jest.mock factory and retrieve mock from required
module to avoid hoisting issues with jest.mock in CJS/ts-jest.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Use Object.keys() instead of Map.keys() for Record<string, string> filenames
- Use tempy.directory() instead of temporaryDirectory() (v10 CJS style)
- Remove storeDir from ClientOptions (not in v10 API)
- Add missing WorkspaceState imports and mocks in test
- Fix lint: use commas in type literals, fix require import style
- Fix spellcheck in changeset
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix(dlx): print help message on calling pnpm dlx without arguments
Running `pnpm dlx` with no arguments would crash Node.js with a
TypeError as it attempted to call `.indexOf()` on an undefined variable.
This commit adds a guard clause and displays the help message instead
and exits gracefully.
Fixes#10633
* refactor: dlx
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
