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 → 5.0.0
pnpm (source)	tools	major	10.32.1 → 12.4.2	12.5.1 (+1)

---

Release Notes

suzuki-shunsuke/pinact (pinact)

v5.0.0

Compare Source

Upgrade Guide

🤖 pinact is now AI friendly

v5 is about coding agents. An agent that is asked about pinact, or that hits a pinact error in CI, has until now had to answer from its training data, from the source code, or from whichever version of the website it happened to land on. v5 gives it three things so that it answers from the pinact that is actually installed:

#​1708 An Agent Skill
#​1708 pinact docs: the documentation, embedded in the binary
#​1705 pinact json-schema: the JSON Schema of the configuration file, embedded in the binary

An Agent Skill

gh skill install suzuki-shunsuke/pinact pinact

The skill carries no documentation of its own, deliberately. It is installed separately from the binary, so anything copied into it would go stale, and an agent would confidently describe a flag or an error code of a version that isn't the one on the machine. Instead the skill tells the agent to run pinact docs list and pinact docs show <name> before answering, so the answer always comes from the installed pinact and the skill and the binary can never disagree about a version.

It adds only the few things an agent gets wrong unless it is told: that pinact run edits files and --check is the way to look without touching them, that --update changes which version a workflow uses, and that the exit codes 1 and 2 are findings rather than pinact failing.

pinact docs

$ pinact docs list          # the name and the description of every document, as JSON
$ pinact docs show config   # one document
$ pinact docs show codes/005

The documents are embedded in the binary, so there is nothing to fetch. An agent doesn't need network access to read them, doesn't have to guess which branch or tag of the repository to read, and cannot land on the documentation of a version other than the one it is being asked about. docs list reports a description of every document, written to name the symptoms a reader arrives with, so an agent can pick the one document it needs instead of reading them all.

The README is split into documents so that the binary ships them: --update, --min-age, --no-api, SARIF, --diff-file, and the access token used to exist only in the README, which the binary doesn't ship, and they are exactly the things an agent asks about. pinact docs list now lists 21 documents instead of 12, and the README goes from 431 lines to 169, keeping what someone reads to decide whether to use pinact.

The command is only useful to an agent that knows it exists, and an agent arrives at pinact through one of three places, so all three say so. pinact --help says it in the root command's description, every error pinact reports carries the hint as the help attribute, and pinact -v logs it:

$ pinact -v
pinact version v5.0.0
INF If you are a coding agent, run `pinact docs list` to list the documentation and `pinact docs show <name>` to read it before answering questions about pinact or troubleshooting its errors.

Checking the version is often the only pinact command an agent runs before it starts answering, so without this it never learns that the documentation is there. The hint goes to stderr as a log rather than to stdout, so it doesn't break a script that parses the version, and it is logged at the info level, so --log-level warn silences it. The routine outcomes of pinact run are unaffected: the exit codes 1, 2, and 3 are unchanged, and nothing is logged for them.

pinact json-schema

$ pinact json-schema > pinact.json

The schema is embedded in the binary too, so it is the schema of the configuration that the running version accepts. An agent writing or reviewing a .pinact.yaml can read the exact set of fields, their types, and which ones are required, rather than inferring them from an example it has seen. The copy served from GitHub, which the existing yaml-language-server comments point at, describes whatever main or the pinned tag holds instead.

#​1707 makes that schema worth reading: every field is now described, including version, files[].pattern, ignore_actions[].name, and ignore_actions[].ref, which had no description at all.

Editors such as VSCode use the same schema to complete the configuration file and to warn about invalid settings.

⚠️ Breaking Changes

#​1704 The CLI is built with spf13/cobra instead of urfave/cli

The commands, the flags, and their behavior are unchanged, but a long flag must now be written with two dashes.

# v4
pinact run -check
pinact run -fix=false -no-api
pinact run -diff-file diff.txt

