[renovate]

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
pnpm (source)	11.15.1 → 11.28.9
tsdown (source)	^0.22.13 → ^0.23.0
tsdown-preset-sxzz	^0.6.0 → ^0.7.0

---

Release Notes

pnpm/pnpm (pnpm)

v11.28.9: pnpm 11.28.9

Compare Source

This release fixes a crash on registry responses with too many content encodings (GHSA-xjj6-f33q-929c) and sizes the install worker pool by the container's CPU quota. A repeat pnpm install now acts on more setting changes.

Patch Changes

Crashes and security

• A registry response with too many content encodings can no longer crash pnpm. pnpm now uses undici 7.30.1, which fixes GHSA-xjj6-f33q-929c.

• pnpm install now sizes its worker pool by the CPU quota of the container it runs in, such as a Kubernetes CPU limit, when that quota is smaller than the number of CPUs the container may run on. The default workspaceConcurrency respects the quota the same way. On a CI runner with a 4-CPU quota and hundreds of host CPUs, pnpm started hundreds of workers and ran out of memory #​17382.

Repeat installs and changed settings

• A repeat pnpm install now acts on a change to these settings. Before, it reported "Already up to date".

  • storeDir or virtualStoreDir: it recreates node_modules.
  • virtualStoreDirMaxLength: it renames the virtual store directories.
  • dangerouslyAllowAllBuilds turned on: it runs the builds it skipped.
  • trustLockfile turned off: it verifies the lockfile.

• pnpm add, pnpm remove, and pnpm update now fail when the node-linker setting differs from the one recorded in node_modules. A pnpm install of the whole workspace recreates node_modules with the new node-linker, and an install filtered to some projects fails pnpm/tasks#203.

• An install filtered to some workspace projects now fails if node_modules was installed with a different nodeLinker, hoistPattern, publicHoistPattern, store, or virtual store. Before, it recreated node_modules and left the projects it skipped without their dependencies. A pnpm install of the whole workspace still recreates node_modules pnpm/tasks#217.

• pnpm install now takes its fast path in a workspace with patchedDependencies when the previous install ran with another major version of pnpm.

• pnpm install now relinks the bins of a workspace package when its bin field changes, including with --frozen-lockfile and an unchanged lockfile. A filtered install relinks them in the selected projects, and the next install that covers the remaining projects relinks them there #​17324.

• pnpm install now removes command shims from node_modules/.bin when a workspace dependency renames or removes an entry from its bin field pnpm/tasks#211.

• With nodeLinker: hoisted, an install that stops partway no longer leaves the next install trusting the packages it was replacing. Before, reverting the change that started the stopped install, such as a patch edit, kept the half-replaced package in node_modules.

• pnpm run and pnpm exec no longer report the dependencies as out of date after a lockfile change when dedupePeers is true #​17322.

Resolving dependencies and the lockfile

• A package that a plain range and a <prefix>: specifier both resolve from one registry is now recorded once in pnpm-lock.yaml and installed once. The lockfile key names the registry a package resolved from. When that registry declares a prefix, through prefix in registries or through namedRegistries, the package is keyed <name>@<prefix>:<version> however its dependency was written: with the prefix, as a plain range its scope routes to that registry, or through the default registry. Before, the plain range was keyed <name>@<version>, so one tarball was installed twice and instanceof checks and module singletons broke between the two copies. The same name and version served by two registries still get separate entries. When several prefixes declare one registry, its packages are keyed by the lexicographically smallest prefix.

  If a scope you route reaches a registry that also declares a prefix, your next pnpm install re-keys those entries, which shows up as a lockfile diff. Commit it. pnpm install --frozen-lockfile installs the lockfile as recorded.

• pnpm install now resolves a scope's packages again when the scope is routed to another registry in registries. Before, the lockfile kept the versions and integrity resolved from the old registry, so the install failed when the new registry did not serve a locked version or served different content. pnpm records in the workspace state which registry each scope routed to, so a fresh clone without that record installs the lockfile as recorded. Changing the default registry resolves nothing again, and pnpm install --frozen-lockfile is unchanged.

