Skip to content

fix(deps): update all non-major dependencies - #146

Open
khepri-bot[bot] wants to merge 1 commit into
mainfrom
renovate/all-non-major-dependencies
Open

fix(deps): update all non-major dependencies#146
khepri-bot[bot] wants to merge 1 commit into
mainfrom
renovate/all-non-major-dependencies

Conversation

@khepri-bot

@khepri-bot khepri-bot Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@cloudflare/vite-plugin (source) 1.52.11.53.1 age confidence
@cloudflare/vitest-pool-workers (source) 0.21.30.22.0 age confidence
@sentry/cloudflare (source) 10.70.010.71.0 age confidence
@sentry/solid (source) 10.70.010.71.0 age confidence
@testing-library/user-event 14.6.414.6.6 age confidence
@types/node (source) 26.2.026.3.0 age confidence
daisyui (source) 5.7.175.7.22 age confidence
happy-dom 20.11.220.11.6 age confidence
pnpm (source) 11.22.011.24.0 age confidence
solid-js (source) 1.9.141.9.15 age confidence
vite (source) 8.2.18.2.2 age confidence
vitest (source) 4.1.104.1.11 age confidence
wrangler (source) 4.123.04.125.0 age confidence

Release Notes

cloudflare/workers-sdk (@​cloudflare/vite-plugin)

v1.53.1

Compare Source

Patch Changes

v1.53.0

Compare Source

Minor Changes
  • #​15026 6529f0c Thanks @​petebacondarwin! - Allow containers to be attached to a Durable Object from its exports entry

    A container can now be linked to its Durable Object from the export side, using a new container field that names an entry in the containers array. As a result containers[].class_name is now optional — a container that is referenced this way only needs a name:

    {
      "name": "my-worker",
      "main": "worker.js",
      "compatibility_date": "2026-07-01",
      "containers": [
        { "name": "my-container", "image": "./Dockerfile", "max_instances": 1 }
      ],
      "exports": {
        "MyContainerDO": {
          "type": "durable-object",
          "storage": "sqlite",
          "container": "my-container"
        }
      }
    }

    The existing containers[].class_name direction keeps working and either direction may be used, but the two must agree: a container that names its Durable Object cannot also be claimed by a different one.

    container is only valid on live durable-object exports (created and expecting-transfer) and requires storage: "sqlite". Wrangler now also reports an error when:

    • a container reference names a container that does not exist
    • two Durable Object exports claim the same container
    • a container and a Durable Object export disagree about which one they are linked to
    • a container ends up linked to no Durable Object at all
    • two containers share a name
    • a container's class_name names a Durable Object whose storage is legacy-kv
    • two containers are attached to the same Durable Object

    That last case was previously accepted but could never work: workerd attaches a single container per Durable Object namespace, and in local development every container for a class builds into the same image tag, so one silently overwrote the other. If you have two containers on one class_name, give each its own Durable Object class.

Patch Changes
  • #​15238 3a4fc6b Thanks @​jamesopstad! - Honor access.dev when running Workers with @cloudflare/vite-plugin, so ctx.access.getIdentity() returns the configured identity.

  • #​15028 d4f441f Thanks @​harshmathurx! - Handle Worker-side request body cancellation without surfacing stream controller errors in local dev.

  • #​15185 1f79ace Thanks @​jamesopstad! - Use a fixed default compatibility date rather than the current date

    When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

    The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.

  • #​15239 f431166 Thanks @​jamesopstad! - Prevent date-enabled Node.js compatibility from adding conflicting globals to generated runtime types

    Runtime type generation now treats Node.js compatibility enabled by a compatibility date the same way as an explicit nodejs_compat flag. Node.js globals continue to come from @types/node instead of being generated as any declarations that override those types.

  • #​15196 8fb2b87 Thanks @​skepticfx! - Use the FedRAMP High managed container registry when Wrangler targets the FedRAMP High compliance region

    Container builds, pushes, deployments, image commands, and local development now select the corresponding production or staging FedRAMP registry and API from either compliance_region or CLOUDFLARE_COMPLIANCE_REGION.

  • Updated dependencies [bc5726b, 1277a72, ba54f0d, 6529f0c, b7422b0, 186339c, 4f922dc, 4d74b8d, 2e0c962, 1f79ace, 49f73de, 7cee278, 8777180, 265256a, 1f79ace, f431166, 8fb2b87, 75cf407]:

