You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
352ae48: Security: validate config dependency names and versions before using them to build filesystem paths. A pnpm-workspace.yaml with a traversal-shaped configDependencies name (such as ../../PWNED) or version (such as ../../../PWNED) could previously cause pnpm install to create symlinks or write package files outside node_modules/.pnpm-config and the store. Names must now be valid npm package names and versions must be exact semver versions. See GHSA-qrv3-253h-g69c.
352ae48: Reject path-traversal and reserved dependency aliases (such as ../../../escape, .bin, .pnpm, or node_modules) that come from a lockfile rather than a freshly resolved manifest. A crafted lockfile alias could otherwise be joined directly under a hoisted node_modules directory, letting package files be written outside the intended install root or overwrite pnpm-owned layout.
The nodeLinker: hoisted graph builder now validates each alias at the directory sink (safeJoinModulesDir), matching the validation pnpm already performs when resolving aliases from manifests. See GHSA-fr4h-3cph-29xv.
352ae48: Prevent pnpm patch-remove from removing files outside the configured patches directory.
217fbe0: Hardened the warning printed when a project .npmrc uses environment variables in registry/auth settings: the suggested pnpm config set command is now only included for keys made up of shell-inert characters. Because the key comes from a repository-controlled .npmrc and a shell expands $(...), backticks, and $VAR even inside double quotes, a crafted key could otherwise have turned the suggested copy-paste command into command execution.
⚠️ Security fix — environment variables in a project .npmrc (action may be required)
Following GHSA-3qhv-2rgh-x77r, pnpm no longer expands ${ENV_VAR} placeholders that come from a repository-controlled config file, because a malicious repository could otherwise use them to leak your environment secrets (npm tokens, CI job tokens, etc.) to an attacker-controlled registry during install. This applies to:
This release also closes a bypass where a project .npmrc could set userconfig, globalconfig, or prefix to make pnpm load a repo-supplied file as trusted config (via @pnpm/npm-conf@3.0.3).
Environment variables are still expanded in trusted config: your user-level ~/.npmrc, the global config, CLI options, and environment config.
If your authentication broke after upgrading, move the token out of the committed .npmrc:
# Writes to your user/global config, not the repository:
pnpm config set"//registry.npmjs.org/:_authToken""$NPM_TOKEN"
Or keep the ${NPM_TOKEN} line but put it in your user-level ~/.npmrc instead of the repo. In GitHub Actions, actions/setup-node with registry-url already writes a user-level .npmrc, so NODE_AUTH_TOKEN keeps working. For other CI where editing each pipeline is hard, set NPM_CONFIG_USERCONFIG=.npmrc in the CI environment to declare the project .npmrc trusted.
Improved the warning printed when a project .npmrc uses an environment variable in a registry/proxy URL or in registry credentials. The message now explains why the setting was ignored and how to migrate it to a trusted source — for example by running pnpm config set "<key>" <value> to store it in the global config, or by keeping the ${...} line in the user-level ~/.npmrc — with a link to https://pnpm.io/npmrc.
A repository-controlled project or workspace .npmrc can no longer redirect which files pnpm loads as its trusted user and global configuration. Previously such a file could set userconfig, globalconfig, or prefix to point at an attacker-supplied file shipped in the repository, and pnpm would load it as a trusted config source — bypassing the protection that prevents repository config from expanding environment variables into registry request destinations and credentials, and allowing it to set tokenHelper. The user/global config file locations are now resolved only from trusted sources (CLI options, environment config, the npm builtin config, and defaults) before the project and workspace .npmrc files are read. Fixed by upgrading @pnpm/npm-conf to 3.0.3.
⚠️ Security fix — environment variables in a project .npmrc (action may be required)
Following GHSA-3qhv-2rgh-x77r, pnpm no longer expands ${ENV_VAR} placeholders that come from a repository-controlled config file, because a malicious repository could otherwise use them to leak your environment secrets (npm tokens, CI job tokens, etc.) to an attacker-controlled registry during install. This applies to:
This release also closes a bypass where a project .npmrc could set userconfig, globalconfig, or prefix to make pnpm load a repo-supplied file as trusted config (via @pnpm/npm-conf@3.0.3).
Environment variables are still expanded in trusted config: your user-level ~/.npmrc, the global config, CLI options, and environment config.
If your authentication broke after upgrading, move the token out of the committed .npmrc:
# Writes to your user/global config, not the repository:
pnpm config set"//registry.npmjs.org/:_authToken""$NPM_TOKEN"
Or keep the ${NPM_TOKEN} line but put it in your user-level ~/.npmrc instead of the repo. In GitHub Actions, actions/setup-node with registry-url already writes a user-level .npmrc, so NODE_AUTH_TOKEN keeps working. For other CI where editing each pipeline is hard, set NPM_CONFIG_USERCONFIG=.npmrc in the CI environment to declare the project .npmrc trusted.
Package-manager bootstrap traffic is now resolved through trusted registries and trusted network config. When pnpm downloads the pnpm version requested by a repository's packageManager field, the registry it fetches from (and the proxy/TLS settings used for that traffic) now come exclusively from trusted config sources — CLI options, env config, user and global .npmrc — defaulting to the public npm registry, instead of the repository's project/workspace settings.
pnpm now verifies the npm registry signature of a package-manager binary before spawning it. When the packageManager field (or pnpm self-update) makes pnpm download another pnpm version, the staged install is verified corepack-style: the integrity recorded in the staged lockfile must carry a valid npm registry signature for the exact name@version, validated against npm's public signing keys that ship embedded in the pnpm CLI. Verification fails closed — a tampered download, an unsigned package, or an unreachable registry refuses the version switch rather than running an unverified binary. It runs only when the wanted version is actually downloaded (a tools-directory cache miss), so repeated commands pay no extra network round trip.
Environment variable expansion is now trust-aware for registry/auth config and request destinations. Repository-controlled config files (the project and workspace .npmrc and pnpm-workspace.yaml) can no longer expand ${...} placeholders in registry/proxy request destinations, URL-scoped keys, or registry credential values, preventing repository-controlled configuration from exfiltrating environment secrets through request URLs. Trusted user/global/CLI/env config keeps full env expansion, so existing token and registry setup flows continue to work.
Reject reserved manifest bin names ("", ".", "..", and scoped forms such as @scope/..) when resolving a package's bins. These names previously passed the bin-name guard and, when joined to the global bin directory during global remove/update/add operations, could resolve to the global bin directory itself or its parent and have it recursively deleted.
Require trusted package identity before package-name onlyBuiltDependencies (and allowBuilds) entries can approve lifecycle scripts for git, git-hosted tarball, direct tarball, and local directory artifacts. To approve one of those artifacts explicitly, use its peer-suffix-free lockfile depPath as the key. Lockfile entries are now rejected when a registry-style dependency path (name@semver) is backed by a git, directory, or git-hosted tarball resolution (ERR_PNPM_RESOLUTION_SHAPE_MISMATCH), so the dependency path is a reliable artifact identity by the time scripts can run.
pnpm now verifies the detached OpenPGP signature of a Node.js release's SHASUMS256.txt against the Node.js release team's public keys (embedded in the pnpm CLI) before trusting its hashes. The Node.js download mirror is repository-configurable (node-mirror:<channel> in .npmrc), and the integrity check previously trusted a SHASUMS256.txt fetched from that same mirror — a circular check that a malicious mirror could satisfy with a tampered binary and matching hashes. A mirror that proxies the real signed SHASUMS keeps working unchanged. Only the release channel publishes signed SHASUMS files, so pre-release channels (rc, nightly, …) remain unverified.
Reject pnpm-lock.yaml entries whose remote tarball resolution: block is missing the integrity field. Previously the worker that extracts a downloaded tarball skipped hash verification when no integrity was supplied and minted a fresh one from the unverified bytes, so an attacker who could both alter the lockfile (e.g. via a pull request that strips integrity:) and serve modified content at the referenced tarball URL could install a tampered package without any error — including under --frozen-lockfile. pnpm now fails closed at lockfile-read time with ERR_PNPM_MISSING_TARBALL_INTEGRITY. Git-hosted tarballs (gitHosted: true or a URL on codeload.github.com / bitbucket.org / gitlab.com) and file: tarballs are exempt — the commit SHA in a git-host URL and the user-controlled local path already anchor the bytes.
Treat tarball-integrity mismatches against the lockfile as a hard failure by default. Previously, pnpm install (non-frozen) would log ERR_PNPM_TARBALL_INTEGRITY, silently re-resolve from the registry, and overwrite the locked integrity — which meant a compromised registry, proxy, or republished version could substitute attacker-controlled content on a clean machine even though the project shipped a committed lockfile.
pnpm install now exits with ERR_PNPM_TARBALL_INTEGRITY and a hint pointing at the new opt-in flag.
The only opt-in is pnpm install --update-checksums — narrowly scoped to refreshing the locked integrity values from what the registry currently serves. Mirrors yarn's flag of the same name. A warning still prints when the bypass takes effect so the operation is auditable.
--force and pnpm update deliberately do not bypass the integrity check. They are routine refresh operations; silently overwriting a locked integrity in those flows would erase the protection a committed lockfile is supposed to provide. --frozen-lockfile behavior is unchanged. --fix-lockfile keeps its documented purpose (filling in missing lockfile entries) and is also not a bypass.
Patch Changes
Pin unscoped per-registry settings (_authToken, _auth, username/_password, tokenHelper, inline cert/key) to the registry declared in the same config source at load time, so a later layer overriding registry= (workspace `.n
✂ Note
PR body was truncated to here.
Configuration
📅 Schedule: (UTC)
Branch creation
Between 12:00 AM and 03:59 AM, only on Monday (* 0-3 * * 1)
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
renovateBot
changed the title
fix(deps): update all non-major dependencies
chore(deps): update dependency rolldown to v1.0.0-beta.9-commit.43425a0
May 20, 2025
renovateBot
changed the title
chore(deps): update dependency rolldown to v1.0.0-beta.9-commit.43425a0
fix(deps): update all non-major dependencies
May 20, 2025
renovateBot
changed the title
fix(deps): update all non-major dependencies
chore(deps): update dependency rolldown to v1.0.0-beta.9-commit.d91dfb5
Jun 5, 2025
renovateBot
changed the title
chore(deps): update dependency rolldown to v1.0.0-beta.9-commit.d91dfb5
fix(deps): update all non-major dependencies
Jun 6, 2025
Next steps: Take a moment to review the security alert above. Review
the linked package source code to understand the potential risk. Ensure the
package is not malicious before proceeding. If you're unsure how to proceed,
reach out to your security team or ask the Socket team for help at
support@socket.dev.
Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code.
Mark the package as acceptable risk. To ignore this alert only
in this pull request, reply with the comment
@SocketSecurity ignore npm/@emnapi/runtime@1.11.1. You can
also ignore all packages with @SocketSecurity ignore-all.
To ignore an alert for all future pull requests, use Socket's Dashboard to
change the triage state of this alert.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^0.127.0→^0.138.07.0.0-dev.20260422.1→7.0.0-dev.20260706.110.33.1→10.34.4^0.21.9→^0.22.0Release Notes
microsoft/typescript-go (@typescript/native-preview)
v7.0.0-dev.20260706.1Compare Source
v7.0.0-dev.20260705.1Compare Source
v7.0.0-dev.20260704.1Compare Source
v7.0.0-dev.20260703.1Compare Source
v7.0.0-dev.20260702.3Compare Source
v7.0.0-dev.20260701.1Compare Source
v7.0.0-dev.20260630.1Compare Source
v7.0.0-dev.20260629.1Compare Source
v7.0.0-dev.20260628.1Compare Source
v7.0.0-dev.20260627.2Compare Source
v7.0.0-dev.20260626.1Compare Source
v7.0.0-dev.20260624.1Compare Source
v7.0.0-dev.20260623.1Compare Source
v7.0.0-dev.20260622.1Compare Source
v7.0.0-dev.20260621.1Compare Source
v7.0.0-dev.20260620.1Compare Source
v7.0.0-dev.20260619.1Compare Source
v7.0.0-dev.20260618.1Compare Source
v7.0.0-dev.20260617.2Compare Source
v7.0.0-dev.20260616.1Compare Source
v7.0.0-dev.20260615.1Compare Source
v7.0.0-dev.20260614.1Compare Source
v7.0.0-dev.20260613.1Compare Source
v7.0.0-dev.20260612.1Compare Source
v7.0.0-dev.20260611.2Compare Source
v7.0.0-dev.20260610.1Compare Source
v7.0.0-dev.20260609.1Compare Source
v7.0.0-dev.20260608.1Compare Source
v7.0.0-dev.20260607.1Compare Source
v7.0.0-dev.20260606.1Compare Source
v7.0.0-dev.20260605.1Compare Source
v7.0.0-dev.20260604.1Compare Source
v7.0.0-dev.20260603.1Compare Source
v7.0.0-dev.20260602.1Compare Source
v7.0.0-dev.20260601.1Compare Source
v7.0.0-dev.20260527.2Compare Source
v7.0.0-dev.20260527.1Compare Source
v7.0.0-dev.20260526.1Compare Source
v7.0.0-dev.20260525.1Compare Source
v7.0.0-dev.20260524.1Compare Source
v7.0.0-dev.20260523.1Compare Source
v7.0.0-dev.20260522.1Compare Source
v7.0.0-dev.20260521.1Compare Source
v7.0.0-dev.20260519.1Compare Source
v7.0.0-dev.20260518.1Compare Source
v7.0.0-dev.20260517.1Compare Source
v7.0.0-dev.20260516.1Compare Source
v7.0.0-dev.20260515.1Compare Source
v7.0.0-dev.20260514.1Compare Source
v7.0.0-dev.20260513.1Compare Source
v7.0.0-dev.20260512.1Compare Source
v7.0.0-dev.20260511.1Compare Source
v7.0.0-dev.20260510.1Compare Source
v7.0.0-dev.20260509.2Compare Source
v7.0.0-dev.20260508.1Compare Source
v7.0.0-dev.20260507.1Compare Source
v7.0.0-dev.20260506.1Compare Source
v7.0.0-dev.20260505.1Compare Source
v7.0.0-dev.20260504.1Compare Source
v7.0.0-dev.20260503.1Compare Source
v7.0.0-dev.20260502.1Compare Source
v7.0.0-dev.20260501.1Compare Source
v7.0.0-dev.20260430.1Compare Source
v7.0.0-dev.20260429.1Compare Source
v7.0.0-dev.20260428.1Compare Source
v7.0.0-dev.20260427.1Compare Source
v7.0.0-dev.20260426.1Compare Source
v7.0.0-dev.20260425.1Compare Source
v7.0.0-dev.20260424.2Compare Source
v7.0.0-dev.20260424.1Compare Source
v7.0.0-dev.20260423.1Compare Source
pnpm/pnpm (pnpm)
v10.34.4: pnpm 10.34.4Compare Source
Patch Changes
352ae48: Security: validate config dependency names and versions before using them to build filesystem paths. Apnpm-workspace.yamlwith a traversal-shapedconfigDependenciesname (such as../../PWNED) or version (such as../../../PWNED) could previously causepnpm installto create symlinks or write package files outsidenode_modules/.pnpm-configand the store. Names must now be valid npm package names and versions must be exact semver versions. See GHSA-qrv3-253h-g69c.352ae48: Reject path-traversal and reserved dependency aliases (such as../../../escape,.bin,.pnpm, ornode_modules) that come from a lockfile rather than a freshly resolved manifest. A crafted lockfile alias could otherwise be joined directly under a hoistednode_modulesdirectory, letting package files be written outside the intended install root or overwrite pnpm-owned layout.The
nodeLinker: hoistedgraph builder now validates each alias at the directory sink (safeJoinModulesDir), matching the validation pnpm already performs when resolving aliases from manifests. See GHSA-fr4h-3cph-29xv.352ae48: Preventpnpm patch-removefrom removing files outside the configured patches directory.217fbe0: Hardened the warning printed when a project.npmrcuses environment variables in registry/auth settings: the suggestedpnpm config setcommand is now only included for keys made up of shell-inert characters. Because the key comes from a repository-controlled.npmrcand a shell expands$(...), backticks, and$VAReven inside double quotes, a crafted key could otherwise have turned the suggested copy-paste command into command execution.Platinum Sponsors
Gold Sponsors
v10.34.3: pnpm 10.34.3Compare Source
.npmrc(action may be required)Following GHSA-3qhv-2rgh-x77r, pnpm no longer expands
${ENV_VAR}placeholders that come from a repository-controlled config file, because a malicious repository could otherwise use them to leak your environment secrets (npm tokens, CI job tokens, etc.) to an attacker-controlled registry during install. This applies to:.npmrc—registry,@scope:registry, proxy URLs, URL-scoped keys (//host/…), and credential values (_authToken,_auth,_password,username,tokenHelper,cert,key);pnpm-workspace.yaml.This release also closes a bypass where a project
.npmrccould setuserconfig,globalconfig, orprefixto make pnpm load a repo-supplied file as trusted config (via@pnpm/npm-conf@3.0.3).Environment variables are still expanded in trusted config: your user-level
~/.npmrc, the global config, CLI options, and environment config.If your authentication broke after upgrading, move the token out of the committed
.npmrc:Or keep the
${NPM_TOKEN}line but put it in your user-level~/.npmrcinstead of the repo. In GitHub Actions,actions/setup-nodewithregistry-urlalready writes a user-level.npmrc, soNODE_AUTH_TOKENkeeps working. For other CI where editing each pipeline is hard, setNPM_CONFIG_USERCONFIG=.npmrcin the CI environment to declare the project.npmrctrusted.See https://pnpm.io/npmrc for full migration details.
Patch Changes
.npmrcuses an environment variable in a registry/proxy URL or in registry credentials. The message now explains why the setting was ignored and how to migrate it to a trusted source — for example by runningpnpm config set "<key>" <value>to store it in the global config, or by keeping the${...}line in the user-level~/.npmrc— with a link to https://pnpm.io/npmrc..npmrccan no longer redirect which files pnpm loads as its trusted user and global configuration. Previously such a file could setuserconfig,globalconfig, orprefixto point at an attacker-supplied file shipped in the repository, and pnpm would load it as a trusted config source — bypassing the protection that prevents repository config from expanding environment variables into registry request destinations and credentials, and allowing it to settokenHelper. The user/global config file locations are now resolved only from trusted sources (CLI options, environment config, the npm builtin config, and defaults) before the project and workspace.npmrcfiles are read. Fixed by upgrading@pnpm/npm-confto3.0.3.Platinum Sponsors
Gold Sponsors
v10.34.2: pnpm 10.34.2Compare Source
.npmrc(action may be required)Following GHSA-3qhv-2rgh-x77r, pnpm no longer expands
${ENV_VAR}placeholders that come from a repository-controlled config file, because a malicious repository could otherwise use them to leak your environment secrets (npm tokens, CI job tokens, etc.) to an attacker-controlled registry during install. This applies to:.npmrc—registry,@scope:registry, proxy URLs, URL-scoped keys (//host/…), and credential values (_authToken,_auth,_password,username,tokenHelper,cert,key);pnpm-workspace.yaml.This release also closes a bypass where a project
.npmrccould setuserconfig,globalconfig, orprefixto make pnpm load a repo-supplied file as trusted config (via@pnpm/npm-conf@3.0.3).Environment variables are still expanded in trusted config: your user-level
~/.npmrc, the global config, CLI options, and environment config.If your authentication broke after upgrading, move the token out of the committed
.npmrc:Or keep the
${NPM_TOKEN}line but put it in your user-level~/.npmrcinstead of the repo. In GitHub Actions,actions/setup-nodewithregistry-urlalready writes a user-level.npmrc, soNODE_AUTH_TOKENkeeps working. For other CI where editing each pipeline is hard, setNPM_CONFIG_USERCONFIG=.npmrcin the CI environment to declare the project.npmrctrusted.See https://pnpm.io/npmrc for full migration details.
Patch Changes
packageManagerfield, the registry it fetches from (and the proxy/TLS settings used for that traffic) now come exclusively from trusted config sources — CLI options, env config, user and global.npmrc— defaulting to the public npm registry, instead of the repository's project/workspace settings.packageManagerfield (orpnpm self-update) makes pnpm download another pnpm version, the staged install is verified corepack-style: the integrity recorded in the staged lockfile must carry a valid npm registry signature for the exactname@version, validated against npm's public signing keys that ship embedded in the pnpm CLI. Verification fails closed — a tampered download, an unsigned package, or an unreachable registry refuses the version switch rather than running an unverified binary. It runs only when the wanted version is actually downloaded (a tools-directory cache miss), so repeated commands pay no extra network round trip..npmrcandpnpm-workspace.yaml) can no longer expand${...}placeholders in registry/proxy request destinations, URL-scoped keys, or registry credential values, preventing repository-controlled configuration from exfiltrating environment secrets through request URLs. Trusted user/global/CLI/env config keeps full env expansion, so existing token and registry setup flows continue to work.binnames ("",".","..", and scoped forms such as@scope/..) when resolving a package's bins. These names previously passed the bin-name guard and, when joined to the global bin directory during global remove/update/add operations, could resolve to the global bin directory itself or its parent and have it recursively deleted.onlyBuiltDependencies(andallowBuilds) entries can approve lifecycle scripts for git, git-hosted tarball, direct tarball, and local directory artifacts. To approve one of those artifacts explicitly, use its peer-suffix-free lockfile depPath as the key. Lockfile entries are now rejected when a registry-style dependency path (name@semver) is backed by a git, directory, or git-hosted tarball resolution (ERR_PNPM_RESOLUTION_SHAPE_MISMATCH), so the dependency path is a reliable artifact identity by the time scripts can run.SHASUMS256.txtagainst the Node.js release team's public keys (embedded in the pnpm CLI) before trusting its hashes. The Node.js download mirror is repository-configurable (node-mirror:<channel>in.npmrc), and the integrity check previously trusted aSHASUMS256.txtfetched from that same mirror — a circular check that a malicious mirror could satisfy with a tampered binary and matching hashes. A mirror that proxies the real signed SHASUMS keeps working unchanged. Only thereleasechannel publishes signed SHASUMS files, so pre-release channels (rc, nightly, …) remain unverified.Platinum Sponsors
Gold Sponsors
v10.34.1: pnpm 10.34.1Compare Source
Patch Changes
pnpm-lock.yamlentries whose remote tarballresolution:block is missing theintegrityfield. Previously the worker that extracts a downloaded tarball skipped hash verification when no integrity was supplied and minted a fresh one from the unverified bytes, so an attacker who could both alter the lockfile (e.g. via a pull request that stripsintegrity:) and serve modified content at the referenced tarball URL could install a tampered package without any error — including under--frozen-lockfile. pnpm now fails closed at lockfile-read time withERR_PNPM_MISSING_TARBALL_INTEGRITY. Git-hosted tarballs (gitHosted: trueor a URL on codeload.github.com / bitbucket.org / gitlab.com) andfile:tarballs are exempt — the commit SHA in a git-host URL and the user-controlled local path already anchor the bytes.Platinum Sponsors
Gold Sponsors
v10.34.0: pnpm 10.34Compare Source
Minor Changes
Treat tarball-integrity mismatches against the lockfile as a hard failure by default. Previously,
pnpm install(non-frozen) would logERR_PNPM_TARBALL_INTEGRITY, silently re-resolve from the registry, and overwrite the locked integrity — which meant a compromised registry, proxy, or republished version could substitute attacker-controlled content on a clean machine even though the project shipped a committed lockfile.pnpm installnow exits withERR_PNPM_TARBALL_INTEGRITYand a hint pointing at the new opt-in flag.The only opt-in is
pnpm install --update-checksums— narrowly scoped to refreshing the locked integrity values from what the registry currently serves. Mirrors yarn's flag of the same name. A warning still prints when the bypass takes effect so the operation is auditable.--forceandpnpm updatedeliberately do not bypass the integrity check. They are routine refresh operations; silently overwriting a locked integrity in those flows would erase the protection a committed lockfile is supposed to provide.--frozen-lockfilebehavior is unchanged.--fix-lockfilekeeps its documented purpose (filling in missing lockfile entries) and is also not a bypass.Patch Changes
_authToken,_auth,username/_password,tokenHelper, inlinecert/key) to the registry declared in the same config source at load time, so a later layer overridingregistry=(workspace `.nConfiguration
📅 Schedule: (UTC)
* 0-3 * * 1)🚦 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.
This PR was generated by Mend Renovate. View the repository job log.