• An optional dependency written with a named-registry prefix, such as work:^1.0.0, now fails the install when it cannot be resolved but the lockfile already has a matching entry from that registry. Such a dependency was skipped, which removed its entries from the lockfile.

• With injectWorkspacePackages: true, a workspace: dependency written as a relative path, such as workspace:../lib-a, in a workspace package now resolves from that package's directory #​17284.

• Fixed pnpm install failing with ERR_PNPM_UNSUPPORTED_PROTOCOL when a workspace package injected through a relative path, such as workspace:../lib, has catalog: dependencies. Their catalog entries now resolve the way they do for a package injected by name #​17280.

• pnpm install now applies the serverType registry setting when it updates the lockfile for an override or catalog change without a full resolution. pnpm wrote the tarball URLs of a declared registry into the lockfile in that case.

• Added the pnpr value to the serverType registry setting. pnpm leaves the tarball URLs of a pnpr registry out of pnpm-lock.yaml.

• A registries entry whose prefix is __proto__ is no longer ignored.

• Installs delegated to a pnpr server now resolve every prefix declared for a registry URL. A dependency or lockfile entry that used the second of two prefixes for the same registry, such as zeta: next to work: in namedRegistries, failed on the server pnpm/tasks#204.

Registries, proxies, and downloading pnpm

• The proxy settings httpProxy, httpsProxy, noProxy, proxy, and noproxy set in the global config.yaml, through PNPM_CONFIG_HTTPS_PROXY and the matching variables, or as --config.httpsProxy on the command line now apply to pnpm self-update and to the download of the pnpm version pinned in packageManager. Previously, these requests read the proxy only from .npmrc and the HTTPS_PROXY family of variables pnpm/tasks#215.

• When https-proxy is false, pnpm now downloads the pnpm version pinned by packageManager through the legacy proxy setting, as installs already do. Setting proxy to false now also stops that download from using the HTTP_PROXY environment variable. The signature check of the pinned pnpm now uses the same proxy and TLS settings as its download pnpm/tasks#193.

• strictSsl and localAddress set in the global config.yaml, through PNPM_CONFIG_STRICT_SSL and PNPM_CONFIG_LOCAL_ADDRESS, or on the command line now apply to pnpm self-update and to the download of the pnpm version pinned in packageManager. These requests read them from .npmrc only before. --config.localAddress now reaches them in the camelCase spelling too pnpm/tasks#201.

Commands

• pnpm audit --ignore and pnpm audit --ignore-unfixable now exit with a non-zero code when vulnerabilities at or above the audit level remain after ignoring. Before, these commands always exited with code 0.

• pnpm audit --fix and pnpm audit --interactive now fail with ERR_PNPM_AUDIT_FIX_WITH_IGNORE when combined with --ignore or --ignore-unfixable. Before, the fix ran and the ignore flags had no effect.

• pnpm ci --lockfile and pnpm ci --config.lockfile=true no longer delete pnpm-lock.yaml. pnpm ci now always keeps the lockfile and runs a frozen install from it.

• pnpm deploy now keeps a deployed symlink to a directory inside the project even if the directory is not among the deployed files, such as a link into node_modules #​17288.

• pnpm pack and pnpm publish again include the files of a publishConfig.directory that is reached through a symlink, together with its bundled dependencies #​17390.

• pnpm -r publish --batch now sends PUT /-/pnpr/v0/publish, the batch publish endpoint that pnpr serves.

• pnpm store prune now keeps the packages that a project still uses when pnpm copied or cloned them into node_modules. These include patched packages, built packages, and every package installed with packageImportMethod: copy. Before, the prune removed them, and the next install downloaded them again #​7192.

• pnpm store prune now keeps the packages of a project that was installed with a different symlinked spelling of the store path. Previously, prune dropped such a project from its list and removed the packages only that project used from the global virtual store.

Speed and output