cloudflare/workers-sdk (@​cloudflare/vitest-pool-workers)

v0.22.0

Compare Source

Minor Changes
  • #​13830 49d4e00 Thanks @​penalosa! - Mocking requests with MSW in Worker tests now requires MSW >= 2.14

    @cloudflare/vitest-pool-workers previously shipped internal shims to make MSW work inside the workerd runtime. MSW 2.14 added that support natively, so those shims have been removed.

    If you mock requests with MSW in your Worker tests, make sure you're on MSW >= 2.14; older versions will no longer intercept requests. You can keep using setupServer() from msw/node, or adopt the official @msw/cloudflare integration via setupNetwork(). See the updated request-mocking example fixture for the recommended pattern.

Patch Changes
  • #​15211 bc5726b Thanks @​nithin42! - Honor access.dev when running Workers with @cloudflare/vitest-pool-workers, so ctx.access.getIdentity() returns the configured identity just as it does with wrangler dev.

  • #​15156 3ddd3ce Thanks @​dario-piotrowicz! - Fix module resolution for relative require() inside CJS deps when the project path contains spaces

    When a project lives under a directory with a space in its name, externalized CommonJS dependencies that use relative require() calls (e.g. require("./lib/impl.js")) would fail with "No such module" because workerd preserves URL encoding in the module name. Encoded module paths are now handled deterministically before CommonJS resolution without altering literal percent sequences.

  • #​15150 2cf3143 Thanks @​kkkhs! - Restore typed inject() keys in cloudflareTest() pool options

    inject() inside cloudflareTest() options again infers the value type from the keys you declare in your Vitest ProvidedContext, and reports misspelled keys. For keys that are only provided at runtime, pass an explicit type argument, e.g. inject<number>("myPort").

  • #​15232 8777180 Thanks @​vicb! - Bump capnp-es to 0.0.16.

  • #​15185 1f79ace Thanks @​jamesopstad! - Use a fixed default compatibility date rather than the current date

    When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

    The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.

  • Updated dependencies [bc5726b, 1277a72, ba54f0d, 6529f0c, b7422b0, 186339c, 4f922dc, 4d74b8d, 2e0c962, 1f79ace, 49f73de, 7cee278, 8777180, 265256a, 1f79ace, f431166, 8fb2b87, 75cf407]:

getsentry/sentry-javascript (@​sentry/cloudflare)

v10.71.0

Compare Source