# v5
pinact run --check
pinact run --fix=false --no-api
pinact run --diff-file diff.txt

urfave/cli accepted a long flag with a single dash. cobra's flag parser does not: a single dash introduces short flags, and -c is the short flag of --config, so -check would otherwise be read as --config=heck and pinact would silently look for a configuration file named heck. To prevent that, pinact rejects a single-dash long flag with an error naming the form to use:

$ pinact run -check
unknown flag: -check. Long flags need two dashes since pinact v5: --check

Short flags are unchanged and can still be written with a single dash:

pinact run -u -m 7
pinact run -i "^actions/.*$" -e "^actions/checkout$"
pinact init -g
pinact -c pinact.yaml run

--verify and --sep also keep working, as aliases of --verify-comment and --separator.

The migration fixes two urfave/cli bugs that pinact ran into:

• A workflow file named help could not be passed to pinact run: the argument was taken as a request for the help of run.
• Pressing TAB after a -- ran the command instead of completing it (urfave/cli#1993). Since pinact run fixes files by default, a TAB pressed while typing a pinact run -- command line rewrote the workflow files then and there. cobra completes through a separate hidden command that never reaches the action.

cobra also brings its own completion command, so pinact completion bash|zsh|fish|powershell generates a completion script.

#​1704 The Go module path is now github.com/suzuki-shunsuke/pinact/v5

go install github.com/suzuki-shunsuke/pinact/v5/cmd/pinact@latest

This affects anyone importing pinact as a library, and go install. Installing the CLI from a release asset or via aqua is unaffected.

#​1708 Documents under docs/ are renamed with underscores

docs/why-pinact-not-pin.md becomes docs/why_pinact_not_pin.md, so a link to the old path from outside this repository breaks. The README is also split into documents, so links to the section anchors that moved, such as #update-actions--update, now land on the README rather than on the section.

Fixes

#​1707 Describe every configuration field in the JSON Schema, and correct required

min_age was required by the schema, so every configuration file without it was reported as invalid. That is fixed, and version, ignore_actions[].ref, and rules[].conditions, which pinact does require, are now marked required. The description of files is also no longer truncated at a comma.

Dependency Updates

#​1689 #​1711 Update Go to v1.27.1

#​1681 Update module github.com/suzuki-shunsuke/ghtkn-go-sdk to v0.6.1
#​1713 Update module github.com/google/go-github/v90 to v91
#​1715 Update module golang.org/x/oauth2 to v0.37.0

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)

v12.4.2

Compare Source

v12.4.1: pnpm 12.4.1

Compare Source

pnpm 12.4.1 fixes installs that failed on filesystems refusing hard links or clones, on Android, and under nodeLinker: hoisted. Repeat installs are faster.

Patch Changes

Installing packages

• pnpm install no longer fails with Operation not permitted when the filesystem refuses a hard link or a copy-on-write clone #​14722. Under packageImportMethod: auto and clone-or-copy, pnpm copies the file instead. EdenFS checkouts, which have no hard links, and rootless containers, which refuse the clone syscall, both hit this. An explicit packageImportMethod: hardlink or clone still reports the error.

  pnpm also copies a package file whose store entry has reached the filesystem's limit on names for one file, 1024 on NTFS and 65000 on ext4. Such a file failed the install under packageImportMethod: hardlink, and under auto it stopped pnpm hard linking for the rest of the install.

• pnpm install no longer writes a package file through a symlink left at the path it is importing to. Copying such a file overwrote whatever the link pointed at, and created that file when the link pointed nowhere. An executable package file also made the link's target executable.

• Fixed pnpm install and pnpm dlx on Android. Registry requests crashed because pnpm found no system CA certificates, so pnpm uses bundled ones there #​14777. Imports also failed with "Permission denied" on filesystems that deny hard links and reflinks, and now fall back to copying #​14780.

• pnpm install no longer fails with "Invalid cross-device link" while preserving a package's nested node_modules directory during a Docker build #​14758.