• Sped up installs of projects whose local directory dependencies share transitive local directory dependencies. pnpm no longer checks a shared directory again for each direct dependency that reaches it #​17374.

• Output that fills the terminal, such as pnpm run --stream script output, is now written once. Before, every new line also rewrote all the lines already on screen #​17387.

• The warning about unrecognized settings now marks symlinkedLockfileTargetDirs as a setting of a newer pnpm version.

Platinum Sponsors

Gold Sponsors

v11.28.8: pnpm 11.28.8

Compare Source

Patch Changes

• The standalone @pnpm/exe builds now embed Node.js 26.12.1. The previously embedded Node.js 26.0.0 still trusted the certificate authority intermediates that Node.js distrusted in October 2026, so a standalone pnpm accepted TLS certificates issued under them.

Platinum Sponsors

Gold Sponsors

v11.28.7: pnpm 11.28.7

Compare Source

This release rejects registry metadata that names a different package than the one requested, applies trustPolicy to the pnpm version a project pins, and caps unpacked package size with maxTarballUnpackedSize. It also removes support for registry revisions, fixes verifyDepsBeforeRun after filtered installs, and finishes commands with their own exit code when a pipe reader exits early.

Patch Changes

Security

• pnpm now fails with ERR_PNPM_REGISTRY_NAME_MISMATCH if a registry returns metadata for a package other than the one requested. Before, pnpm installed the package under the name in the metadata, so allowBuilds rules for the requested package did not apply to it.

• pnpm now applies trustPolicy to the pnpm version a project pins in packageManager or devEngines.packageManager. A pinned version whose trust evidence was downgraded fails the command before pnpm switches to it or records it in the lockfile #​16319.

• minimumReleaseAgeExcludePrune and trustPolicyExcludePrune now keep exclusions for resolved configuration dependencies and their transitive dependencies #​17142.

• Added the maxTarballUnpackedSize setting. pnpm install fails with ERR_PNPM_TARBALL_TOO_LARGE when the files of one package unpack to more than this many bytes, 4 GiB by default pnpm/tasks#81.

Resolving dependencies

• Registry revisions are no longer supported. pnpm now fails with ERR_PNPM_REGISTRY_REVISIONS_UNSUPPORTED on registry metadata that selects a revision, on a +rN version specifier, and on a lockfile entry with a revision field. pnpm update --patches is removed.

• When pnpm install resolves a dependency again, it now reuses a version that the install already resolved for the same package, as a fresh install does. Before, it kept the version the lockfile pinned and added a second copy of the package. A locked version still stays when nothing else in the install prefers another version. To pin a transitive dependency on purpose, use overrides #​17084.

• When another workspace project adds a different version of a package, a project's auto-installed peer on that package now moves to the version a fresh install picks. It used to stay on its locked version while any other project still accepted that version #​17058.

• An optional peer that pnpm adds to a project now keeps the version the lockfile recorded for that project only while the dependency graph still holds it. Otherwise it follows its provider to a version the graph holds. Before, pnpm kept a higher version that only the lockfile held, which left two copies of the peer #​16443.

• A package that lists the same dependency in dependencies and as an optional peer now gets the peer bound when a project adds a provider for it later. The lockfile now records every peer a package declares, including one its own dependency supplies #​17056.

• pnpm install --prod no longer drops a dependency that a package declares both as an optional peer and as its own dependency, when the package resolved it as its own dependency and a dev dependency provides the same package under another alias.

• pnpm now measures a pnpm.overrides entry written as a workspace: path, such as workspace:./packages/foo, from the directory holding pnpm-workspace.yaml. It used to be measured from each package the override rewrote. The install then linked a directory that does not exist, or failed if workspace packages were injected #​17010.

• pnpm install now removes config dependencies that are no longer declared, including when the entire configDependencies setting is removed. Frozen installs reject a lockfile that still records removed config dependencies.

• pnpm add now reads the package name correctly from a tarball URL under a registry URL that has a path, such as https://example.com/npm/. Before, the registry path became part of the name, so a scoped package failed with ERR_PNPM_INVALID_PACKAGE_NAME.