Important Changes
  • feat(v10/core)!: Enable logs by default (#​23311)

The enableLogs client option now defaults to true, so Sentry Logs work without any manual opt-in. Nothing is captured unless you call the Sentry.logger.* APIs or add a log-forwarding integration (such as consoleLoggingIntegration, pinoIntegration, or the winston transport), and you can set enableLogs: false to opt out. Although a default change like this would normally land in a major release, we are shipping it in a minor after careful consideration, since it sends no data on its own and only takes effect once you actively use the logging APIs or a logging integration.

Other Changes
  • feat(v10/core): Deprecate scope.clear() method (#​23231)
  • fix(v10/core): Bound child span tracking on long-lived spans (#​23406)
  • fix(v10/core): Read Supabase PostgREST headers from Headers instances (#​23241)
  • fix(v10/hono): Use captureException from scope, not from Client (#​23280)
  • fix(v10/nuxt): Delete source maps after Nitro finishes building (#​23508)
  • fix(v10/react-router): Carry multi-byte UTF-8 across SSR stream chunk boundaries (#​23421)
  • fix(v10/react): Match TanStack Router pageload against the router location (#​23494)
Internal Changes
  • test(v10/nextjs): Add e2e app for a user-owned OpenTelemetry setup (#​23278)
Bundle size 📦
Path Size
@​sentry/browser 27.1 KB
@​sentry/browser - with treeshaking flags 25.58 KB
@​sentry/browser (incl. Tracing) 45.51 KB
@​sentry/browser (incl. Tracing + Span Streaming) 47.25 KB
@​sentry/browser (incl. Tracing, Profiling) 50.15 KB
@​sentry/browser (incl. Tracing, Replay) 83.83 KB
@​sentry/browser (incl. Tracing, Replay) - with treeshaking flags 73.71 KB
@​sentry/browser (incl. Tracing, Replay with Canvas) 88.45 KB
@​sentry/browser (incl. Tracing, Replay, Feedback) 100.79 KB
@​sentry/browser (incl. Feedback) 43.87 KB
@​sentry/browser (incl. sendFeedback) 31.78 KB
@​sentry/browser (incl. FeedbackAsync) 36.79 KB
@​sentry/browser (incl. Metrics) 28.16 KB
@​sentry/browser (incl. Logs) 28.38 KB
@​sentry/browser (incl. Metrics & Logs) 29.06 KB
@​sentry/react 28.86 KB
@​sentry/react (incl. Tracing) 47.72 KB
@​sentry/vue 32.4 KB
@​sentry/vue (incl. Tracing) 47.43 KB
@​sentry/svelte 27.12 KB
CDN Bundle 29.43 KB
CDN Bundle (incl. Tracing) 47.43 KB
CDN Bundle (incl. Logs, Metrics) 30.98 KB
CDN Bundle (incl. Tracing, Logs, Metrics) 48.7 KB
CDN Bundle (incl. Replay, Logs, Metrics) 69.32 KB
CDN Bundle (incl. Tracing, Replay) 84.05 KB
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) 85.33 KB
CDN Bundle (incl. Tracing, Replay, Feedback) 89.72 KB
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) 90.96 KB
CDN Bundle - uncompressed 87.76 KB
CDN Bundle (incl. Tracing) - uncompressed 143.35 KB
CDN Bundle (incl. Logs, Metrics) - uncompressed 92.36 KB
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed 147.24 KB
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed 214.2 KB
CDN Bundle (incl. Tracing, Replay) - uncompressed 259.79 KB
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed 263.67 KB
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed 273.17 KB
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed 277.04 KB
@​sentry/nextjs (client) 50.2 KB
@​sentry/sveltekit (client) 45.92 KB
@​sentry/core/server 78.73 KB
@​sentry/core/browser 65.27 KB
@​sentry/node-core 61.77 KB
@​sentry/node 122.94 KB
@​sentry/node (incl. diagnostics channel injection) 147.78 KB
@​sentry/node/import (ESM hook with diagnostics-channel injection) 68.39 KB
@​sentry/node/light 50.21 KB
@​sentry/node - without tracing 73.19 KB
@​sentry/aws-serverless 82.24 KB
@​sentry/cloudflare (withSentry) - minified 197.31 KB
@​sentry/cloudflare (withSentry) 485.11 KB
testing-library/user-event (@​testing-library/user-event)

v14.6.6

Compare Source

Bug Fixes
  • default pointer event pointerType to empty string instead of the string "undefined" (#​1325) (71a5475)

v14.6.5

Compare Source

Bug Fixes
saadeghi/daisyui (daisyui)

v5.7.22

Compare Source

Bug Fixes

v5.7.21

Compare Source

Bug Fixes

v5.7.20

Compare Source

Bug Fixes
  • text-rotate - selector targets direct children, to avoid style leaking (#​4682) (44856dc)

v5.7.19

Compare Source

Bug Fixes

v5.7.18

Compare Source

Bug Fixes
  • don't force dock layout onto script/style/template children (#​4679) (b5a1209)
capricorn86/happy-dom (happy-dom)

v20.11.6

Compare Source

👷‍♂️ Patch fixes

v20.11.5

Compare Source

👷‍♂️ Patch fixes
  • Allow explicit element types for querySelector (e.g. querySelector<HTMLInputElement>(".my-input")) - By @​cyphercodes

v20.11.4

Compare Source

👷‍♂️ Patch fixes
  • Fixes the CORS check fetch() to match origins instead of host and protocol - By @​rexxars in task #​1490

v20.11.3

Compare Source

👷‍♂️ Patch fixes
pnpm/pnpm (pnpm)

v11.24.0: pnpm 11.24

Compare Source

Minor Changes
Patch Changes
  • Fixed pnpm v11 incorrectly reporting confirmModulesPurge as unrecognized when set in pnpm-workspace.yaml. The Rust CLI now identifies the unsupported option as a pnpm v11 setting instead of suggesting an unrelated setting.

  • pnpm install --frozen-lockfile no longer fails with ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE when the pinned pnpm version recorded in pnpm-lock.yaml has to be re-resolved before it can be installed. It runs the pnpm version the lockfile pins and leaves the lockfile unchanged #​14124.

  • Under nodeLinker: hoisted, peer-resolution variants of an injected directory dependency (a file: snapshot) are materialized as separate copies again instead of collapsing onto the first-seen variant. Each copy keeps its own peer-resolved dependency set, so a project pinning one peer version no longer resolves another project's variant — Bit root components with conflicting peers across injected copies rely on this.

  • Fixed pnpm install --merge-git-branch-lockfiles --frozen-lockfile failing with ERR_PNPM_OUTDATED_LOCKFILE when a branch lockfile predates the removal of a dependency, or its move to another dependency group #​13966. A dependency that no project declares anymore is no longer reinstated by the merge, and the packages it was the only path to are dropped with it.

  • Batch workspace publishing accepts a shared scope-specific credential, rejects mismatched credentials for a registry before publishing, and runs the publish and postpublish scripts after each completed registry group pnpm/pnpm#14101.

  • The Rust CLI now honors five settings it recognized but ignored: updateNotifier, legacyDirFiltering, initAuthorName / initAuthorEmail / initAuthorUrl, initLicense, and initVersion. pnpm install and pnpm add check once a day for a newer pnpm and print how to get it (turn it off with updateNotifier: false); a {<dir>} filter selector can go back to matching the subtree below the directory with legacyDirFiltering: true; and pnpm init writes the configured author, license, and version into the package.json it scaffolds. PNPM_CONFIG_INIT_VERSION is now read as well.

    maxsockets, npm's spelling of maxSockets, is no longer ignored: both spellings are read from pnpm-workspace.yaml, the global config file, the environment, and the command line, in that increasing order of precedence — a value passed on the command line now wins even when the two sides spelled the setting differently.

    A lastUpdateCheck timestamp dated in the future — after a clock change, a restored snapshot, or a hand-edited state file — no longer silences the update check until that time comes around.

    legacyDirFiltering no longer reaches the workspace-root selectors pnpm generates for itself: the !{<workspace-root>} exclusion a recursive run / exec / add / test appends, and the {<workspace-root>} inclusion --workspace-root appends. Read as subtree matches they named every project below the root, so a recursive command under the setting selected nothing at all, and --workspace-root pulled in every project below the root instead of the root alone #​14101.

  • pnpm install --frozen-lockfile no longer fails when pnpm-lock.yaml records the pinned pnpm version alongside an engine package the running pnpm does not install it from. An entry pinning another version is still refused, and a plain install rewrites the block #​14124.

v11.23.0: pnpm 11.23

Compare Source

Minor Changes

  • pnpm config get and pnpm config list now show the settings pnpm acts on under their documented names:

    • registries shows the registries pnpm resolves from, merged across every source (.npmrc, pnpm-workspace.yaml, the global config, CLI flags), in the shape the setting is written in: keyed by registry URL, with the default registry declared as the bare @ scope. Built-in routes are included — the @jsr scope and the npmjs and gh prefixes — unless pointed elsewhere. Previously pnpm config get registries printed undefined.
    • update and audit show the effective sections, whichever spelling set them. The deprecated internal spellings (updateConfig, auditConfig, auditLevel) are no longer listed.
    • catalogs shows the complete resolved catalog set — the singular catalog block is its default entry — whichever spelling declared it.
    • The registry and @scope:registry entries show the merged routes rather than raw .npmrc values, so they always agree with the registries view.
  • Settings that no supported pnpm version recognizes get their own warning. A key in the global config file that this version of pnpm does not read is no longer reported with advice to move it to a project-level pnpm-workspace.yaml (where it would be ignored too); the warning now says the setting is not recognized by this version of pnpm, names the pnpm version that does read it when there is one (for example, globalShims is a pnpm v12 setting), and suggests the closest real setting name when the key looks like a typo. Unrecognized and non-camelCase keys in a project's pnpm-workspace.yaml, previously ignored silently, are now reported the same way. pnpm config get <key> and pnpm get <key> no longer print config-load warnings, so a script capturing the value gets the value alone.

  • The importPackage pnpmfile hook is deprecated. pnpm now prints a warning when a pnpmfile defines it, and the hook will be removed in the next major version. It also opts the installation out of the parallel package importer, making installation slower. If you rely on this hook, comment on #​14101.

  • node_modules/.modules.yaml no longer records the registries an install resolved from, and the recorded copy is dropped from the file on the first install that rewrites it.

    It dated from the lockfile format that spelled a dependency's path relative to its registry, where reading an installed tree meant knowing the registries it was installed with. Dependency paths have not carried a registry for several major versions, and the recorded copy outlived its use: pnpm list, pnpm why, and single-project installs preferred it over the project's own configuration, so a project whose registry had changed since its last install was still read through the old one.

    They now use the configured registries, like every other command already did.

  • When enableGlobalVirtualStore is on, every process pnpm spawns for the project (pnpm run, pnpm exec, lifecycle scripts) now receives a NODE_PATH pointing at the project's hoisted node_modules, plus a NODE_OPTIONS --import flag that registers a resolve hook restoring NODE_PATH lookups for ESM imports. Dependencies that import undeclared ("phantom") packages keep resolving under the global virtual store — for both CommonJS and ESM — without installing the @pnpm/plugin-esm-node-path config dependency pnpm/pnpm#9618. Tools run by pnpm dlx resolve such dependencies too: the JS CLI passes them the same environment, while the Rust CLI's dlx cache is self-contained, so its layout already exposes them.

  • A registry can now declare that its abbreviated metadata carries the time field, so resolutionMode: time-based reads the full metadata document only from the registries that need it:

    resolutionMode: time-based
    registries:
      https://npm.internal.example/:
        supportsTimeField: true

    registry.npmjs.org omits time from abbreviated metadata, so a time-based resolution has to fall back to the much larger full document. That fallback used to be all-or-nothing: registrySupportsTimeField answered for every registry at once, so a project resolving from both the public registry and a Verdaccio instance either paid for full metadata everywhere or claimed a time field npmjs does not serve. The answer is now per registry, and registrySupportsTimeField remains the answer for every registry that does not declare one.

    The declaration is also sent to a pnpr server, which applies it to the resolution it runs on the client's behalf.

  • A pnpr resolve request now carries the client's registries the way the registries setting declares them — keyed by URL, with the scopes routed to each, the bare-specifier prefix each answers to, and each one's serverType — in place of the prefix map it used to send.

    The server routes them through the same inversion the config reader runs, so a pnpr-served install resolves a scoped dependency from the registry that scope is routed to, which it previously could not: only the default registry and the prefix-addressed ones reached the server. A declared serverType reaches it too, so the tarball URLs pnpr omits from the lockfile match the ones the client reconstructs.

    Built-in scope routes the project has not pointed elsewhere are not declared, so a pnpr server's allowlist is not asked about npm.jsr.io on requests that resolve no JSR package.

    A registry a request only declares is no longer refused up front for being off the server's allowlist — a client describes its whole configuration, including scopes a given resolve never reaches, so a stray @scope:registry in a developer's ~/.npmrc no longer fails every install against a pnpr server that does not serve it. The boundary moves to the fetch itself: an origin the resolve does reach is refused before the request leaves the server, with the same message.

    This changes the resolve and verify-lockfile request bodies. A pnpr server and its clients have to be on matching versions; the protocol is still experimental and unversioned.

  • The registries setting now declares a registry once, keyed by its URL, with everything about that registry in the entry: how it lays out tarball URLs, the scopes routed to it, and the bare-specifier prefix it answers to.

    registries:
      https://artifactory.example.com/artifactory/api/npm/npm-virtual/:
        serverType: artifactory
        scopes: ['@acme', '@acme-internal']
        prefix: work
    • serverType tells pnpm how the registry lays out its tarball URLs, which decides whether a URL can be omitted from pnpm-lock.yaml:
      • undeclared (the default) — strict. Only the exact canonical URL is treated as reconstructible.
      • npm — the registry behaves like registry.npmjs.org, which also serves a scoped package from its percent-encoded path. Declare this for a faithful mirror or caching proxy of the public registry so its tarball URLs can be omitted too.
      • artifactory — JFrog Artifactory repeats the scope in a scoped package's tarball filename (@acme/widget/-/@acme/widget-1.0.0.tgz) where the npm registry strips it (@acme/widget/-/widget-1.0.0.tgz). Declaring it lets pnpm rebuild that URL, so it is omitted from pnpm-lock.yaml instead of being written out for every scoped package pnpm/get-npm-tarball-url#16.
    • scopes lists the @-prefixed scopes that resolve from this registry. A bare '@' is the scope-less default registry, the one the registry setting names.
    • prefix is the alias a dependency addresses this registry by, as in "foo": "work:^1.0.0".

    The layout is never inferred from the registry URL, so nothing changes unless you declare it; registry.npmjs.org continues to behave as npm without being declared. Because the lockfile depends on serverType, it is read from pnpm-workspace.yaml only — a serverType in the global config.yaml is ignored, so one developer's machine cannot shape a lockfile their collaborators read back with a different layout. Credentials are rejected in this setting, in a key as well as in a field, and still belong in .npmrc. An entry that routes nothing to itself and matches no configured registry is reported as a warning rather than silently ignored.

Migrating

The older registries shape, a map of <scope>: <url> strings, still works and needs no change:

registries:
  '@acme': https://npm.acme.example/

namedRegistries is deprecated in favor of the prefix field, and is still read for prefixes registries does not declare.

toLockfileResolution and isCanonicalRegistryTarballUrl now take their registry and layout as an options object rather than positional arguments, so @pnpm/lockfile.utils and @pnpm/resolving.tarball-url get a major bump.

  • An install that had to re-hash store files to verify them now reports it. If that cost more than a second, it says how long — The integrity of N files was checked in 2.5s. — and if it was quick but covered more than a thousand files, it names the cause instead: their timestamps changed since the store recorded them, which a backup tool, an antivirus scan or a copied store can do.

  • Added virtualStoreType, which names where the virtual store lives — one store per machine, or one per project:

    virtualStoreType: global   # or: project

    It is the canonical spelling of enableGlobalVirtualStore, which keeps working. When a project sets both, virtualStoreType wins. It can also be set through PNPM_CONFIG_VIRTUAL_STORE_TYPE and read back with pnpm config get virtualStoreType. The default is unchanged — project, so the shared store stays opt-in.

    The setting is independent of nodeLinker. isolated and pnp both work with either store type, and hoisted writes no virtual store at all, so it is unaffected.

Patch Changes

  • pnpm add --allow-build now adds to the allowBuilds entries already in pnpm-workspace.yaml instead of replacing them #​13872.

  • Kept pending build approvals available after removing an unrelated dependency.

  • pnpm approve-builds now removes onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, and ignoredBuiltDependencies from pnpm-workspace.yaml when it writes allowBuilds. Those settings were replaced by allowBuilds in pnpm 11 and silently ignored since, so a workspace migrated from pnpm 10 kept them around looking active.

  • pnpm audit no longer reports a patched version that was never published or is deprecated. The inferred patched range (e.g. >=4.17.24 from <=4.17.23) is now checked against the registry packument, and the report is corrected to the lowest non-deprecated published version that satisfies it (e.g. >=4.18.1 when 4.17.24 does not exist and 4.18.0 is deprecated). When no published version satisfies the range, the report shows Patched versions: None. This also prevents pnpm audit --fix from adding overrides or minimumReleaseAgeExclude entries for patches that do not exist #​13824.

    pnpm audit --fix and pnpm audit --fix update no longer add a minimumReleaseAgeExclude entry when the registry packument shows that the minimum patched version was never published. Previously such entries were written for versions that do not exist, which would have let a later publish of that version bypass the minimumReleaseAge gate #​11563.

    The --json output of pnpm audit now returns patched_versions: null for advisories whose inferred patch is not available (never published, skipped, yanked, or deprecated), making it easier for tooling to distinguish "no fix available" from "fix available at version X".

  • Fixed pnpm patch-commit in project and edit paths containing non-ASCII characters.

  • The package and bump pickers of pnpm change now size their page from the terminal height instead of always showing 7 rows. They fall back to 7 rows when the terminal height is unknown pnpm/pnpm#13815.

  • Canceling a pnpm change prompt with Ctrl-c no longer prints a stack trace. It reports Change canceled and exits with a success status, like the other interactive commands #​13814.

  • Re-fetch full registry metadata when minimumReleaseAge is enabled and an abbreviated packument's time map omits timestamps for some versions. This prevents mature versions from being filtered out and resolution from falling back to the lowest matching version pnpm/pnpm#13741.

  • A config dependency carrying an inline integrity (the <version>+<integrity> form, or the object form without a tarball) now takes its tarball URL from the registry's packument instead of deriving it from the registry URL, so migrating one costs an extra metadata request. On a registry that serves tarballs from a path pnpm cannot derive, GitLab's group endpoint for one, installing such a config dependency failed with a 404 while the same package installed fine as a regular dependency #​13765.

  • Fixed PNPM_CONFIG_NODE_VERSION being ignored when setting the Node.js version used for compatibility checks.

  • A custom fetcher can no longer replace the archive integrity that pnpm-lock.yaml pins: the locked value is restored after a canFetch or fetch hook rewrites the resolution, and delegating a locked archive to a directory or git source now fails instead of installing unverified content.

    The Rust CLI now also loads the pnpmfiles named by the pnpmfile setting (a single path or an ordered list), and hands custom fetchers native localTarball and remoteTarball callbacks — including on a fresh install that has to compute a missing tarball integrity, which is then reused by later offline installs. File maps a fetcher returns are accepted only when they match what those native callbacks extracted.

  • Fixed an issue where running pnpm dedupe --check in projects with nodeLinker: hoisted would cause dependencies to be moved out of node_modules into node_modules/.ignored.

  • pnpm deploy --prod and pnpm deploy --no-optional no longer list the excluded dependency groups in the deployed package.json and pnpm-lock.yaml. The deployed lockfile referenced packages that the deploy left out of its graph, so installing in the deploy directory afterwards created dangling symlinks #​13623.

  • Don't treat files like license16.json as a package license when deciding if the workspace LICENSE file should be included in the packed package.

  • pnpm exec --recursive --no-reporter-hide-prefix no longer prints a blank prefixed line after each chunk of a command's output, and no longer splits a line in two when it straddles a chunk boundary.

  • Fixed 404 errors when installing from a registry that serves scoped packages only from a percent-encoded path, such as GitHub Enterprise Server. Outside registry.npmjs.org, a tarball URL that encodes the scope separator as %2f or %2F is no longer mistaken for one that pnpm can rebuild from the package name, version, and registry, so it is kept in pnpm-lock.yaml and requested verbatim on the next install #​13534.

  • Fixed trustPolicyExclude and minimumReleaseAgeExclude being ignored when set to a single

Note

PR body was truncated to here.


Configuration

📅 Schedule: (in timezone America/New_York)

  • Branch creation
    • Between 12:00 AM and 08:59 AM, only on Monday (* 0-8 * * 1)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR is behind base branch, 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

This PR has been generated by Mend Renovate CLI.

@khepri-bot
khepri-bot Bot requested a review from a team September 7, 2026 04:55
@khepri-bot khepri-bot Bot added the renovate label Sep 7, 2026
@khepri-bot
khepri-bot Bot force-pushed the renovate/all-non-major-dependencies branch 2 times, most recently from 6810dce to cf96dd6 Compare September 7, 2026 19:16
@khepri-bot
khepri-bot Bot force-pushed the renovate/all-non-major-dependencies branch from cf96dd6 to 8cdc9f9 Compare September 7, 2026 23:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants