chore(deps): update proto dependencies bump

[renovate]

This PR contains the following updates:

Package	Update	Change	Age	Confidence
node (source)	patch	26.5.0 → 26.5.1
pnpm (source)	minor	11.17.0 → 11.18.0
uv	minor	0.11.33 → 0.12.0

---

Release Notes

nodejs/node (node)

v26.5.1

Compare Source

pnpm/pnpm (pnpm)

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 Workspace column of pnpm update --interactive now falls back to the project's path when its name is only whitespace, as it already did for a missing or empty one — all three render an equally blank label otherwise.

• Checking GitHub Actions dependencies for updates is now opt-in for every command. Neither pnpm outdated nor pnpm update reads the workflow files unless --include-github-actions is passed or update.githubActions is set to true in pnpm-workspace.yaml. Reading them runs git ls-remote against every referenced repository, which fails in environments where GitHub is not reachable the way pnpm assumes (a GitHub Enterprise Server, a custom certificate authority, or an offline network) #​13254.

  pnpm outdated accepts the --include-github-actions option too.

• pnpm update --interactive now measures its table in terminal columns rather than in characters. A package name, workspace name, or version containing wide characters (CJK, most emoji) no longer knocks its row's columns out of line with the rest of the group, and a wide character in a version no longer aborts the command with Subject parameter value width cannot be greater than the container width #​13357.

• The Workspace column of pnpm update --interactive is more informative in two cases. A dependency outdated at the same version in several workspace projects is offered as one choice, since selecting it updates every project — that choice now names all of them instead of only the first. And a workspace project without a name is now labelled with its path rather than left blank, so several unnamed projects can be told apart.

• An auto-installed optional peer is no longer hoisted at a version the workspace root's own dependency on that package excludes. resolvePeersFromWorkspaceRoot already made the workspace root's specifier decide which version a missing required peer is installed at; the optional-peer picker ignored it and always took the highest version present anywhere in the graph. In a workspace whose root pins postcss: 8.5.10, an importer that depends on webpack and declares no postcss of its own got postcss@8.5.22 hoisted for terser-webpack-plugin's optional postcss peer, leaving two postcss@8.5.x instances in the graph #​13320.

• overrides now also govern peers that pnpm auto-installs. Previously an override only rewrote dependencies declared in a manifest, so a peer nobody declares — installed because autoInstallPeers is on — resolved against its declared peer range and could bring in a second copy of the very package the override pinned. For example, with overrides: { react: npm:react@19.2.0 } and a lone lucide-react dependency, pnpm installed react@18.3.1; it now installs the pinned react@19.2.0 #​13320.

• Under resolvePeersFromWorkspaceRoot, a workspace root dependency declared with link: or file: (or the path form of workspace:, such as workspace:../pkg) now satisfies another project's missing peer dependency at the linked package's own version, instead of being hoisted as a path. Those specifiers are relative to the project that declares them, so the same specifier reached a different directory — or none — from the project the peer was hoisted into, leaving a broken link. The root now has the same authority over the peer as it has when it declares the package with a version range #​13373.

• Installs through a pnpr server now apply the project's whole verification policy. minimumReleaseAgeExclude, minimumReleaseAgeIgnoreMissingTime, trustPolicy, trustPolicyExclude, trustPolicyIgnoreAfter, and trustLockfile were ignored, so excluded packages were still held back and a lockfile containing them could be rejected.

  trustPolicy: no-downgrade no longer fails with TRUST_POLICY_INCOMPATIBLE_WITH_PNPR when a pnpr server is configured.

  --frozen-lockfile and --no-prefer-frozen-lockfile are now honored on the pnpr path, instead of resolving and rewriting the lockfile anyway. Since frozenLockfile defaults to true on CI, a CI install through a pnpr server now fails on an out-of-date lockfile rather than updating it.

• Workspace installs through a pnpr server no longer crash with Cannot read properties of undefined (reading 'filter') after linking, when minimumReleaseAge is active #​13275.

• Fixed pnpm dedupe updating valid catalog resolutions when another matching version exists in the lockfile.