• pnpm add no longer warns that a gist dependency was replaced from a different source when the new specifier names the same gist in another form, such as gist:<id> and https://gist.github.com/<user>/<id>.

• With minimumReleaseAge set, pnpm now revalidates a package's cached full metadata with a single ETag request so an unchanged registry answers with 304, and keeps using the cached copy once the registry confirms it is current, even when the metadata does not list a publish time for every version. Previously, pnpm downloaded that metadata again whenever the cached copy was older than minimumReleaseAge. Packages listed in minimumReleaseAgeExclude also resolve from cached metadata without a registry request when the lockfile already has the version their range picks.

Linking node_modules and workspaces

• Concurrent installs that import the same package into one project now all complete. One of them used to fail with ENOTEMPTY when its copy of the package collided with the copy another install had already placed pnpm/tasks#48.

• pnpm install no longer fails on macOS with EISDIR when it creates store directories in a group-writable store under a umask that removes owner read, such as 0o477.

• pnpm install now succeeds when node_modules is a symlink to an existing directory. Dependency hoisting previously rejected a symlinked node_modules as an invalid destination #​17157.

• A filtered pnpm install --no-lockfile with hoistWorkspacePackages now hoists every workspace project into node_modules/.pnpm/node_modules. It used to hoist only the selected projects pnpm/tasks#168.

• Filtered installs remove obsolete dependencies from the installed lockfile while preserving dependencies still needed by unselected projects.

• With sharedWorkspaceLockfile: false, pnpm install now runs the preResolution hooks and custom resolvers and fetchers of the workspace root's pnpmfile for every project, next to the project's own. A global pnpmfile now runs once per project, and each project's lockfile records the checksum of the root pnpmfile when the project has none of its own. Before, a project's own pnpmfile replaced these root hooks, the global hooks ran twice, and edits to the root pnpmfile could go unnoticed.

• pnpm prune now removes extraneous direct packages from node_modules when package.json and pnpm-lock.yaml are already in sync. pnpm prune also accepts --filter and --recursive to prune selected workspace projects without removing dependencies of unselected projects.

Injected workspace packages

• pnpm install --frozen-lockfile now fails with ERR_PNPM_OUTDATED_LOCKFILE when the dependencies of an injected workspace package or local directory dependency no longer match the lockfile. This covers sharedWorkspaceLockfile: false #​17008, a dependency changed to a different tarball URL or git commit #​17129, and a change in a transitive injected or local directory dependency #​17128.

• pnpm install --frozen-lockfile no longer fails with ERR_PNPM_OUTDATED_LOCKFILE when an injected workspace package depends on a local directory under another name, such as "renamed": "file:../b" #​17130.

• An injected workspace dependency now becomes a link when its dependencies match the workspace package's own, also on an install that leaves the package's installed dependencies as they are. Before, such an install kept it as a copy #​17094.

• An injected workspace package that was linked now becomes a copy when the project that depends on it starts providing one of its peers at a version the package's own workspace context lacks. The link used to stay until that dependency was updated, so the package could not find the peer the project provides #​17057.

• An injected workspace package now keeps only the files its manifest lists after a lifecycle script or a script named in syncInjectedDepsAfterScripts rebuilds it. Before, these refreshes copied every file of the package directory into the injected copy, including files that files or .npmignore leave out. With deployAllFiles: true the copy still gets every file.

• A script listed in syncInjectedDepsAfterScripts now keeps a package's links to its own files as links in the injected copies, the way pnpm install writes them. It no longer fails when the package links to one directory twice or links back to a directory above the link. pnpm install with deployAllFiles no longer fails on such a link back either.

• A script listed in syncInjectedDepsAfterScripts now updates the injected copies of the package it ran in when sharedWorkspaceLockfile is false or the package publishes from publishConfig.directory. Before, those copies kept the files from the last install.

Running scripts and checking dependencies

