chore(deps): update all-dependencies (major)

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Type	Update	Change	Pending	Age	Confidence
grafana/k6		major	1.6.1 → 2.2.0
pinact	tools	major	3.8.0 → 4.1.1
pnpm (source)	tools	major	10.32.1 → 11.22.0	11.23.0

---

Release Notes

suzuki-shunsuke/pinact (pinact)

v4.1.1

Compare Source

Dependency Updates

#​1634 Update Go to v1.26.5

#​1659 Update module github.com/suzuki-shunsuke/ghtkn-go-sdk to v0.5.0
#​1622 Update module github.com/urfave/cli/v3 to v3.10.1
#​1633 Update module github.com/google/go-github/v88 to v89

#​1646 Update dependency sigstore/cosign to v3.1.2
#​1653 Update dependency anchore/syft to v1.49.0
#​1657 Update dependency goreleaser/goreleaser to v2.17.1

v4.1.0

Compare Source

Features

#​1578 Update ghtkn-go-sdk to v0.3.0 for backend and disable device flow support

v4.0.0

Compare Source

⚠️ Breaking Changes

#​1540 Removed the -review option

Output SARIF and pass it to reviewdog. This has been announced previously.

pinact run -format sarif |
  reviewdog -f sarif -name pinact -reporter github-pr-review

#​1540 Always output diff

Even if you specify -diff=false, it is ignored.

#​1540 -diff and -check are now aliases for -fix=false

This simplifies the logic, making it easier to understand and less prone to bugs.

#​1540 -verify is now an alias for --verify-comment

-verify was unclear about what was being verified, so it has been renamed for clarity.
However, -verify is kept as-is to maintain backward compatibility.

#​1458 #​1558 Version comments are now required @​ManuelLerchnerQC

For SHAs without a version comment, pinact automatically adds a version comment (validation error if -fix=false).

$ pinact run test.yaml
test.yaml:1
- - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
+ - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

Specifying a version comment makes it easier to see which version is being used, and makes it easier for tools like Renovate and Dependabot to update.
It also has security implications.
For GitHub Actions versions, you can also specify the SHA of a commit in a fork.
This means it could point to a malicious commit in a fork.
If you specify only the SHA without a version comment, you cannot tell whether it is the SHA of a commit in a fork.
By requiring version comments, you can verify that the version comment matches the SHA using the --verify-comment option.
Even if a fake version comment is added to a fork's SHA, it can be detected by --verify-comment.
An attacker could also create a tag pointing to a fork's SHA, but creating a tag requires write permission, which raises the bar for attacks, so this can be said to improve security.
Of course, this is only meaningful if you verify with --verify-comment, so it is recommended to run pinact with --verify-comment in CI.

Features

#​1540 -no-api: support for offline validation
#​1540 You can now check whether the version being used satisfies min age, not just newer versions
#​1540 More flexible min age support via rules
#​1540 #​1542 #​1543 Support for a global configuration file
#​1435 Automatic correction of version comments via -verify-comment @​ManuelLerchnerQC
#​1547 #​1552 #​1557 #​1562 -diff-file: limit pinact's targets to only the changed lines

-no-api: support for offline validation

If you just want to check whether something is pinned, you don't really need to use the GitHub API, but previously the GitHub API was called.
With the -no-api option, you can validate without calling the GitHub API.
However, since API calls are currently essential for fixing code (this may change in the future if caching is supported), you need to specify either -fix=false or -format sarif.
Implicitly treating it as -fix=false could cause behavior to change and become a breaking change when caching is supported, so it must currently be specified explicitly.

You can now check whether the version being used satisfies min age, not just newer versions

For example, you can run it in CI against modified lines to check whether any dangerous versions that do not satisfy min age are being used.
This is not checked by default, but is checked when you run pinact run --verify-min-age or pinact run -min-age <min age>.

More flexible min age support via rules

min age can now be configured in the configuration file.
Additionally, by using rules, you can apply settings such as min age to specific actions.

min_age:
  value: 7 # default setting