• pnpm -r run "/pattern/" --no-bail no longer exits zero when one of a project's matched scripts fails and a later one passes. The run summary carries a single status per project, and the passing script overwrote the recorded failure.

• Restored the store block a first install prints, naming how packages were materialized and where the stores live #​13315:

  Packages are hard linked from the content-addressable store to the virtual store.
    Content-addressable store is at: ~/.local/share/pnpm/store/v11
    Virtual store is at:             node_modules/.pnpm
  

• The root project's pnpm:devPreinstall script now runs before resolution and linking, as it does in pnpm 11. It is skipped under --ignore-scripts, --lockfile-only and --dry-run, by pnpm fetch and pnpm rebuild, and by a repeat install that is already up to date. Workspaces that use the hook to prepare state the install depends on — such as next.js, which generates a placeholder next bin with it — were left with dependents linked against files that were never created #​13313.

• Prevented pnpm dedupe --check from removing an incompatible node_modules directory.

• pnpm update --workspace no longer links dependencies the user never named:

  • Running it with updateConfig.ignoreDependencies configured no longer fails with ERR_PNPM_WORKSPACE_PACKAGE_NOT_FOUND for a dependency that is only published to the registry. Such dependencies keep their specifiers, as they already did when no dependencies were ignored.
  • Passing package selectors that match no direct dependency no longer falls back to linking every workspace dependency.

Platinum Sponsors

Gold Sponsors

astral-sh/uv (uv)

v0.12.0

Compare Source

Released on 2026-07-28.

Since we released uv 0.11.0 in March, we've accumulated changes that improve correctness, safety, and compatibility with specifications, but could break some workflows. This release contains those changes; many have been marked as breaking out of an abundance of caution.

We expect most users to be able to upgrade without making changes.

There are no breaking changes to the configuration of the uv build backend. If your [build-system] table includes an upper bound on uv_build, update it to allow uv_build 0.12, e.g., uv_build>=0.11.32,<0.13.

Breaking changes