• When the reader of pnpm's output exits early, as in pnpm outdated | head, pnpm now finishes the command and exits with the command's own exit code pnpm/tasks#133. It used to exit with code 0 at the first write to the closed pipe. That hid the result of commands such as pnpm outdated and stopped pnpm clean before it removed anything.

• With enableGlobalVirtualStore, a Node.js resolve hook that a script registers now sees the importer as context.parentURL after pnpm's NODE_PATH fallback fails to find a bare specifier. Hooks that resolve tsconfig paths aliases from the importer failed with ERR_MODULE_NOT_FOUND #​16979.

• pnpm run, pnpm exec, and pnpm restart now pass the install flags they were given, such as --lockfile-dir, --modules-dir, --store-dir, --offline, and --ignore-scripts, to the pnpm install that verifyDepsBeforeRun: install starts. When that install leaves node_modules out of date, pnpm now prints a warning.

• After pnpm install --filter, pnpm run and pnpm exec now notice a changed manifest or lockfile in a project that the filtered install left out, including the workspace root after a filtered install with pruneDirectDependencies: true pnpm/tasks#181. A filtered install also preserves the recorded ignored build scripts of unselected projects, and pnpm dedupe --check and pnpm install --dry-run no longer record outdated dependencies as installed.

• The verifyDepsBeforeRun check now holds the workspace projects that the selected project depends on, including link: workspace dependencies. --filter=<project>... now selects link: dependencies as well. With sharedWorkspaceLockfile: false, verifyDepsBeforeRun also reports dependencies as outdated when a selected project's pnpm-lock.yaml is missing pnpm/tasks#138.

• verifyDepsBeforeRun and repeat pnpm install runs now apply overrides before comparing a modified package.json with pnpm-lock.yaml #​17127. verifyDepsBeforeRun also checks whether each importer's resolved catalog versions match the catalog snapshot in pnpm-lock.yaml, and respects lockfileDir in single-project repositories.

• verifyDepsBeforeRun now compares manifests, lockfiles, and patch files by content hash. It notices an edit that kept the file's modification time, as cp -p, rsync -a, or an archive extraction leave it, and a patch file that was copied or touched without changing its content no longer marks dependencies as outdated #​16988.

Deploying and other commands

• pnpm deploy now records the peer dependencies of the workspace packages it copies into the deployed lockfile. Before, pnpm rejected that lockfile with --frozen-lockfile when a deployed workspace package declared a peer and injectWorkspacePackages was off #​17093.

• pnpm install --frozen-lockfile and verifyDepsBeforeRun now succeed inside a directory created by pnpm deploy. pnpm deploy writes self-contained workspace and lockfile settings, prunes unused patchedDependencies, and preserves workspace-level dependency resolutions on deployed directory dependencies.

• In workspaces with sharedWorkspaceLockfile: false, pnpm patch, pnpm patch-commit, and pnpm patch-remove now resolve patch files and patchedDependencies entries at the workspace root. pnpm install checks configured patches across all workspace projects before reporting unused patches.

• Trusted publishing with OIDC now works with registries whose URL has a path, such as https://registry.example/npm/private/. pnpm previously sent the token exchange request to the root of the registry host.

• pnpm owner ls now lists the owners of a package on the npm registry. It reported every package as not found.

• pnpm sbom now reads project lockfiles in workspaces with sharedWorkspaceLockfile: false, including filtered and split output, and reports the repository of a package whose repository field is a gist: shorthand.

• pnpm licenses list reports no licenses for workspace projects not recorded in the lockfile. It errors when pnpm-lock.yaml is missing. Empty results now use the requested text or JSON format pnpm/tasks#174.

• pnpm why now reads each selected workspace project's lockfile and modules directory when sharedWorkspaceLockfile is false pnpm/tasks#169.

• pnpm pkg fix now converts a repository string such as github:pnpm/example to the object form, as npm pkg fix does. It also normalizes a GitHub, GitLab, or Bitbucket repository URL the way npm pkg fix does #​16980.

Configuration and setting up pnpm