• pnpm install no longer fails on a package tarball that carries a file at the archive root, such as the ._* entries macOS tar adds #​14701. The file is installed at the root of the package.

  A file: tarball packed without the usual package/ directory is now recorded under the name and version from its own package.json. It was recorded under the alias the dependency was given, at version 0.0.0.

• Under nodeLinker: hoisted, pnpm install no longer re-imports packages that are already in place. A repeat install replaced the whole node_modules tree and reported Packages: +N. A package is still imported when its directory is missing, when its package.json no longer carries the installed version, when it is a file: dependency, and when it is patched. Lifecycle scripts no longer run again for a package left in place, and pnpm rebuild and a change to allowBuilds still reach it.

• pnpm install now runs a dependency's build scripts again when its side-effects cache entry has no files to restore #​14717. Such builds were skipped and nothing was put in their place, so a script whose whole effect lands outside its own package directory, such as a git hook installer, never took effect. pnpm no longer publishes empty artifacts to the shared side-effects cache either.

Resolving and linking dependencies

• pnpm install, pnpm add, and pnpm dedupe now apply ignoredOptionalDependencies #​14729. Matching optional dependencies are left out of the lockfile and are not installed. pnpm 12 installed them whenever it resolved dependencies from scratch.

• pnpm install no longer links a transitive dependency to a workspace package when linkWorkspacePackages is true and the dependency is declared with a plain version range #​14781. Enabling preferWorkspacePackages does not change this. Set linkWorkspacePackages: deep to link them.

• pnpm install no longer leaves dangling dependency links in workspace packages located above the workspace root #​14726.

• pnpm install and pnpm add no longer leave a dangling symlink in node_modules when a project starts depending directly on a package that the lockfile holds only as a transitive dependency with resolved peer dependencies #​14714.

• pnpm dedupe now keeps a compatible auto-installed peer when another workspace project depends on a newer major #​14697. Repeated runs alternated between compatible and incompatible peer versions.

• pnpm peers check no longer reports a peer dependency declared as workspace:^, workspace:~, or a bare workspace: as unmet #​14770. pnpm reported these as unmet whatever version the linked workspace project supplied.

Performance

• Sped up repeat installs #​14540. pnpm checks the store's files only for the packages it links into node_modules, instead of every package in the lockfile. Creating the command shims in node_modules/.bin makes about 1,500 fewer filesystem calls in a 76 project workspace. Installs that use the global virtual store read their slot paths from the cache directory instead of deriving them every time. Verifying a large lockfile also allocates less memory.

• Sped up pnpm install in Cargo workspaces with many member crates. Repeated installs reuse verified Cargo checksum metadata.

• Installing several packages from the same Git repository and commit now downloads the source once per install #​14725. Each package still runs its prepare scripts in its own copy of the checkout.

Running scripts and tasks

• pnpm now passes Ctrl+C on to the script or command it started and waits for it to shut down #​14723. pnpm exited first, so a script that was still writing landed on the shell prompt.

• pnpm run "/pattern/" --no-bail now lets every matched script finish after one of them fails #​14718. The command exits with ERR_PNPM_RUN_FAILED, and its message lists the scripts that failed in the order they were selected.

• pnpm pipeline no longer fails on a project that tracks a symlink, such as a CLAUDE.md pointing at AGENTS.md #​14692. Changing a symlinked input's target invalidates that task's cache, and pnpm pipeline --no-cache no longer hashes task inputs.

Commands

• pnpm add -g, pnpm update -g, and pnpm remove -g no longer change global bins or install directories after reading only part of an installed package group #​13796. If any declared package manifest is missing, malformed, or unreadable, pnpm now fails before it activates or removes anything and leaves the existing global installation intact.

• pnpm dedupe now processes every workspace project by default, including workspaces that keep a separate lockfile per project #​14732. Workspace filters select which projects it processes, and --fail-if-no-match exits with an error when no project matches.

• pnpm update <name>@<version> now keeps the range operator the manifest declares #​14745. Running pnpm update react@19.3.0 on "react": "^19.2.8" writes "react": "^19.3.0". A jsr: entry keeps its jsr: prefix, and a plain pnpm update now moves a jsr: range the way it moves an npm range.

• pnpm --filter directory selectors now support ? wildcards and character classes such as [ab]. A * or ? wildcard no longer selects a directory whose name starts with a dot, as on pnpm 11.

• pnpm deploy --legacy now prefers the dependency versions pinned in the source workspace lockfile when they still satisfy the deployed project's range #​13857.

• pnpm sbom now leaves out a package's author field when the manifest author name is empty or contains only whitespace #​14685. In a filtered or split workspace run, only a project with no author field inherits the workspace root's author.

  pnpm sbom --sbom-format spdx now writes creationInfo.created with whole seconds, such as 2026-09-08T10:38:21Z #​14684. The fractional seconds it carried were rejected by strict SPDX consumers.

Configuration

• The updateConfig pnpmfile hook now receives the resolved configuration, including settings that came from .npmrc, the command line, or a default #​14676. Scoped registries are reported under registriesByScope, and a hook may rewrite that map to change where packages are fetched from. Registry credentials are reported under configByUri, as pnpm 11 reports them. An unset setting is left out rather than reported as null.

• pnpm audit --fix and the minimumReleaseAgeStrict approval prompt now keep the comments in minimumReleaseAgeExclude when they append an entry to it in pnpm-workspace.yaml. The rest of the list is left as written, and the trustPolicyExcludePrune and minimumReleaseAgeExcludePrune cleanups keep the comments of the entries they retain.

  pnpm install and pnpm dedupe now run those cleanups too #​14759. Only pnpm add, pnpm update, and pnpm remove pruned the entries that the freshly written lockfile no longer resolves.

• pnpm config set --global node-download-mirrors no longer rejects the key #​13611. The global config file already accepted nodeDownloadMirrors, but the command refused to write it.

• NO_PROXY entries that start with a dot, such as .npmjs.org, now bypass the proxy for the domain and its subdomains #​14686.

• pnpm no longer creates a project pnpm-lock.yaml when devEngines.packageManager.onFail is download and lockfile writing is off through lockfile: false or --no-lockfile #​14728. pnpm still switches to the pinned version.

• pnpm now writes node_modules/.package-map.json only when nodeExperimentalPackageMap is enabled. Nothing reads the file without that setting, and an install that stops writing the map removes the one a previous install left.

Windows

• pnpm pipeline no longer fails with intermittent access denied errors when concurrent tasks save their cache entries on Windows.

• Windows filesystem operations now retry permission errors for up to one second #​14682. A permanent permission error delayed the failure by a minute. Sharing and lock violations keep their one minute retry budget.

Messages and output

• pnpm now warns when the root package.json declares a non-empty workspaces array and the project has no pnpm-workspace.yaml #​2255. Such an install linked no project and said nothing about why.

• ERR_PNPM_PACKAGE_MANAGER_REMOVE_MODULES_DIR now names the file or directory in node_modules that pnpm could not clean up. It reported only the underlying OS error, such as "Access is denied (os error 5)".

• pnpm --help no longer describes pnpm as experimental.

Platinum Sponsors

Gold Sponsors

v12.4.0: pnpm 12.4

Compare Source

Minor Changes

• pnpm can now manage npm, Python, and Cargo dependencies in the same workspace. Enable python.enabled or cargo.enabled in pnpm-workspace.yaml, then use pnpm install to install them together.

  • Add Python packages with pnpm add pypi:<package>. pnpm uses pyproject.toml, pylock.toml, and a managed .venv. Frozen and offline installs are supported, and pnpm run and pnpm exec make the environment's executables available #​14566.
  • Add Rust crates with pnpm add crate:<package>. pnpm supports crates.io and custom sparse registries configured with cargo.indexUrl. Registry authentication supports pnpm credentials and, for crates.io, CARGO_REGISTRY_TOKEN or $CARGO_HOME/credentials.toml.

  Both ecosystems support faster dependency resolution through pnprServer, with local resolution as a fallback when the server does not support it.

