Open
Conversation
See associated pull request for more information.
f20ece9 to
9149437
Compare
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:
10.33.0→10.33.2Release Notes
pnpm/pnpm (pnpm)
v10.33.2: pnpm 10.33.2Compare Source
Patch Changes
Globally-installed bins no longer fail with
ERR_PNPM_NO_IMPORTER_MANIFEST_FOUNDwhen pnpm was installed via the standalone@pnpm/exebinary (e.g.curl -fsSL https://get.pnpm.io/install.sh | sh -) on a system without a separate Node.js installation. Previously, whenwhich('node')failed duringpnpm add --global, pnpm fell back toprocess.execPath, which in@pnpm/exeis the pnpm binary itself — and that path was baked into the generated bin shim, causing the shim to invoke pnpm instead of Node #11291, #4645.Fix an infinite fork-bomb that could happen when pnpm was installed with one version (e.g.
npm install -g pnpm@A) and run inside a project whosepackage.jsonselected a different pnpm version via thepackageManagerfield (e.g.pnpm@B), while apnpm-workspace.yamlalso existed at the project root.The child's environment is now forced to
manage-package-manager-versions=false(v10) andpm-on-fail=ignore(v11+), which disables the package-manager-version handling in whichever pnpm runs as the child.Fixes #11337.
Platinum Sponsors
Gold Sponsors
v10.33.1: pnpm 10.33.1Compare Source
Patch Changes
packageManagerfield selects pnpm v11 or newer, commands that v10 would have passed through to npm (version,login,logout,publish,unpublish,deprecate,dist-tag,docs,ping,search,star,stars,unstar,whoami, etc.) are now handed over to the wanted pnpm, which implements them natively. Previously they silently shelled out to npm — making, for example,pnpm version --helpprint npm's help on a project withpackageManager: pnpm@11.0.0-rc.3#11328.Platinum Sponsors
Gold Sponsors