• pnpm now recognizes externalDependencies and autoInstallPeersFromHighestMatch in pnpm-workspace.yaml without warning and forwards both settings to pnpm install. Previously, setting externalDependencies in pnpm-workspace.yaml with nodeLinker: hoisted crashed pnpm install with externalDependencies.has is not a function pnpm/tasks#166.

• pnpm now ignores a PNPM_CONFIG_* environment variable for a URL setting, such as PNPM_CONFIG_REGISTRY, when its value is not a URL. Such a value used to make every command fail with Invalid URL.

• The warning about unrecognized settings in pnpm-workspace.yaml and the global config.yaml now names addMissingPeerTypes, autoDedupe, bootConfig, macosBackup, nodePackageMap, permissions, pipelineBase, publishWaitTimeout, python, remoteCache, saveTypes, skills, storeIndexFormat, and tools as pnpm v12 settings pnpm/tasks#167.

• When a config file has a setting pnpm cannot read, pnpm --version now prints the version, and pmOnFail and lockfileDir in pnpm-workspace.yaml stay in force. Previously, pnpm switched to the pinned version despite pmOnFail: ignore. pnpm also no longer writes the pinned version to pnpm-lock.yaml when it cannot read every setting and the running pnpm already matches the pin.

• pnpm now records the pinned pnpm version in the pnpm-lock.yaml under the lockfileDir set in pnpm-workspace.yaml, and resolves a relative lockfileDir from the workspace root. pnpm used to write a second pnpm-lock.yaml at the workspace root.

• pnpm self-update now updates the project's pnpm pin when Homebrew installed pnpm or Corepack runs it. The global pnpm is left alone #​17001.

• pnpm setup now completes when Windows registry environment values cannot be read or written. It prints PowerShell commands to configure PNPM_HOME and PATH without registry access #​17167.

• pnpm setup now succeeds when it cannot tell which shell configuration file to update, for example in a container where SHELL is not set. It installs pnpm and prints the PNPM_HOME and PATH lines to add yourself. Previously it failed with ERR_PNPM_UNKNOWN_SHELL, and so did the installer script at get.pnpm.io #​16973.

Platinum Sponsors

Gold Sponsors

v11.28.6: pnpm 11.28.6

Compare Source

This release stops pnpm publish from sending a CI identity token to a registry it was not issued for. It also fixes installs that dropped a dependency also declared as an optional peer, and accepts empty httpProxy and httpsProxy settings again.

Patch Changes

Security

• pnpm publish now uses an NPM_ID_TOKEN only if its aud claim matches the selected registry, such as npm:registry.npmjs.org. A token for another registry is skipped with a warning, and pnpm falls back to the configured credentials.

• The warning about renamed package files with invalid names no longer prints control characters from those file names.

Configuration

• pnpm again accepts httpProxy and httpsProxy set to null or written with no value in pnpm-workspace.yaml and the global config file, and treats them as unset. Since 11.28.5 these values failed with ERR_PNPM_INVALID_SETTING.

• pnpm now switches to the pnpm version a project pins even when it cannot read its configuration. Previously, a setting it rejected in the global config file, an .npmrc file, _auth, or pnpm-workspace.yaml stopped every command, pnpm --version included.

• A key under a registry URL in the _auth setting that does not start with @ is now skipped with a warning, so a field a later pnpm version adds there no longer breaks this one. A key that holds an authToken object but lacks its @, such as org for @org, is still an error.

Resolving dependencies

• pnpm no longer drops a dependency that a package also declares as an optional peer dependency, for example ajv of ajv-formats. Since 11.28.0, in some dependency graphs the package got the dependency neither as a dependency nor as a peer, and failed to import it #​16901.

• pnpm install no longer fails with ERR_PNPM_NO_MATCHING_VERSION after a change to overrides when the lockfile resolves an optional peer dependency to an npm alias of another package #​16654.

• pnpm install and pnpm dedupe now link an optional peer to the workspace package that the workspace root depends on when the picked version matches it. Previously they installed the registry package with the same name and version #​16706.

