fix(deps): update all non-major dependencies#82
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
renovate
Bot
force-pushed
the
renovate/all-minor-patch
branch
from
a010586 to
f9b15be
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@package.json`:
- Line 28: Add an explicit engines field to the package.json file at the root
level to declare the supported Node.js version range. Set the engines.node
property to match the Node version constraints enforced by key dependencies like
`@rsbuild/core` and `@rslib/core`, which require ^20.19.0 || >=22.12.0. This makes
the Node.js version requirement explicit and visible to contributors and
tooling.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 304efb06-2a59-4dcb-9b6b-0f6ca1a9efd9
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
package.json
| }, | ||
| "dependencies": { | ||
| "@vercel/ncc": "0.38.4", | ||
| "@vercel/ncc": "0.44.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== package.json engines/packageManager =="
jq '{packageManager, engines, dependencies: { "`@vercel/ncc`": .dependencies["`@vercel/ncc`"] }}' package.json
echo
echo "== Node version pins in common toolchain files =="
fd -HI '(^\.nvmrc$|^\.node-version$|^\.tool-versions$|^Dockerfile$|^dockerfile$|^.*\.yml$|^.*\.yaml$)' . \
| while read -r f; do
echo "--- $f"
rg -n -C2 'node-version|setup-node|NODE_VERSION|FROM node|nodejs|engines|volta|nvm|tool-versions' "$f" || true
doneRepository: rstackjs/prebundle
Length of output: 12355
Add explicit engines field to package.json for clarity and consistency.
package.json lacks an engines.node field despite key dependencies enforcing Node constraints (e.g., @rsbuild/core, @rslib/core require ^20.19.0 || >=22.12.0). While CI is already pinned to Node 24.16.0 and dependency constraints provide implicit protection, explicitly declaring the supported Node range in package.json aligns with the dependency requirements and makes expectations clear to contributors and tools.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@package.json` at line 28, Add an explicit engines field to the package.json
file at the root level to declare the supported Node.js version range. Set the
engines.node property to match the Node version constraints enforced by key
dependencies like `@rsbuild/core` and `@rslib/core`, which require ^20.19.0 ||
>=22.12.0. This makes the Node.js version requirement explicit and visible to
contributors and tooling.
0901526 to
e5ffc2d
Compare
renovate
Bot
force-pushed
the
renovate/all-minor-patch
branch
from
e5ffc2d to
1ff7d0f
Compare
This PR contains the following updates:
0.22.0→0.23.0^0.6.1→^0.6.2^0.10.3→^0.10.624.12.4→24.13.20.38.4→0.44.011.5.0→11.8.0^3.8.3→^3.8.4^4.60.4→^4.62.0^2.1.2→^2.1.3Release Notes
web-infra-dev/rslib (@rslib/core)
v0.23.0Compare Source
What's Changed
New Features 🎉
Performance 🚀
Other Changes
Full Changelog: web-infra-dev/rslib@v0.22.1...v0.23.0
v0.22.1Compare Source
What's Changed
Bug Fixes 🐞
Document 📖
Other Changes
e853652by @renovate[bot] in #1684Full Changelog: web-infra-dev/rslib@v0.22.0...v0.22.1
web-infra-dev/rslint (@rslint/core)
v0.6.2Compare Source
What's Changed
New Features 🎉
prefer-equality-matcherrule by @eryue0220 in #1061Performance 🚀
Bug Fixes 🐞
Refactor 🔨
Other Changes
dd6bcebby @fansenze in #1103Full Changelog: web-infra-dev/rslint@v0.6.1...v0.6.2
web-infra-dev/rstest (@rstest/core)
v0.10.6Compare Source
What's Changed
Bug Fixes 🐞
Document 📖
Other Changes
0ac4127by @renovate in #1437Full Changelog: web-infra-dev/rstest@v0.10.5...v0.10.6
v0.10.5Compare Source
What's Changed
New Features 🎉
Bug Fixes 🐞
Document 📖
Other Changes
Full Changelog: web-infra-dev/rstest@v0.10.4...v0.10.5
v0.10.4Compare Source
What's Changed
New Features 🎉
Bug Fixes 🐞
Refactor 🔨
Document 📖
Other Changes
3cbb846by @renovate[bot] in #1343Full Changelog: web-infra-dev/rstest@v0.10.3...v0.10.4
vercel/ncc (@vercel/ncc)
v0.44.0Compare Source
Features
v0.43.0Compare Source
Changes
pnpm/pnpm (pnpm)
v11.8.0Compare Source
Minor Changes
c112b61: Added a--dry-runoption topnpm install. It runs a full dependency resolution and reports what an install would change, but writes nothing to disk (no lockfile, nonode_modules) and always exits with code 0. This mirrors the preview semantics ofnpm install --dry-run#7340.179ebc4:pnpm run --no-bailnow exits with a non-zero exit code when any of the executed scripts fail, while still running every matched script to completion. This makes the exit-code behavior of--no-bailconsistent between recursive and non-recursive runs (recursive runs already failed at the end). Previously, a non-recursivepnpm run --no-bailalways exited with code 0, even when a script failed #8013.0474a9c: Added support for generating Node.js package maps atnode_modules/.package-map.jsonduring isolated and hoisted installs. Added thenode-experimental-package-mapsetting to inject the generated map into pnpm-managed Node.js script environments, and thenode-package-map-typesetting to choose betweenstandardandloosepackage maps.dcededc:pnpm sbomnow marks components reachable only throughdevDependencieswith CycloneDXscope: "excluded"and thecdx:npm:package:developmentproperty. Theexcludedscope documents "component usage for test and other non-runtime purposes", which matches the semantics of a devDependency; the property is the CycloneDX npm-taxonomy marker emitted by@cyclonedx/cyclonedx-npm, so both modern (scope) and existing (property) consumers are covered. Components reachable at runtime (including installedoptionalDependencies) omitscopeand default torequired.1495cb0: Added per-package SBOM generation with--outand--splitflags. Use--out out/%s.cdx.jsonto write one SBOM per workspace package to individual files, or--splitfor NDJSON output to stdout. When--filterselects a single package, the SBOM root component now uses that package's metadata. Workspace inter-dependencies (workspace:protocol) and their transitive dependencies are included. Author, repository, and license fall back to the root manifest when the package doesn't define them.293921a: feat(view): support searching project manifest upward when package name is omittedWhen running
pnpm viewwithout a package name, the command now searchesupward for the nearest project manifest (
package.json,package.yaml, orpackage.json5) and uses itsnamefield.If the manifest exists but lacks a
namefield, an error is thrown.This change also replaces the
find-updependency withempathicforimproved performance and consistency across workspace tools.
Patch Changes
29ab905: Fixedpnpm updateoverriding the version range policy of a named catalog whose name parses as a version (e.g.catalog:express4-21). Thecatalog:reference carries no pinning of its own, so the prefix from the catalog entry (such as~) is now preserved instead of being widened to^#10321.bee4bf4: Security: validate config dependency names and versions from the env lockfile (pnpm-lock.yaml) before using them to build filesystem paths. A committed lockfile with a traversal-shapedconfigDependenciesname (such as../../PWNED) or version (such as../../../PWNED) could previously causepnpm installto create symlinks or write package files outsidenode_modules/.pnpm-configand the store. Names must now be valid npm package names and versions must be exact semver versions; the same validation is applied to optional subdependencies of config dependencies, and to the legacy workspace-manifest format before any lockfile is written. See GHSA-qrv3-253h-g69c.96bdd57: Fixlink:workspace protocol switching tofile:afterpnpm rmis run from inside a workspace package whose target workspace dependency has its own dependencies, wheninjectWorkspacePackages: trueis set. Follow-up to #10575, which fixed the same symptom for workspace packages without dependencies.302a2f7: No longer warn about using bothpackageManageranddevEngines.packageManagerwhen the two fields pin the same package manager at the same version with the same integrity hash (e.g. bothpnpm@11.5.1+sha512.…). Previously the hash was stripped from the legacypackageManagerfield but not fromdevEngines.packageManager, so even identical specifications looked like a mismatch #12028.The warning still fires on any genuine divergence, and several cases now state the specific reason instead of a single generic message: a different package manager, a different version, or contradictory integrity hashes for the same version.
3f0fb21: Fixed the progress line showing leftover characters from external processes that write to the terminal between progress updates (e.g. an SSH passphrase prompt would leave a fragment likeadded 0sa':). The interactive reporter now redraws each frame in place, erasing to the end of the display before reprinting, so any such remnants are cleared #12350.564619f: Fixedpnpm approve-buildsreporting "no packages awaiting approval" when a build-script dependency whose approval was revoked (e.g. aftergit stashdrops theallowBuildsfrompnpm-workspace.yaml) is re-added. The revoked packages are now correctly recorded in.modules.yamlsoapprove-buildscan find them. #122213d1fd20: Skip the redundant "target bin directory already contains an exe called node" warning on Windows when the existingnode.exealready matches the target (same hard link or identical content) pnpm/pnpm#12203.1b02b47: Fix macOS Gatekeeper blocking native binaries (.node,.dylib,.so) by removing thecom.apple.quarantineextended attribute after importing them from the store.When pnpm imports files from its content-addressable store into
node_modules, macOS preserves extended attributes, includingcom.apple.quarantine. If this xattr is present on a store blob (e.g. it was first written under a Gatekeeper-enabled app such as a Git client), it propagates tonode_modules, and Gatekeeper blocks the native binary from loading even though pnpm already verified the file's integrity against the lockfile.After importing a package, pnpm now strips
com.apple.quarantinefrom its native binaries, matching Homebrew's behaviour of dropping quarantine from verified downloads. The cleanup is macOS-only, runs in a single batchedxattrcall per package, is restricted to native binaries (other files are untouched), and is non-fatal (it logs a warning on unexpected errors).Fixes #11056
61969fb: Fixpnpm installwithoptimisticRepeatInstallincorrectly reportingAlready up to datewhenpnpm-lock.yamlchanged but project manifests did not. This affected workflows such as checking out or restoring only the lockfile #12100.Also fixes
checkDepsStatusto use the correct lockfile path whenuseGitBranchLockfileis enabled, so the optimistic fast-path and lockfile modification detection work withpnpm-lock.<branch>.yamlfiles instead of always stat'ingpnpm-lock.yaml. Merge-conflict detection now reads the resolved lockfile name as well, and withmergeGitBranchLockfilesenabled everypnpm-lock.*.yamlis scanned for modifications and conflicts. The git branch is now resolved by reading.git/HEADdirectly (no process spawn) and uses the workspace directory rather thanprocess.cwd().5c12968: Fix recursive updates of transitive dependencies when the update command mixes transitive dependency patterns with direct dependency selectors. For example,pnpm up -r "@​babel/core" uuidnow updates matching transitive@babel/coredependencies even whenuuidis a direct dependency selector #12103.9d79ba1: Register thepnpm update --no-saveflag in the CLI help and option parser.0474a9c: Fixedpnpm importfor Yarn v2 lockfiles whenjs-yamlv4 is installed.9e0c375: Fixedpnpm installrepeatedly prompting to remove and reinstallnode_modulesin a workspace package whenenableGlobalVirtualStoreis enabled. The post-install build step recorded a per-projectnode_modules/.pnpmvirtual store directory innode_modules/.modules.yaml, overwriting the global<storeDir>/linksvalue the install step had written. The next install then detected a virtual-store mismatch (ERR_PNPM_UNEXPECTED_VIRTUAL_STORE). The build step now derives the same global virtual store directory as the install step #12307.223d060: Document the--cpu,--osand--libcflags in the output ofpnpm install --help. These flags were already supported but were only documented on the website #12359.e85aea2: Avoid readingREADME.mdfrom disk when publishing if the publish manifest already provides areadmefield. The README is now only read lazily, insidecreateExportableManifest, when it is actually needed.3188ae7: Fixedpnpm peers checkto accept loose peer dependency ranges such as>=3.16.0 || >=4.0.0-when the installed peer version satisfies the range #12149.531f2a3: Fixedpnpm updaterewriting aworkspace:dependency that points at a local path (e.g.workspace:../packages/foo/dist) into a normalizedlink:or version-range specifier. Such specifiers are now preserved verbatim when the workspace protocol is preserved #3902.fe66535: Fixed a lockfile non-convergence bug where an incremental install kept a duplicate transitive dependency that a fresh install would not produce. When a package is reused from the lockfile, its child edges are taken verbatim and bypass the preferred-versions walk, so a transitive dependency could stay pinned to an older version even after a direct dependency resolved to a higher version that satisfies the same range. The resolver now refreshes such a stale pin to the higher direct-dependency version during resolution — so the older version is never resolved or fetched, and the incremental result converges to the fresh one.6d35338:pnpm installdetects changes inside local file dependencies again. The optimistic repeat-install fast path only tracks manifest and lockfile modification times, so edits inside a local dependency's directory (or a repacked local tarball) were reported as "Already up to date". Projects with local file dependencies (file:and bare local path or tarball specifiers, declared directly or throughpnpm.overrides) now always run a full install, which refetches those dependencies, matching pnpm v10 behavior #11795.4ca9247: Preserve the existing Node.js runtime version prefix when resolvingnode@runtime:<range>to a concrete version.30c7590: Create shorter CAFS temporary package directories to leave room for lifecycle scripts that create IPC socket paths under TMPDIR.13815ad: Reporter output (warnings, progress) forpnpm storeandpnpm configsubcommands now goes to stderr instead of stdout. This fixes scripts that capture their stdout (e.g.PNPM_STORE=$(pnpm store path),pnpm config list --json | jq) from getting warnings mixed into the result.1c05876: Avoid relinking unchanged child dependencies and remove stale child links during warm installs.817f99d: Fixed lockfile churn where a package'stransitivePeerDependenciescould be dropped (and shift between packages) when the package participates in a dependency cycle. A cycle re-entry resolves against truncated children, so it must not be cached as "pure"; otherwise sibling occurrences of the same package short-circuit and lose transitive peers depending on traversal order #5108.eba03e0: Fixpnpm installreporting "Already up to date" after a catalog entry inpnpm-workspace.yamlwas reverted to a previous version. After an update modified a catalog, the workspace state cache stored the pre-update catalog versions, so reverting the entry back to its original version was not detected as an outdated state #12418.3b54d79:pnpm updatenow keeps lockfileoverridesthat resolve through a catalog in sync with the catalog. Previously, when an override referenced a catalog (e.g.overrides: { foo: 'catalog:' }) andpnpm updatebumped that catalog entry, the lockfile'scatalogsadvanced while the resolvedoverrideskept the old version. The resulting lockfile was internally inconsistent, so a laterpnpm install --frozen-lockfilefailed withERR_PNPM_LOCKFILE_CONFIG_MISMATCH.9d0a300: Fixedpnpm version --recursiveso it honors the workspace selection. In recursive mode the version bump now applies to the packages resolved from the workspace filter (selectedProjectsGraph), matching the behavior ofpnpm publish --recursive, instead of always bumping every workspace package #11348.v11.7.0Compare Source
Minor Changes
Added a new setting
frozenStore(--frozen-store) that letspnpm installrun against a package store on a read-only filesystem (e.g. a Nix store, a read-only bind mount, an OCI layer). When enabled, pnpm opens the store's SQLiteindex.dbthrough theimmutable=1URI — bypassing the WAL/-shmsidecar creation that otherwise fails on a read-only directory — and suppresses every store-write path (theindex.dbwriter and the project-registry write). Pair it with--offline --frozen-lockfileagainst a fully-populated store. Under the global virtual store, package directories live inside the store, so if the store is missing the build output of a package whose lifecycle scripts are approved (or that has a patch), pnpm fails up front withERR_PNPM_FROZEN_STORE_NEEDS_BUILDrather than crashing mid-build on a read-only write — seed the store with those builds first. Incompatible with--forceand with a configured pnpr server, since both write into the store; the side-effects cache is likewise not written underfrozenStore. If the store is missing its content directory, the install fails fast withERR_PNPM_FROZEN_STORE_INCOMPLETErather than attempting to initialize it. The read-onlyimmutable=1open requires Node.js >=22.15.0, >=23.11.0, or >=24.0.0; on older runtimes--frozen-storefails with a clearERR_PNPM_FROZEN_STORE_UNSUPPORTED_NODEerror. Bin-linking also tolerates a read-only store: under the global virtual store a package's bin source lives inside the store, so thechmodthat makes it executable would be refused — withEPERM/EACCES, or withEROFSon a genuinely read-only filesystem. Thatchmodis redundant when the seed already ships its bins executable with a normalized shebang, so it is now skipped in that case, while a non-executable bin (or one still carrying a Windows CRLF shebang) on a read-only store still errors.When
pacquet(the Rust port of pnpm) is declared inconfigDependencies, pnpm now delegates dependency resolution to it too — not just materialization — provided the installed pacquet is new enough to support full resolving installs (>= 0.11.7).Previously pacquet only ran in frozen-install mode: pnpm always resolved the dependency graph itself (writing
pnpm-lock.yaml) and handed pacquet a finished lockfile to fetch / import / link. With pacquet >= 0.11.7, a non-frozenpnpm install(default isolatednodeLinker, plain install) is delegated to pacquet end-to-end in a single pass — pacquet resolves the manifests, writes the lockfile, and materializesnode_modules. pnpm detects the capability from the installed pacquet's version; older pacquet releases keep the resolve-then-materialize split, andadd/update/removestill resolve in pnpm (it has to mutate the manifests first). This remains an opt-in preview of the Rust install engine #11723.Added a new opt-in
--batchflag topnpm publish --recursivethat sends all selected packages to the registry in a singlePUT /-/pnpm/v1/publishrequest instead of one request per package. The target registry has to implement the batch publish endpoint (pnpr does); registries that don't are reported with a clearERR_PNPM_BATCH_PUBLISH_UNSUPPORTEDerror. The batch is processed all-or-nothing by pnpr: if any package in the batch fails validation, none of the packages are published.Patch Changes
Reject path-traversal and reserved dependency aliases (such as
../../../escape,.bin,.pnpm, ornode_modules) that come from a lockfile rather than a freshly resolved manifest. A crafted lockfile alias could otherwise be joined directly under a hoistednode_modulesdirectory, letting package files be written outside the intended install root or overwrite pnpm-owned layout.The fix adds two layers:
nodeLinker: hoistedgraph builder now validates each alias at the directory sink (safeJoinModulesDir), matching the validation pnpm already performs when resolving aliases from manifests.verifyLockfileResolutions) now runs an always-on, policy-independent check that rejects any importer or snapshot dependency alias that is not a valid package name, failing the install early — before any fetch or filesystem work — for every node linker at once.Made shared package child resolution deterministic when the same package is reached through multiple contexts. pnpm now chooses the shallowest occurrence, then importer order, then parent path, instead of letting request timing decide the child context and missing-peer report pnpm/pnpm#12358.
Fix garbled summary line after submitting
pnpm update -iandpnpm audit --fix -i. The interactive checkbox prompt previously printed every selected choice's full table row (label, current/target versions, workspace, URL) joined by commas, producing a wall of text after pressing Enter. The summary now lists only the selected package names (or vulnerability keys) by setting an explicitshortper choice; the in-progress selection UI is unchanged.Prevent
pnpm patch-removefrom removing files outside the configured patches directory.Fixed
pnpm publishignoringstrictSsl: falsewhen publishing to registries with self-signed certificates. ThestrictSSLoption is now forwarded tolibnpmpublish/npm-registry-fetchso thatstrict-ssl=falsein.npmrcorstrictSsl: falseinpnpm-workspace.yamlis respected during publish, the same way it is forpnpm installpnpm/pnpm#12012.Fixed
Cannot destructure property 'manifest' of 'manifestsByPath[rootDir]' as it is undefinedregression introduced in 11.6.0 when runningpnpm add <pkg>outside a workspace on Windows.selectProjectByDirwas keying the resultingProjectsGraphbyopts.dirinstead ofproject.rootDir, so downstreammanifestsByPathlookups missed when the two paths normalized differently (typically drive-letter casing). pnpm/pnpm#12379Git dependencies that point to a subdirectory of a repository (
repo#commit&path:/sub/dir) keep theirpathin the lockfile again. Since the integrity of git-hosted tarballs started being pinned in the lockfile, any install that actually downloaded the tarball rebuilt the lockfile resolution as{ integrity, tarball, gitHosted }and dropped thepathfield, while installs served from the store kept it — so the field disappeared seemingly at random. Withoutpath, later installs from that lockfile silently unpacked the repository root instead of the subdirectory #12304.Fixed nondeterministic lockfile output that made
pnpm dedupe --checkfail intermittently in CI. When a locked peer provider was pinned for a dependency that has no child dependencies of its own, the pinned provider leaked into the shared parent scope, so siblings resolved after it could pick up an optional peer they should not see. Which siblings were affected depended on resolution order, which varies with network timing.Sped up
pnpm installwith a frozen lockfile by running lockfile verification (the policy revalidation gate added forminimumReleaseAge/trustPolicyand the tarball-URL anti-tamper check) concurrently with fetching and linking instead of blocking the whole install on it. Dependency lifecycle scripts are still held back until verification succeeds, so no script runs on an unverified lockfile: if verification fails the install aborts before any dependency build, and if linking finishes first the install waits for the verification verdict before completing.User-defined
npm_config_*environment variables are now preserved during lifecycle script execution. Previously, allnpm_-prefixed env vars were stripped, which caused user-set variables likenpm_config_platform_archto be lost pnpm/pnpm#12399.pnpm can now use different auth tokens for different package scopes, even when those scopes use the same registry URL.
Previously, auth was selected only by registry URL. If
@org-aand@org-bboth usedhttps://npm.pkg.github.com/, they had to share the same token. This caused problems for registries that issue tokens per organization or per scope.Configure a scope-specific token by adding the package scope after the registry URL in the auth key:
pnpm login --registry=https://npm.pkg.github.com --scope=@​org-awrites the token to the same scope-specific auth key.When installing or publishing
@org-a/*, pnpm usesORG_A_TOKEN. For@org-b/*, pnpm usesORG_B_TOKEN. Packages without a matching scope continue to use the registry-wide fallback token.pnpm setupno longer prompts to approve build scripts for@pnpm/exewhen installing the standalone executable. pnpm links the platform-specific binary itself, so the package's install scripts are skipped during the global self-install #12377.Close lockfile reads deterministically before rewriting lockfiles and keep pacquet's virtual store directory length aligned with pnpm on Windows.
A
304 Not Modifiedanswer from the registry now renews the cached metadata file's mtime, so theminimumReleaseAgefreshness shortcut keeps serving resolutions from the cache. Previously, once a cached packument grew older thanminimumReleaseAge, every subsequent install re-validated it against the registry forever, because a 304 never rewrites the file.Updated dependency ranges. Notably:
@pnpm/loggerpeer dependency range moved to^1100.0.0.msgpackr1.11.8 → 2.0.4 (store index files remain byte-compatibleConfiguration
📅 Schedule: (in timezone Asia/Shanghai)
* 0-3 1,15 * *)🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR was generated by Mend Renovate. View the repository job log.