Conversation
|
Size Change: 0 B Total Size: 3.49 kB ℹ️ View Unchanged
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
11.0.0+sha512.5bd187500e49cc6c3d891d973b432c02b844a5eb7209172c90a517a3ef4f579ed5c23d409b699e6a9dc418ff7b2b1890e63f6d74f1d3fc49848f37779c89c84c→11.0.3Release Notes
pnpm/pnpm (pnpm)
v11.0.3Compare Source
Patch Changes
node_modules/.bin#11412.ERR_PNPM_FETCH_404when installing a project whose lockfile depends on afile:tarball. The previous behavior dropped thetarballfield fromfile:and git-hosted resolutions whenlockfile-include-tarball-url=false(the default), even though those URLs cannot be reconstructed from the package name, version, and registry #11407.v11.0.2Compare Source
Patch Changes
ENOENTsymlink failure whenpnpm add -gtriggers the approve-builds prompt. The global add flow used to forward an absolutemodulesDir(<installDir>/node_modules) into the install run byapprove-builds. The install layer treatedmodulesDiras a path relative tolockfileDirand joined it again, producing a doubled path on Windows becausepath.joindoes not collapse an embedded absolute path. The hoist step then tried tomkdirand symlink under<installDir>\<installDir>\node_modules\.pnpm\node_modules\...and failed withENOENT#11403.packageManagerDependenciesgoing stale when pnpm is invoked through corepack. The lockfile sync (and thedevEngines.packageManagerversion check) previously ran only when pnpm was invoked directly; under corepack the entire block was skipped, so a stale entry would persist even after the running pnpm version changed. The lockfile sync now runs regardless of how pnpm was invoked, while the pnpm-managed version switch (onFail: 'download') remains skipped under corepack so it doesn't fight corepack's own version selection #11397.publishConfig.directorywhen packages publish from a generated directory #11239.os/cpuentries (e.g.["!win32"]) being incorrectly rejected whensupportedArchitecturesexpands to multiple platforms #11375.v11.0.1Compare Source
Patch Changes
pnpm runscripts.nullnamed catalogs in workspace manifests withInvalidWorkspaceManifestErrorinstead of crashing with a rawTypeError.pnpm sbomemittedNOASSERTION(SPDX) and omitted the distribution reference (CycloneDX) for git dependencies. Now emits the git URL with commit hash, e.g.git+https://github.com/user/repo.git#commit.pnpm self-updatenow keepspackage.json'spackageManageranddevEngines.packageManagerin sync. When the legacypackageManagerfield pins pnpm, both fields are rewritten to the new exact pnpm version on update —packageManagertopnpm@<version>(without an integrity hash), anddevEngines.packageManager.versionto the same exact<version>(dropping any range operator). When onlydevEngines.packageManageris declared, the existing range-preserving behavior is unchanged #11388.pnpm audit --fixso that the log output order matches the order written topnpm-workspace.yaml.packageManagerDependenciesentry whendevEngines.packageManagerdeclares a pnpm version that the lockfile no longer satisfies. Previously, the stale entry was kept even though the running pnpm matched the declared version, silently breaking the integrity record #11387.Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.