rules:
  # Allow latest for suzuki-shunsuke's actions
  - ignore: true
    conditions:
      - expr: |
          ActionRepoOwner == "suzuki-shunsuke" && ActionVersion == "latest"
  # Set min age to 0 for actions/checkout
  - min_age: 0
    conditions:
      - expr: |
          ActionRepoFullName == "actions/checkout"

For rules, conditions are evaluated per rule, and the settings are applied if matched.
You can write multiple conditions, and the settings are applied if any one of the conditions matches.
expr follows https://expr-lang.org/docs/language-definition. Please read the documentation for details.
The settings of rules listed later in rules take precedence.

Support for a global configuration file

[!WARNING]
If you have set the PINACT_MIN_AGE environment variable in ~/.bashrc, ~/.zshrc, etc., it is recommended to remove it and use a global configuration file instead.
PINACT_MIN_AGE takes precedence over the configuration file, so it overrides the project's settings.
On the other hand, global settings are merged with lower priority than the project's settings.
If you want to enforce the setting, PINACT_MIN_AGE is suitable, but for default settings, a global configuration file is more appropriate.
Note also that environment variables do not allow flexible settings like rules.

A global configuration file is now supported.
The file path is searched in the following order of priority:

1. $PINACT_GLOBAL_CONFIG
2. ${XDG_CONFIG_HOME}/pinact/pinact.yaml
3. ${HOME}/.config/pinact/pinact.yaml

On Windows:

1. $PINACT_GLOBAL_CONFIG
2. %APPDATA%\pinact\pinact.yaml

rules are prepended before the rules in the project configuration file.
So project settings take precedence over global settings.

Automatic correction of version comments via -verify-comment

If the SHA and the version comment do not match, the version comment is automatically corrected to match the SHA.
Previously, it would just return an error, but now it is automatically corrected.

-diff-file: limit pinact's targets to only the changed lines

If you specify a file in Unified Diff Format via -diff-file, you can limit pinact's targets to only the changed lines.
By passing the PR's diff file in PR CI, you can reduce unnecessary API calls and prevent corrections or errors from code unrelated to the PR's changes.
This makes it easier to introduce pinact via Required Workflow across an entire GitHub Organization of a large development organization.
To improve the overall health of a development organization, it is desirable to introduce pinact via Required Workflow.
However, if you suddenly introduce pinact as a Required Workflow in an Organization that has a lot of originally unpinned code, errors and corrections unrelated to the PR's changes will occur everywhere, causing confusion.
When errors occur in places unrelated to the PR's changes, the PR author thinks "what is this error?", "wait, do I have to fix this? It's unrelated to this PR so I want to split the PR, but creating a PR is a hassle."
It is also possible that the same error occurs in multiple PRs, and each one independently performs redundant fixing work.
Inquiries about errors come in from various teams, generating unnecessary costs.
If you try to fix everything before introducing the Required Workflow, it takes time to introduce, and during that time the bad situation continues where new unpinned code keeps increasing.

On the other hand, if you can fix and validate only the lines changed in a PR, the PR author can more easily accept making the fix, and there is no need to split the PR.
However, this alone does not pin existing code, so in parallel with this, you still need to run pinact against each repository and create PRs.

How do you generate the file specified by -diff-file? You can easily generate it using the action https://github.com/suzuki-shunsuke/pr-unified-diff-action.

- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
  with:
    persist-credentials: false
- uses: suzuki-shunsuke/pr-unified-diff-action@c932c1df5f577028d8ca05d2d3c0c059072d8821 # v0.0.1
  id: diff
- uses: suzuki-shunsuke/pinact-action@896d595f299e71d65b9d28349d6956abe144390a # v3.0.0
  with:
    diff_file: ${{ steps.diff.outputs.diff_path }}

v3.10.1

Compare Source

🐛 Bug Fixes

#​1535 pin uses lines with multiple spaces after the YAML list dash

v3.10.0

Compare Source

Features

#​1530 Support pinning branches to latest stable tags by the --branch-to-tag option