• Added pnpm pipeline [name] to install frozen dependencies and run workspace tasks declared in pipelines. It selects affected projects, runs their task graph, and continues running tasks after a task fails.

  Tasks support inputs, outputs, env, and cache settings. Cached results restore task outputs and replay logs. Cargo tasks can reuse local build state between worktrees with tasks.<name>.cargoTargetDir. Set includeWorkspaceRoot: true to include root tasks.

  Use pnpm pipeline --dry-run to preview the task graph without installing configuration dependencies or running workspace hooks.

• Added support for Android on arm64 and x64, FreeBSD on x64, and Linux on ppc64le, s390x, and RISC-V (riscv64 with glibc) #​14431, #​14597, #​7582.

• Added trustPolicyExcludePrune to automatically remove unused versions and packages from trustPolicyExclude when running pnpm add, pnpm update, or pnpm remove. It is disabled by default. Package name patterns such as @scope/* are kept, and cleanup is skipped when sharedWorkspaceLockfile is false.

• Added pnpm change check for CI validation of package versions against the versioning.epics bands and versioning.fixed groups in pnpm-workspace.yaml. It reports all violations, including packages that are not part of the current release.

Patch Changes

• Registry metadata is now kept separate for registries with different URL paths or schemes. This prevents installs from using another registry's package versions or tarball URLs, and keeps metadata fetched over HTTP from being reused for HTTPS #​13558.

  The first install after upgrading refetches registry metadata. The package store is unchanged. pnpm cache view now shows full registry URLs. Scripts that parse the directory names from pnpm cache list-registries or pnpm cache list need updating.

• Patches that add build scripts or a binding.gyp now trigger a build, subject to build approval. Unapproved builds appear under "Ignored build scripts" #​14648.

• Build scripts can now be rejected before installing a package with pnpm add --allow-build=!<pkg>, including global installs. pnpm approve-builds <pkg> and pnpm approve-builds !<pkg> also save decisions when no packages are awaiting approval. They warn if the named package is not awaiting approval #​14067.

• A registry configured in .npmrc now takes precedence over registry settings saved by pnpm login in the global config.yaml. This fixes installs using the wrong registry after login #​14614.

• Large downloads over slow connections no longer time out while data is still arriving. fetch-timeout now limits how long a request can go without making progress #​14604.

• Sped up installs in workspaces with many projects when reusing a warm global virtual store #​14540.

• pnpm deploy is faster in large workspaces and no longer fails with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH when the project includes a .pnpmfile.mjs #​14539, #​14671.

• pnpm add --workspace <pkg> works again. It saves the dependency with the workspace: protocol and links it from the workspace. The command fails if no workspace project provides the package #​14602.

• pnpm add and pnpm install now accept protocol-prefixed selectors such as jsr:@scope/pkg, npm:pkg@^1.0.0, and workspace:pkg@* #​14590. Installs with JSR dependencies in the lockfile also no longer fail with ERR_PNPM_META_FETCH_FAIL #​14649.

• Boolean flags now accept explicit inline values. For example, pnpm install --prod=false installs devDependencies, while --prod=true skips them #​14553.

• pnpm install <pkg> now accepts --offline and --prefer-offline, as pnpm add <pkg> already did #​14194.

• Fixed pnpm install --frozen-lockfile rejecting a freshly generated lockfile when overrides use relative file: or link: paths in a workspace #​14555.

• Fixed installs with config dependencies failing on symlinked lockfiles, such as those used by Bazel and Nix, when the config dependencies have not changed. Updates that would write through a symlink remain disallowed. Updating config dependencies also preserves lockfiles that start with a byte order mark #​14372.

• Fixed package manager version pins being written to the wrong lockfile when lockfileDir is set. The pins also remain consistent across commands when version switching is disabled, avoiding unnecessary lockfile changes #​14633, #​14575.

• pnpm import now respects lockfileDir and branch lockfiles without modifying other lockfiles. Failed imports restore the destination lockfile #​14563.

• pnpm patch-commit now produces valid patches when files are added or deleted. pnpm install also accepts patches that delete files without listing their contents, and patch files with CRLF line endings #​14559, #​14557.

• Fixed version ranges with partial upper bounds. For example, <=16 now includes all 16.x versions, and >=0.11 <=3 correctly accepts 3.0.1 #​14419.

• Workspace package patterns now support . and .. segments and repeated slashes. Patterns such as ./packages/* and exclusions such as !./packages/foo now match correctly #​14571.

• packageConfigs settings now apply to the specified projects when sharedWorkspaceLockfile is false, including overrides, hoist, modulesDir, saveExact, and savePrefix. Workspaces with a shared lockfile report which entries were ignored #​14556.

• pnpm run and pnpm exec no longer report a changed workspace structure after a successful install when sharedWorkspaceLockfile is false and verifyDepsBeforeRun is enabled #​14588.

• Commands run from a project's subdirectory now find the nearest ancestor with a manifest. This fixes commands such as pnpm bin returning paths under the wrong directory. pnpm init still creates its manifest in the current directory, and pnpm exec still runs there #​14622.

• Relative scriptShell paths in pnpm-workspace.yaml now resolve from the workspace root, including when scripts run in nested packages. Bare command names such as bash still use PATH #​14422.

• Fixed installing the pnpm version pinned in packageManager when nodeLinker is hoisted. Managed Node.js, Deno, and Bun installations also work when the global config uses nodeLinker: hoisted #​14595.

• The JavaScript pnpm can again switch to a project's pinned pnpm version on platforms without a native binary for that version, such as Alpine Linux with pnpm 10 or Intel Macs with pnpm 11. If a native pnpm version does not support the platform, the error now names the missing target #​13622.

• Provisioning Yarn 6 now uses GH_TOKEN or GITHUB_TOKEN when available to avoid GitHub's anonymous API rate limit in CI. Tokens are only sent when strict-ssl is enabled.

• Fixed concurrent installs sharing a global virtual store on macOS failing with "failed to import ... No such file or directory" #​14560.

• Fixed pnpm setup failing with ERR_PNPM_DIRECTORY_FETCHER_PATH_ESCAPE on Windows. Local file: dependencies whose directories are symlinks or junctions are now packed correctly #​14618.

• On Windows, installs now retry replacing command shims temporarily locked by another process #​14549.

• Fixed argument forwarding on Windows with shellEmulator enabled. Paths ending in a backslash, line breaks, and literal shell expressions are preserved #​14548.

• Windows store paths now consistently use backslashes in pnpm store path output and in the storeDir and virtualStoreDir fields of node_modules/.modules.yaml.

• Invalid certificates in ca or cafile no longer cause an Invalid CA certificate error. Valid certificates still apply, and blank cert or key values are treated as unset #​14646.

• Installs now respect the archive extraction concurrency limit even after a download is abandoned #​14585.

• pnpm audit summaries now exclude advisories ignored through auditConfig.ignoreGhsas and report them separately. When all advisories are ignored, the summary says so #​14535.

• pnpm pack --json now reports errors as JSON. Lifecycle script output appears before the final JSON output.

• pnpm outdated -r now wraps the Dependents column, keeping the table readable when many workspace projects use the same dependency #​14591.

• Shell completions now support the pn alias in bash, fish, pwsh, and zsh #​11955.

• pnpm version now accepts -m as a short alias for --message #​14567.

Platinum Sponsors

Gold Sponsors

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.