Script 'mail_helper' called by obssrc Hello community, here is the log from the commit of package pnpm for openSUSE:Factory checked in at 2026-11-07 23:32:15 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/pnpm (Old) and /work/SRC/openSUSE:Factory/.pnpm.new.3759290 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "pnpm" Sat Nov 7 23:32:15 2026 rev:61 rq:1395937 version:11.28.11 Changes: -------- --- /work/SRC/openSUSE:Factory/pnpm/pnpm.changes 2026-07-03 16:08:07.175945582 +0200 +++ /work/SRC/openSUSE:Factory/.pnpm.new.3759290/pnpm.changes 2026-11-07 23:32:28.541206607 +0100 @@ -1,0 +2,5202 @@ +Fri Nov 6 09:48:28 UTC 2026 - Johannes Kastl <[email protected]> + +- update to 11.28.11: + pnpm 11.28.11 fixes frozen installs with + excludeLinksFromLockfile, pnpm link in workspaces, pnpm deploy + with dangling symlinks, and verifyDepsBeforeRun starting needless + installs. + * Patch Changes + - Installing packages + - pnpm deploy now keeps a symlink in the project whose target + is missing from the source, such as a link into a + node_modules directory that was removed after the build. + Deploy used to fail with ENOENT on such a link #17571. + - A package with bundledDependencies and a build script now + keeps its bundled dependencies when it is restored from the + side-effects cache #17523. + - pnpm install now links the runtime that an earlier pnpm + install --no-runtime skipped #17542. + - Commands of a package whose bin paths contain excess parent + directory segments, such as ../dist/cli.js, are no longer + missing. Such paths now resolve inside the package #17586. + - Generated POSIX shell shims now quote their paths, so shell + special characters in a path stay literal. + - A repeat pnpm install now rewrites the bin shims after + extendNodePath changes. Before, it reported "Already up to + date" and the shims kept the NODE_PATH of the previous + setting. + - Lockfile and resolution + - pnpm install --frozen-lockfile now accepts the lockfile it + wrote with excludeLinksFromLockfile and + linkWorkspacePackages on, when a project depends on a + workspace package through a plain version range or a + catalog: entry. It used to fail with + ERR_PNPM_OUTDATED_LOCKFILE. + - pnpm install --frozen-lockfile, pnpm approve-builds, and + pnpm rebuild now accept a lockfile that resolves a * + dependency to a prerelease latest version. pnpm wrote such + a lockfile and then reported it as outdated #17594. + - Packages from the default registry keep plain lockfile + keys, even when a prefix such as npmjs points at the + registry set as registry. A dependency written with such a + prefix shares the plain entry of the same package. The next + install rewrites keys that earlier versions qualified this + way #17575. + - Relative local paths in root overrides now resolve from the + workspace root when each project has its own lockfile + #17691. + - Installing a local directory dependency no longer fails + when another project's install is writing a lockfile in + that directory. + - Peer deduplication no longer gives a project different + copies of a dependency across direct and transitive paths + when an optional peer has no provider #17666. + - A Node.js version range such as >=26.13, for example in + devEngines.runtime, now resolves to the newest stable + release that satisfies it. pnpm picks a prerelease only + when no stable release matches #17516. + - verifyDepsBeforeRun + - With verifyDepsBeforeRun, pnpm run and pnpm exec now report + dependencies as out of date after a dependency is added to + the package.json of a local directory dependency, such as + "lib": "file:../lib". Before, the command ran without the + new dependency installed. + - verifyDepsBeforeRun no longer reports dependencies as out + of sync when only the version field of a single-project + repository changed #17560. The same holds for a workspace + project that no dependency can resolve to. A script run + after such a change no longer starts an install first. + - pnpm link + - In a workspace, pnpm link <dir> now adds the link: + dependency to the package.json of the project where the + command runs, not to the workspace root's package.json. The + link is created in that project's node_modules, as + documented. The override is still written to the root + pnpm-workspace.yaml. + - pnpm link with several paths now records every linked + package in the overrides of pnpm-workspace.yaml. Some of + them could be missing before. + - pnpm link now fails without changing package.json or + pnpm-workspace.yaml when the linked package's name is not a + valid npm package name. It used to write that name to both + files, which made every later install fail #17475. + pnpm - update + - pnpm update with only negated selectors, such as pnpm + update '!foo', now leaves the dependencies listed in + update.ignoreDeps unchanged pnpm/tasks#243. + - pnpm update --depth 0 without selectors now does nothing + when every direct dependency is listed in + update.ignoreDeps. Before, it failed with + ERR_PNPM_NO_PACKAGE_IN_DEPENDENCIES pnpm/tasks#251. + - Store and self-update + - pnpm store prune now keeps packages linked from a + configured modules directory pnpm/tasks#230. + - pnpm store status no longer reports untouched packages as + modified when the global virtual store is enabled. If the + installed global-store layout cannot be verified, the + command reports ERR_PNPM_STORE_STATUS_UNVERIFIABLE and asks + for a reinstall #17631. + - pnpm store add now fails right away with + ERR_PNPM_FROZEN_STORE_WRITE when frozenStore is enabled. It + used to retry each download for minutes before failing, or + fail with a SQLite error on an empty store. + - pnpm self-update now reinstalls a cached engine if its + executable cannot run. This repairs shared store entries + damaged by an earlier install #17582. +- update to 11.28.10: + pnpm 11.28.10 stops pnpm store prune from deleting other stores + when cacheDir points to their parent directory. It also fixes + globally installed commands that load hoisted dependencies, and + repeat installs that missed changes to local dependencies. + * Patch Changes + - Installing packages + - pnpm store prune preserves other stores and global package + data when cacheDir points to their parent directory. + - Commands installed with pnpm add --global now find the + dependencies that pnpm hoists for their package. A package + that loads a dependency it does not declare, such as a + native addon's platform-specific package, failed with + "Cannot find module". Reinstall such a package with pnpm + add --global to update its existing command #17503. + - pnpm prune --prod no longer fails with ERR_PNPM_EXDEV when + node_modules was copied from an earlier Docker build stage + #17424. + - pnpm install now retries a Node.js runtime zip download + when the connection drops partway through. A download that + still fails names its URL. Before, a single dropped + connection ended the install with terminated #17411. + - With the global virtual store, a change to a dependency of + one package in a dependency cycle now gives every package + in that cycle a new directory. Before, the other packages + kept their directories and still linked the old copy of the + changed package, so the project could load two copies of it + #17466. + Packages in a dependency cycle, and packages that depend on + one, move to new global virtual store directories once + after this update. Those that run a build miss the + side-effects cache once. + - pnpm install and pnpm rebuild now refresh privately hoisted + .bin shims in node_modules/.pnpm/node_modules/.bin after a + dependency build replaces a script target with a native + executable #17402. + - The Node.js latest selector now chooses the newest stable + release #17490. + - The standalone @pnpm/exe builds now embed Node.js 26.13.0. + - Repeat installs and lockfiles + - pnpm install now resolves a local directory again after its + package.json changes when an override or a package + extension adds it to the dependencies of a registry + package. pnpm install --frozen-lockfile fails on a lockfile + that still records the old dependencies of such a directory + #17486. + - With injectWorkspacePackages and per-project lockfiles, + pnpm install now updates a project's lockfile when a local + tarball that an injected workspace project depends on is + replaced. The project's lockfile kept the old version and + integrity before. + - pnpm install now detects a change to a local tarball or + directory that only a pnpmfile readPackage hook depends on. + A repeat install reported "Already up to date" and kept the + old contents before pnpm/tasks#227. + - pnpm install now relinks a workspace: or link: dependency + whose link was deleted from node_modules. It used to report + "Already up to date" and leave the link missing #17485. + - Merging git branch lockfiles now keeps a workspace project + whose directory is named __proto__. It was dropped from the + merged lockfile before pnpm/tasks#59. + - Adding and publishing packages + - pnpm add no longer rewrites a catalog entry set to the + dist-tag that the dependency resolves through. For example, + an entry beta stays beta after pnpm add foo@beta or pnpm + add foo. Before, the entry was replaced with the version + the tag pointed to pnpm/tasks#225. + - pnpm pack and pnpm publish now always include the binary + file declared by a string bin field in package.json, even + when files or .npmignore would otherwise exclude it. + - When the version or range given to pnpm unpublish matches + every published version, the error now says so and shows + the same command with --force. It suggested running pnpm + unpublish <pkg>@<version>, the command that had just + failed. + - Running commands + - Every command, including pnpm --version, pnpm self-update, + and invocations with unknown flags, now applies the same + packageManager and devEngines.packageManager settings when + switching to the pinned pnpm version or recording it in + pnpm-lock.yaml. --config.<key> flags and lockfileDir now + reach the version switch and lockfile sync on every entry + point. Unreadable settings in pnpm-workspace.yaml or the + global config.yaml that do not affect the pin decision no + longer block the version switch pnpm/tasks#222. + - pnx and pnpm create now run the command in the directory + selected by --dir or --workspace-root. Without either flag, + the command still runs in the directory pnpm was started + in. + - The error for a dependency with an invalid name in a + project's manifest now names the project's directory. It + used to say only "The current package", which did not tell + which workspace project to fix #17475. +- update to 11.28.9: + 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, ++++ 4905 more lines (skipped) ++++ between /work/SRC/openSUSE:Factory/pnpm/pnpm.changes ++++ and /work/SRC/openSUSE:Factory/.pnpm.new.3759290/pnpm.changes Old: ---- pnpm-11.9.0.tgz New: ---- pnpm-11.28.11.tgz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ pnpm.spec ++++++ --- /var/tmp/diff_new_pack.0JbIRr/_old 2026-11-07 23:32:29.447244044 +0100 +++ /var/tmp/diff_new_pack.0JbIRr/_new 2026-11-07 23:32:29.449244126 +0100 @@ -23,7 +23,7 @@ %global __nodejs_provides %{nil} %global __nodejs_requires %{nil} Name: pnpm -Version: 11.9.0 +Version: 11.28.11 Release: 0 Summary: Package manager for node.js License: MIT ++++++ _scmsync.obsinfo ++++++ --- /var/tmp/diff_new_pack.0JbIRr/_old 2026-11-07 23:32:29.490245821 +0100 +++ /var/tmp/diff_new_pack.0JbIRr/_new 2026-11-07 23:32:29.493245945 +0100 @@ -1,6 +1,6 @@ -mtime: 1782658772 -commit: be4992ed368e74d0bbb22a50ffd090451a9801e7dc73f848da63eedbad04100c +mtime: 1793964372 +commit: 47e7bc63f4951a54e0520dcca2890654c8174598491d7a0fcd70b2e34043987e url: https://src.opensuse.org/nodejs/pnpm -revision: be4992ed368e74d0bbb22a50ffd090451a9801e7dc73f848da63eedbad04100c +revision: 47e7bc63f4951a54e0520dcca2890654c8174598491d7a0fcd70b2e34043987e projectscmsync: https://src.opensuse.org/nodejs/_ObsPrj.git ++++++ build.specials.obscpio ++++++ ++++++ build.specials.obscpio ++++++ diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/.gitignore new/.gitignore --- old/.gitignore 1970-01-01 01:00:00.000000000 +0100 +++ new/.gitignore 2026-11-06 12:26:12.000000000 +0100 @@ -0,0 +1 @@ +.osc ++++++ pnpm-11.9.0.tgz -> pnpm-11.28.11.tgz ++++++ ++++ 602607 lines of diff (skipped)