The default behabiour isn't changed.
By default, pinact doesn't pin branches such as main or master.
If you want to pin specific branches, you can use the --branch-to-tag option.

e.g.

pinact run --branch-to-tag '^main$' --branch-to-tag '^release/.*$'

v3.9.2

Compare Source

Fixes

#​1493 Preserve original line endings when updating workflows

v3.9.1

Compare Source

v3.9.0

Compare Source

Features

#​1365 Make version separator configurable via configuration file @​ReenigneArcher
#​1372 Make version separator configurable via command line option and environment variable

🐛 Bug Fixes

#​1359 Fix a bug that -log-color doesn't work

Others

• docs: fix readme for ignore_actions[].ref by @​nasa9084 in #​1323
• docs: fix readme for correct GHES_API_URL by @​maruloop in #​1324
• docs(INSTALL): add mise alternate installation documentation by @​jylenhof in #​1331

pnpm/pnpm (pnpm)

v11.22.0

Compare Source

v11.21.0: pnpm 11.21

Compare Source

Minor Changes

• Added interactive group selection to pnpm update --global --interactive.

• Running pnpm setup, pnpm self-update, or a command that modifies the global installation (such as pnpm add --global) through sudo now prints a warning. pnpm keeps global packages and configuration in the invoking user's home directory, so running these commands as root silently operates on the root user's home directory instead of yours. They will fail with ERR_PNPM_SUDO_NOT_SUPPORTED in pnpm v12. Read-only global commands (such as pnpm bin --global) are unaffected.

Patch Changes

• Fixed pnpm failing to start under asynchronous Node.js module loaders when no .pnpmfile.mjs exists pnpm/pnpm#11701.

• Fixed minimumReleaseAge fallback for custom dist-tags so the selected version does not exceed the registry’s original tag target.

• Removing a dependency from package.json and reinstalling no longer re-resolves the dependency graph. The importer's entry is dropped from pnpm-lock.yaml, anything it made unreachable is pruned, and a catalog entry that loses its last referent is removed — all without registry access. Installs still fall back to a full resolution when a package that stays resolves a peer dependency through the removed one, since that would change the surviving package's entry rather than only prune.

• Changing a catalog entry to a different exact version no longer re-resolves the dependency graph. The package is replaced in pnpm-lock.yaml directly, reusing the same check the pnpm.overrides fast path applies: every locked dependency of the package must still satisfy the new version's manifest. Installs fall back to a full resolution when anything other than the catalog reaches the package — an importer that depends on it directly, or another package that depends on it — since the graph would then need both versions.