• Removal overrides such as "debug>supports-color": "-" now also apply to an optional peer that a package declares only in peerDependenciesMeta #​16681.

• pnpm dedupe now preserves a hoisted workspace package when another package uses a separately installed peer with the same name #​16935.

• pnpm install and pnpm add --config now apply minimumReleaseAge when they resolve a config dependency. A config dependency range resolves to the newest version that is old enough, so a later clean pnpm install --frozen-lockfile accepts the lockfile #​16660.

• pnpm install --fix-lockfile no longer removes the deprecated and hasBin fields from lockfile entries #​6600.

Workspaces and catalogs

• A filtered install, such as pnpm install --filter <pkg>, now keeps the pnpm-lock.yaml entries of workspace projects that are missing from disk, as in a sparse checkout. Their importers, packages, and catalog entries stay even when the filter matches every project on disk #​16931.

• catalogPrune no longer removes catalog entries that pnpm-lock.yaml still records for workspace projects missing from disk. This affected pnpm remove and installs that leave the lockfile unchanged, such as frozen installs. Before, a following frozen install failed with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH #​16679.

• Sped up workspace discovery with subtree exclusions such as !generated/**.

Linking node_modules

• pnpm install no longer fails on Windows with EPERM on rmdir node_modules/@scope when several workspace packages under one scope are hoisted, for example with nodeLinker: hoisted #​16690.

• pnpm install hardlinks files from a group-writable or world-writable store again. Before this fix, pnpm copied every file from such a store into node_modules #​16677.

• With enableGlobalVirtualStore, an install that updates node_modules now restores the dependency links of a package in the global virtual store that an interrupted install left without them. Before, such an install kept the incomplete package if the project's node_modules already recorded it #​16642.

• Removing a link: dependency now also removes its symlink from node_modules when nodeLinker is hoisted #​16884.

• An install that adds nothing to the store no longer changes the modification time of the store directory. CI caches that check modification times, such as GitLab's, no longer re-upload an unchanged store #​16929.

Injected workspace packages

• With sharedWorkspaceLockfile: false, an injected workspace package installed in the same run as its dependent now holds only the files its files field selects. The copy used to also hold other files of the project, such as tsconfig.json #​16683.

• A script listed in syncInjectedDepsAfterScripts no longer fails when it rewrites package.json while pnpm is copying its edits into the injected copies. The sync after the script now replaces a half-copied manifest.

• Sped up frozen installs of unchanged injected workspace packages that use hardlinks.

Deploying

• pnpm deploy without injectWorkspacePackages now binds a peer dependency of a linked workspace package to the version its parent provides, as an injected install does. Previously the deploy failed with ERR_PNPM_DEPLOY_AMBIGUOUS_PEER whenever other packages in the deployed graph depended on different versions of that peer #​16807.

• pnpm deploy in a workspace with injectWorkspacePackages no longer crashes when a linked workspace package declares a peer dependency named after an Object.prototype member, such as constructor.

Setting up pnpm

• pnpm now relinks the bins of a pnpm version it installed earlier for packageManager or pnpm with. A pnpm 12 version installed by a pnpm release older than 11.28.4 could keep a launcher that ran node on the native binary, so every command failed with SyntaxError: Invalid or unexpected token #​16646.

• pnpm setup no longer tries to install pnpm globally from npm's bin directory when pnpm was installed with npm. It printed Failed to create bin at <PNPM_HOME>/bin/pnpm #​16855.

Output

• Escape codes in script output that moved the cursor or cleared the screen garbled pnpm's output. pnpm now drops them and keeps only color codes. Color codes are dropped too when pnpm's own output is not in color.

• When the registry rejects pnpm stage publish, the error message now starts with "Failed to stage package".

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.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/unplugin-lightningcss@39

commit: 0b7d161

[socket-security]

All alerts resolved. Learn more about Socket for GitHub.

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

View full report

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	tsdown-preset-sxzz@​0.6.0 ⏵ 0.7.1	+1
	tsdown@​0.22.13 ⏵ 0.23.2	+1		+1

View full report