• Define build systems by default with uv init (#​19197)

  Projects created with uv init now declare a build system and are packaged by default. This was the default project layout all the way back in v0.3, but we found that the use of the hatchling build system was confusing to newcomers and consequently dropped use of a build system by default in v0.4. Since then, we've created our own build system (uv_build) with tight integration with uv and are excited to restore the default to a best-practice project layout.

  Previously, uv init example created an unpackaged layout containing main.py and a pyproject.toml without a build system. The project could declare dependencies but was not itself installed into its virtual environment.

  Now, uv init example defines a [build-system] using uv_build, places application source code in src/example, and includes a [project.scripts] entry named example. Defining a build system allows the project to be imported from tests or other code, installed as a dependency, and run as a command:

  $ uv init example
  $ cd example
  $ uv run example
  Hello from example!

  Existing projects are unaffected. Use uv init --no-package example to create the previous unpackaged layout without a build system.

  See the project creation documentation for more details.

  This stabilizes the packaged-init preview feature.

• Reject unsupported source distribution and wheel archive formats (#​18927)

  PEP 625 requires source distributions to use .tar.gz archives. Previously, uv also accepted legacy formats such as .tar.bz2 and .tar.xz. Those formats are now rejected, including when referenced by an existing lockfile. Legacy .zip source distributions remain supported for backwards compatibility.

  Wheels and other ZIP archives can no longer contain entries compressed with bzip2, LZMA, or XZ. Entries must use the stored, DEFLATE, or zstd compression methods.

  Removing support for uncommon compression methods reduces uv's compression dependencies and the attack surface exposed when processing untrusted packages.

  You cannot opt out of this behavior. If you depend on a legacy source distribution that uses an unsupported format, we recommend rebuilding it as a .tar.gz archive and regenerating any lockfile containing references to the legacy archive.

• Reject wheel files that could replace the Python interpreter (#​20748, #​20749)

  uv already rejected wheel entry points named python, but case variants such as Python were still accepted. On case-insensitive filesystems, including common macOS and Windows setups, these entry points could overwrite the virtual environment's interpreter.

  Wheels could also place interpreter files in their .data/scripts directory or in paths such as .data/data/bin/python, bypassing the entry-point check and replacing the interpreter during installation.

  uv now rejects case-insensitive variants of reserved interpreter names and wheel data files that would be installed over an interpreter. This includes names such as Python, python.py, and Python.exe, along with other reserved interpreter names and their versioned variants.

  You cannot opt out of these checks. Rename conflicting entry points or wheel data files and rebuild the affected wheel.

• Prefer stable releases before falling back to pre-releases (#​19993)

  A dependency can introduce a pre-release requirement after resolution starts. uv previously required each package's pre-release eligibility to be known before resolution began: the default if-necessary-or-explicit mode allowed them for direct requirements that explicitly requested a pre-release, or for packages that only published pre-releases.

  This meant that a pre-release requirement discovered in a dependency's metadata, e.g., example>=2.0.0b1, would fail to resolve even when a compatible pre-release existed. To resolve it, you had to add that dependency as a direct requirement or allow pre-releases across your entire dependency graph.

  The default mode is now if-necessary. uv tries stable candidates first and falls back to pre-releases when no stable candidate satisfies the active constraints. Like pip, uv now supports pre-release requirements discovered transitively, but can select different versions than previous uv releases when both stable and pre-release candidates are available.

  You can opt out of automatic pre-release selection with --prerelease disallow. Alternatively, --prerelease allow considers pre-releases without first preferring stable releases, and --prerelease explicit only allows them for direct requirements that mention a pre-release.

  The old if-necessary-or-explicit mode distinguished between explicitly requested pre-releases and packages with no stable releases. That distinction is unnecessary now that if-necessary handles both cases, including transitive requirements. The old name remains available as an alias but is deprecated and will be removed in a future release.

• Respect --require-hashes directives in requirements.txt (#​19336)

  Previously, uv pip install and uv pip sync warned about --require-hashes inside a requirements.txt file but still installed dependencies without checking their hashes. Now, the directive enables hash-checking mode, just as if --require-hashes had been passed on the command line.

  For example, this requirements file is no longer accepted because the requirement is neither pinned nor hashed:

  --require-hashes
  anyio
  

  You cannot opt out while the directive is present. Pin every requirement with == and provide its hash, or remove --require-hashes if hash checking is not intended.

• Reject MD5-only hashes in hash-checking mode (#​20758)

  Previously, uv pip install --require-hashes and uv pip sync --require-hashes accepted requirements whose only available digest used MD5. MD5 is not collision-resistant, so relying on it undermined installations that require hash verification and differed from pip's behavior.

  Hash-checking mode now requires at least one secure digest for every requirement. For example, the following requirement is rejected unless a secure hash, such as SHA-256, is also supplied:

  anyio==4.0.0 --hash=md5:420d85e19168705cdf0223621b18831a
  

  A secure hash can be supplied directly on the requirement or in a matching constraints file. Ordinary hash verification without --require-hashes continues to support MD5.

  You cannot opt out while hash checking is required. Regenerate affected hashes with SHA-256 or another supported secure hash.

• Reject invalid pylock.toml files and artifacts (#​20402, #​20440, #​20443)

  uv now validates additional requirements from the pylock.toml specification:

  • The packages array must be present. Previously, uv interpreted a missing array as an empty lockfile, so uv pip sync could uninstall an environment instead of rejecting malformed input. An explicitly empty packages = [] array remains valid.
  • Lockfile filenames must be pylock.toml or a single-name variant such as pylock.dev.toml. Names such as pylock..toml and pylock.foo.bar.toml are rejected.
  • If a wheel, source distribution, or other artifact declares a size, the downloaded or cached artifact must match. Previously, an incorrect size was accepted when the hash was correct. Sizes reported by package indexes remain advisory.

  You cannot opt out of these checks. Regenerate malformed lockfiles, rename invalid filenames, and either correct or remove an incorrect optional size value.

• Honor explicit certificate overrides even when no certificates can be loaded (#​20741, #​20767)

  Previously, uv ignored SSL_CERT_FILE or SSL_CERT_DIR values that pointed to missing or inaccessible paths, empty files or directories, or sources without valid certificates. Instead, it fell back to its default trust roots, potentially allowing HTTPS connections that the configured override was intended to reject.

  Now, any non-empty SSL_CERT_FILE or SSL_CERT_DIR value replaces uv's default certificate roots, even when no valid certificates can be loaded. In that case, HTTPS requests fail because no certificates are trusted. This applies to package downloads and remote scripts, including GitHub Gists.

  Fix or unset the certificate override. Unsetting it restores the default trust store; empty environment-variable values continue to be ignored.

• Support pip-compatible --cert handling in uv pip (#​20418)

  The uv pip interface now accepts --cert <path>, e.g.:

  $ uv pip install --cert ./company-ca.pem example

  As in pip, the provided PEM bundle replaces all other certificate sources for that invocation, including system certificates and SSL_CERT_FILE or SSL_CERT_DIR. This change has no effect unless you pass --cert. Include the necessary certificate authorities in the bundle.

  --cert is only supported by uv pip commands; other uv commands continue to use their existing certificate configuration.

• Discover projects relative to the script passed to uv run (#​20225)

  Previously, uv run project/script.py discovered its project from the current directory, even when the script belonged to another project. uv now starts project and workspace discovery from the script's directory instead.

  For example, running uv run other-project/script.py now uses other-project and its dependencies. This fixes scripts that previously failed because their own dependencies were not installed, but can select a different environment than before.

  You can opt out of script-relative discovery by selecting a project explicitly, e.g., uv run --project . other-project/script.py.

  This stabilizes the target-workspace-discovery preview feature.

• Require --force before clearing a directory that is not a virtual environment (#​20225)

  uv venv --clear previously removed any existing target directory, even if it was not a virtual environment. uv emitted a warning but still deleted the directory and its contents. Now, uv refuses to clear directories that do not contain a virtual environment.

  You can opt out of this safety check by explicitly passing --force, e.g., uv venv --clear --force ./not-a-virtualenv.

  This stabilizes the venv-safe-clear preview feature.

• Reject --project when initializing a project (#​20225)

  --project selects an existing project, so it is not meaningful when initializing a new one. Previously, uv init --project example warned and initialized example anyway; if a positional path was also provided, --project was ignored.

  This usage is now an error. Use uv init example to initialize a project at the requested path, or uv init --directory example to change the working directory first.

  This stabilizes the init-project-flag preview feature.

• Reject missing or invalid --project paths (#​20225)

  uv previously warned when --project referred to a missing directory or a file other than pyproject.toml, but then attempted to continue. This could produce confusing errors later or run against an unintended project.

  Now, uv run --project missing python fails immediately instead of continuing. You cannot opt out of this behavior. Create the directory first or select an existing project. Passing --project path/to/pyproject.toml remains supported and selects the file's parent directory.

  This stabilizes the project-directory-must-exist preview feature.

• Skip distributions with non-normalized filenames when publishing (#​20225)

  Distribution filenames must use normalized package names and versions. For example, a wheel for version 1.01.0 should be named example-1.1.0-py3-none-any.whl, not example-1.01.0-py3-none-any.whl.

  Previously, uv publish warned about non-normalized filenames but still attempted to upload them. It now skips the affected wheels and source distributions instead.

  You cannot opt out of this behavior. Rebuild distributions with normalized filenames before publishing.

  This stabilizes the publish-require-normalized preview feature.

• Classify Conda environments named base and root by their paths (#​20225)

  Conda environments named base or root were previously assumed to be the base Conda environment, even when they were ordinary child environments. uv now recognizes child Conda environments named base or root based on their paths, as it already does for other names.

  You can opt out of automatic interpreter selection by requesting an interpreter explicitly with --python /path/to/python.

  This stabilizes the special-conda-env-names preview feature.

• Reject broken .venv symlinks during environment discovery (#​20433)

  Previously, uv could ignore a broken .venv symlink and continue searching parent directories for another virtual environment. As a result, commands such as uv pip install could unexpectedly modify an unrelated ancestor environment.

  uv now stops at a broken .venv symlink and reports its exact path. Errors encountered while reading virtual environment metadata, including permission failures, are also reported immediately instead of being ignored.

  You cannot opt out of this behavior. Repair or remove the broken .venv symlink and correct any permissions that prevent uv from inspecting the environment.

• Reinstall matching installed Python patch versions instead of upgrading implicitly (#​20659)

  Before Python upgrades were supported, uv python install 3.12 --reinstall doubled as a way to install the latest Python 3.12 patch release. Now that --upgrade is available, --reinstall reinstalls the matching patch releases that are already present.

  For example, if Python 3.12.6 and 3.12.7 are installed, uv python install 3.12 --reinstall reinstalls both versions instead of installing the latest available 3.12 release.

  You can recover the previous upgrade behavior with uv python install 3.12 --upgrade. Combine --upgrade --reinstall to reinstall only the latest patch.

• Require --upgrade-group to name an existing dependency group (#​18957)

  Previously, uv lock --upgrade-group docs silently succeeded even if no docs dependency group existed. uv now validates the requested group against the project, its workspace members, and workspace-level dependency groups.

  You cannot opt out of this behavior. Correct the group name or add it to [dependency-groups]. Legacy tool.uv.dev-dependencies still satisfies --upgrade-group dev.

• Resolve relative indexes and find-links against --directory (#​20740)

  The --directory option changes the directory in which uv operates. Previously, relative index and find-links paths supplied on the command line were still resolved against the original working directory.

  uv now resolves --index, --default-index, --index-url, --extra-index-url, and --find-links relative to the directory selected by --directory. For example:

  $ uv add --directory project --index ./packages example

  This now uses project/packages instead of ./packages in the original working directory. Absolute paths and indexes loaded from configuration files are unaffected.

  To preserve the previous target, pass an absolute path or adjust the relative path, e.g., --index ../packages.

• Preserve absolute paths provided to uv add (#​18402)

  uv add previously converted every local dependency into a project-relative path, even when the original request used an absolute path or a literal file:// URL. It now preserves the form of the request in pyproject.toml and uv.lock:

  $ uv add ../library             # remains relative
  $ uv add /projects/library      # remains absolute

  Absolute paths make a project less portable. Use a relative path to avoid recording an absolute path. URLs containing expanded variables retain their existing relative-path behavior.

• Remove older PyPy distributions that are only available as bzip2 archives (#​20423)

  Older PyPy patch releases that are only distributed as .tar.bz2 archives are no longer available through uv python install. These releases require unsupported bzip2 archives.

  The latest PyPy release for each supported Python minor version is available as a gzip-compressed archive and remains supported. For example, uv python list 3.10 --all-versions still includes the latest PyPy 3.10 release, but older bzip2-only patch releases are omitted.

  You cannot opt out of this behavior. Request a newer PyPy patch release instead.

• Omit excluded-package comments when annotations are disabled (#​20085)

  uv pip compile --no-annotate suppresses comments describing the generated requirements file. Previously, a footer listing packages excluded with --unsafe-package was still included, even though annotations were disabled. That footer is now omitted.

  You can recover the footer by removing --no-annotate.

Stabilizations

• TOML 1.0-compatible source distributions (#​20225)

  uv_build now writes a TOML 1.0-compatible pyproject.toml when building source distributions, allowing older Python build frontends to consume projects that use newer TOML syntax. The original project file remains available in the archive as pyproject.toml.orig.

  This stabilizes the toml-backwards-compatibility preview feature.

• Automatic open-file limit adjustment on Unix (#​20225)

  On Linux and macOS, uv now attempts to raise the soft open-file limit at startup toward the hard limit, capped at 1,048,576 descriptors. The new limit also applies to subprocesses and reduces failures caused by running out of file descriptors. If the limit cannot be raised, uv continues running with the existing limit.

  This stabilizes the adjust-ulimit preview feature.

Preview features

• Allow uv upgrade to target multiple packages, upgrade all production dependencies, and exclude selected dependencies (#​20338)

Bug fixes

• Include extras activated by dependency groups when evaluating conflicts (#​20237)

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• 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.