• Fixed a CI regression where github:owner/repo dependencies (and other shorthand Git specifiers) would fail to install with Permission denied (publickey) on CI runners that lack SSH keys. The Git resolver no longer records an SSH URL unless the user explicitly wrote one (e.g. git+ssh:// or git@host:...):

  • The repository visibility probe (an HTTP HEAD request) now retries transient failures such as 429 Too Many Requests, so host throttling of CI runners is no longer mistaken for a private repository.
  • For non-SSH specifiers, anonymous HTTPS git ls-remote access is now tried before SSH, so a public repository whose visibility probe fails still resolves to a portable HTTPS URL instead of an SSH URL that only works where SSH keys are configured.
  • When every probe fails, the resolver falls back to HTTPS for shorthand and HTTPS-style specifiers, and only guesses SSH when the user explicitly provided an SSH URL.
  • A repository that could not be confirmed public is no longer resolved to the host's anonymous archive URL (e.g. codeload.github.com, which would fail to download for a private repository); it stays a regular git resolution so installs can use ambient Git credentials such as credential helpers and tokens.

  Note that a private repository that is reachable both over authenticated HTTPS and over SSH now resolves to its HTTPS URL, where previous versions recorded the SSH URL.

  Fixes pnpm/pnpm#13276.

• ng build and nuxt build now work under the global virtual store: pnpm's built-in compatibility extensions add the tslib dependency that @angular/build uses without declaring and the unplugin dependency that @nuxt/vite-builder v4 uses without declaring.

• Fixed link: dependencies under enableGlobalVirtualStore so linked children are materialized and slots remain isolated by their resolved link targets.

• An install that skips resolution because pnpm-lock.yaml is already up to date now reacts fully to packages the lockfile removed — for example after pulling a lockfile in which a dependency was deleted. The hoist layer is recomputed, so a package that became hoistable when a direct dependency was removed is hoisted, and pendingBuilds entries for removed packages are dropped instead of staying pending forever.

• The held-back-update warning printed by pnpm update no longer fires when minimumReleaseAge is the actual reason a newer version was not picked. The warning's baseline now applies the same maturity cutoff as the pick itself, so it no longer wrongly attributes the hold-back to "your manifests and already installed dependencies" or recommends an override that would defeat the age gate. See #​13071.

• Checking whether ignoredOptionalDependencies is up to date no longer reorders the configured patterns. The check sorted them in place, which could move an ! exclusion ahead of the pattern it excludes from and flip which optional dependencies were ignored.

• Changing autoInstallPeers, dedupePeers, peersSuffixMaxLength, excludeLinksFromLockfile, or injectWorkspacePackages no longer re-resolves the dependency graph when the lockfile proves the setting cannot affect it: no package or project declares a peer dependency for the peer settings, and no project depends on a directory or on another workspace project for the link and injection settings. The new setting is recorded in pnpm-lock.yaml and the install proceeds from the existing resolution. Every other case still falls back to a full resolution.

• Adding, editing, or removing an entry in patchedDependencies no longer re-resolves the dependency graph. Resolution never reads a patch — it only records the patch file's hash against the package it matches — so the install now rewrites the affected entries in pnpm-lock.yaml and materializes the patched package from the store instead. Installs still fall back to a full resolution when the patched package is reachable as a peer dependency, and when the new configuration would leave a patch unused while allowUnusedPatches is off, so ERR_PNPM_UNUSED_PATCH is still reported.

• Resolving a private git repository no longer blocks on an interactive credential prompt: git ls-remote now fails fast with an authentication error when git has no credentials for the repository #​13522.

• Lockfile verification now honors offline mode by using cached registry metadata instead of reaching the registry. When the required metadata is not available locally, verification reports the same ERR_PNPM_NO_OFFLINE_META condition used by offline resolution.

• POSIX shell shims now follow symbolic links before computing basedir, preventing execution failures when a shim is invoked via an external symlink on PATH #​13405.

• The automatic packageManager version switch works again on registries whose tarball URLs point at a different host than the registry itself (load-balanced feed proxies, Artifactory-style mirrors). Package-manager entries are now always recorded with integrity-only resolutions — the download URL is derived from the trusted bootstrap registry instead — and entries persisted in an invalid shape by an earlier pnpm are discarded and re-resolved instead of failing every command #​13619.

• Registries that serve no npm signature metadata (private mirrors and feed proxies commonly strip dist.signatures) no longer break the automatic packageManager version switch and pnpm self-update #​13147. When the configured registry cannot provide a verifiable signature, pnpm now fetches the signature from registry.npmjs.org and verifies it against the same embedded npm keys over the installed integrity — which proves exactly the same thing. If no signature can be obtained from either source (for example, both are unreachable, or the registry publishes only a shasum), pnpm proceeds with a warning instead of failing, but only when the packages resolve through a registry configured in the user's own (non-project) configuration; the download stays pinned by the lockfile integrity, and a signature that exists but does not validate still fails the switch.

• pnpm fetch, and any install run with virtualStoreOnly, no longer writes a .pnp.cjs loader under nodeLinker: pnp. These installs populate the virtual store without linking the project, so the loader would have claimed the project resolves out of a store it was never linked into. The importer links and node_modules/.package-map.json were already skipped; the PnP loader now follows the same rule.

• Prevent pnpm from removing project files when modulesDir resolves to the project root.

• Speed up installs after adding ignoredOptionalDependencies patterns by removing newly ignored optional dependencies and pruning packages that are no longer reachable without resolving the dependency graph again.

• When a failed install re-copies a bin script from the store, rerunning pnpm install now reapplies the executable bit to the bin instead of leaving it non-executable #​12742.

• pnpm root -g and pnpm bin -g now print warnings to stderr instead of stdout, so their stdout stays a clean, machine-readable path. Previously, running either command with --global in a project that pins a package manager (e.g. via the packageManager field) printed a warning like [WARN] Using --global skips the package manager check for this project ahead of the path, breaking programs that capture the output as a path #​13672.

  In pnpm 12, pnpm root -g and pnpm prefix -g are now supported (they previously failed with ERR_PNPM_CLI_ROOT_GLOBAL_UNSUPPORTED / ERR_PNPM_CLI_PREFIX_GLOBAL_UNSUPPORTED), and the reporter output of dlx, create, config, sbom, with, store, prefix, root, and bin goes to stderr, matching pnpm 11.

• pnpm setup no longer makes Node.js print a MODULE_TYPELESS_PACKAGE_JSON warning about dist/worker.js on every command. The package.json it writes next to a standalone executable now declares "type": "module".

• pnpm update without saving no longer records a version that the manifest's range excludes. The kept range stays authoritative: a requested version outside it is skipped with a warning, and a requested range, a dist tag, or --latest resolves within it instead of past it. Previously each of these could write a lockfile entry that contradicted its own specifier, which the next pnpm install --frozen-lockfile rejected with ERR_PNPM_OUTDATED_LOCKFILE #​12764.

• pnpm version -r --json now outputs [] instead of human-readable text when no pending changes exist pnpm/pnpm#13217.

Platinum Sponsors

Gold Sponsors

v11.20.0: pnpm 11.20

Compare Source

Minor Changes

• Security fix. Affects projects using namedRegistries on pnpm 11.1.0–11.19.x. It is semi-breaking for those projects — see "If you use named registries" below.

  The lockfile recorded no marker for which registry a package came from. Packages were keyed by name@version alone, and entry lookup went through refToRelative(ref, name), so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single packages: entry and whichever resolved first decided the tarball every consumer got.

  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.

  Packages resolved from a named registry are now recorded under registry-qualified keys (<name>@<registryName>:<version>, e.g. foo@work:1.0.0), so each registry gets its own entry and the lockfile pins which one a dependency came from.

  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use namedRegistries sees no difference, and older pnpm versions keep reading the file.

If you use named registries

Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.

Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.

There is no setting to keep the old behavior: the old shape is the vulnerability.

Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the namedRegistries setting on demand.

To use named registries, map your aliases in pnpm-workspace.yaml:

namedRegistries:
  work: https://npm.enterprise.example.com/

New built-in npmjs: alias

npmjs: now resolves to https://registry.npmjs.org/ with no configuration, alongside the existing gh: alias for GitHub Packages. It pins a dependency to the public registry even when registry points elsewhere, such as an internal proxy:

{ "dependencies": { "left-pad": "npmjs:^1.3.0" } }

npm: cannot do this — it is the alias protocol (npm:<name>@<range>) and resolves through whatever registry points at.

If you mirror or proxy npmjs, point the alias at your mirror:

namedRegistries:
  npmjs: https://npm.internal.example.com/

Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on registry.npmjs.org is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, minimumReleaseAge, or trustPolicy check runs. Overriding the alias is the same escape hatch GHES users already have for gh.

Every alias the lockfile references must stay in namedRegistries: reading an entry whose alias is gone fails with ERR_PNPM_MISSING_NAMED_REGISTRY rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.

Named registry aliases that shadow a reserved dependency specifier prefix (file, link, workspace, runtime, npm, jsr, ...) are now rejected with ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME instead of being silently shadowed by the corresponding resolver.

pnpm licenses and pnpm sbom now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl repository_url qualifier.

Patch Changes

• An empty http-proxy, https-proxy, proxy, or no-proxy value — from the .npmrc, pnpm-workspace.yaml, the CLI, or the HTTP_PROXY / HTTPS_PROXY / PROXY / NO_PROXY environment variables — no longer fails the install with ERR_PNPM_INVALID_PROXY. Empty settings read as unset, so a shell exporting HTTP_PROXY= disables the proxy, and an empty proxy= in the .npmrc no longer suppresses HTTPS_PROXY #​13533.

  proxy=false in the .npmrc or proxy: false in pnpm-workspace.yaml now turns proxying off instead of being read as a proxy host named false. false and null on https-proxy / http-proxy / no-proxy read as unset, and on the command line they are ordinary host names, since a flag carries its value verbatim.

• The env lockfile no longer pins @pnpm/exe alongside pnpm when the wanted pnpm version is 12 or newer. From v12 the unscoped pnpm package is itself the native executable, so @pnpm/exe is not published for it and resolving it would fail. The engine identity check now verifies the native binary through whichever package ships it.

• lexCompare and nerfDart are now published as @pnpm/text.ordinal-comparator and @pnpm/config.registry-auth-key. Use these instead of @pnpm/util.lex-comparator and @pnpm/config.nerf-dart.

• Fixed the order in which pnpm matches a lockfile's recorded tarball URL against known registry URLs. Two registry URLs of equal length were previously ordered arbitrarily, so which one a tarball URL matched could differ between runs.

• Dependency resolution is faster: package metadata is now filtered once per packument instead of once per dependency edge when minimumReleaseAge is active, and parsed semver versions and ranges are reused instead of re-parsed on every comparison.

• Security: pnpm rebuild now refuses a lockfile whose packages key carries a path traversal in the package name (e.g. ../../../escaped@1.0.0), instead of running that package's lifecycle scripts and linking its bins in a directory outside the virtual store. Such a name is rejected with ERR_PNPM_INVALID_DEPENDENCY_NAME.

Platinum Sponsors

Gold Sponsors

v11.19.0: pnpm 11.19

Compare Source

Minor Changes

• pnpm login no longer requires an interactive terminal when the registry supports web-based login: without a TTY it prints the authentication URL (skipping the QR code and the "Press ENTER to open the URL in your browser" prompt) and polls the registry until the browser approval completes. Only the classic username/password login still fails with ERR_PNPM_LOGIN_NON_INTERACTIVE in a non-interactive terminal.

• The save-prefix setting now accepts =: newly added dependencies are saved with an explicit = operator (=1.2.3) instead of the setting being silently treated as the default ^.

Patch Changes

• allowBuilds entries can now approve git-hosted packages that pnpm downloads as a tarball, such as github: dependencies (which are fetched from codeload.github.com rather than cloned), by their repository URL without the resolved commit hash. This matches the hashless git+ matching already supported for cloned git dependencies. For example:

  allowBuilds:
    "foo@git+https://github.com/org/foo.git": true

  This approves the package whether pnpm clones it or downloads a tarball, so the entry no longer has to be updated every time the pinned commit changes. GitLab and Bitbucket tarball downloads are matched the same way. Approving or denying a specific resolved commit by its full tarball dep path continues to work.

• pnpm outdated --include-github-actions no longer blocks on an interactive git credential prompt when a workflow uses a private action repo.

• Prevented minimumReleaseAge from replacing latest with a SemVer-greater version than the registry tag target #​13034.

• Fixed empty bundledDependencies and bundleDependencies arrays causing nondeterministic lockfile changes. See #​13123.

• The install summary no longer prints (X is available) when the registry's dist-tags.latest is still held back by the active minimumReleaseAge policy. The hint only ever names the actual latest tag, so an immature latest suppresses the hint instead of advertising the version pnpm just refused to install #​11698.

• pnpm update keeps the explicit = operator of an exact version pin: a dependency saved as =3.5.1 now updates to =3.5.2 instead of the bare 3.5.2. See #​13168.

• Preserve a workspace dependency's link: entry when a run does not target it — e.g. pnpm update <other-pkg> (with or without --recursive), or a plain install after a root/catalog dependency change — with injectWorkspacePackages, instead of spuriously rewriting it to a peer-suffixed file: protocol. See #​10433.

• Workspace dependencies declared with a relative path (e.g. "foo": "workspace:../foo") are no longer silently dropped from the workspace projects graph, so --filter selection and the topological order of recursive commands take them into account.

Platinum Sponsors

Gold Sponsors

v11.18.0: pnpm 11.18

Compare Source

Minor Changes

• Fixed an installed optional dependency being left without one of its own required dependencies. When a package reached through optionalDependencies is installable on the current system but one of its regular dependencies is not, a lockfile-based install skipped that dependency and installed the parent anyway, so importing the parent failed with MODULE_NOT_FOUND. The dependency is now installed, and an install-check warning reports the incompatibility. A dependency is still only skipped when every path to it is optional, or when the package that pulls it in was itself skipped #​13286.

• pnpm setup now appends PNPM_HOME and the global bin directory to the GitHub Actions environment files (GITHUB_ENV and GITHUB_PATH), so later steps in the same job can run pnpm add --global and other global commands #​9191.

• Added support for publishConfig.name, which publishes a package under a different name than the one its manifest carries in the workspace. It is for a project whose published name is already taken by a sibling project, which otherwise has to be renamed by a build step just before publishing. Only the published artifact is renamed — dependents, pnpm-lock.yaml, and release tooling keep addressing the project by its manifest name — and the new name reaches the packed manifest, the tarball filename, and everything that addresses the package at the registry: the already-published check of pnpm publish -r, its registry selection, and the release-planning probes of pnpm change status and pnpm version -r #​13345.

• pnpm self-update no longer takes any instruction from the project it is run in:

  • pnpm is fetched through the same trusted registry and auth configuration used when switching pnpm versions, so a project .npmrc or pnpm-workspace.yaml can no longer redirect the download or attach credentials to it, and the project's default .pnpmfile.(c|m)js is no longer loaded. Pnpmfiles from trusted sources (the pnpmfile setting, the global pnpmfile, config dependencies) still apply.
  • The minimumReleaseAge settings in pnpm-workspace.yaml no longer affect self-update. They still govern the project's own dependencies; for self-update the cooldown now comes from the built-in default, your global config, a PNPM_CONFIG_* environment variable, or a command-line flag. This fixes self-update failing inside a workspace that raises the cutoff while succeeding everywhere else, and stops a repository from either waiving the cooldown or keeping you on an outdated pnpm by raising it.
  • The same applies to the trustPolicy settings and to ci: a project can no longer weaken the trust check that guards the pnpm download, nor re-enable the confirmation prompt that a CI run suppresses.

  When self-update refuses a version that is younger than the cutoff, an interactive run now offers to update anyway; non-interactive runs still fail. CI never prompts, even on a runner that attaches a TTY.

Patch Changes

• Fixed pnpm licenses list to report every version when the same package is installed under multiple aliases pnpm/pnpm#13438.

• Sort pnpm dedupe --check snapshot changes for stable output across pnpm implementations.

• Strip Unicode formatting characters from registry- and manifest-derived terminal output.

• Speed up installs after compatible catalog or direct dependency range changes by retaining the locked version without resolving the dependency graph again.

• Speed up installs after safe override changes by reusing unambiguous compatible dependency resolutions, pruning obsolete dependencies, applying independent replacements and removals together, and handling parent-scoped "-" overrides without full lockfile resolution.

• Installing a local file: directory dependency with the global virtual store enabled no longer fails with TypeError: Cannot read properties of undefined (reading 'split') #​13335.

  Local directory dependencies — file: directories and injected workspace packages — now get a global-virtual-store slot of their own per project. They used to share one slot across every project that depended on a directory of the same name, so a project could end up linked to another project's copy of the dependency.

• The `

✂ Note

PR body was truncated to here.

---

Configuration

📅 Schedule: (in timezone Asia/Tokyo)

• Branch creation
  • "on monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.