chore(deps): update all non-major dependencies#56
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:
📝 WalkthroughWalkthroughVersion bumps across four 🚥 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
4 times, most recently
from
5af1294 to
bbc9449
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 `@test/yarn-berry/package.json`:
- Line 9: The packageManager field in test/yarn-berry/package.json specifies
Yarn 4.17.0, but the PR objectives indicate the update should be to Yarn 4.16.0.
Additionally, the provided sha512 hash cannot be verified against official Yarn
release sources (GitHub releases or npm registry). Clarify whether 4.17.0 is the
intended target version, then obtain the correct sha512 integrity hash from an
official Yarn release source and update the packageManager value with both the
correct version and verified hash to ensure corepack can properly validate the
binary.
🪄 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: 3aa2ded0-361a-4882-a46e-c58e662b3656
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (4)
package.jsontest/pnpm-workspace/package.jsontest/pnpm/package.jsontest/yarn-berry/package.json
✅ Files skipped from review due to trivial changes (2)
- test/pnpm/package.json
- test/pnpm-workspace/package.json
🚧 Files skipped from review as they are similar to previous changes (1)
- package.json
| "src/*" | ||
| ], | ||
| "packageManager": "yarn@4.15.0+sha512.07ec708ac11e2eaa4ea2b04cfbb272812f7e74a753f1595eaef4486c663a98306a30cca3e6fc40f7a0b168dcfb3a2490b6a5e0501e20fb69cc36f563dd161c53" | ||
| "packageManager": "yarn@4.17.0+sha512.c2957de2f9025ab14d63b24d0d8be1f1655810e22c341042c27f7ecd017b180ec12db73d69ac366d71b304ef9f069349ce462de96f04f8f1da317f4f762c95ae" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the latest stable release of Yarn 4.x, and specifically does Yarn 4.17.0 exist with sha512 hash c2957de2f9025ab14d63b24d0d8be1f1655810e22c341042c27f7ecd017b180ec12db73d69ac366d71b304ef9f069349ce462de96f04f8f1da317f4f762c95ae?
💡 Result:
As of June 16, 2026, the latest stable release of Yarn 4.x is version 4.17.0, which was published on June 15, 2026 [1]. Regarding the specific SHA-512 hash you provided (c2957de2f9025ab14d63b24d0d8be1f1655810e22c341042c27f7ecd017b180ec12db73d69ac366d71b304ef9f069349ce462de96f04f8f1da317f4f762c95ae), there is no evidence associating this hash with the Yarn 4.17.0 release [1][2]. Official Yarn releases are distributed via the npm registry, and integrity verification typically utilizes hashes provided by the registry or the official release assets on GitHub; the hash you provided does not appear in official project documentation or repository metadata [1].
Citations:
- 1: https://github.com/yarnpkg/berry/releases/tag/%40yarnpkg/cli/4.17.0
- 2: https://anaconda.org/conda-forge/yarn/files/manage?page=0
🏁 Script executed:
#!/bin/bash
# Search for references to this specific hash in the codebase to understand its origin
rg "c2957de2f9025ab14d63b24d0d8be1f1655810e22c341042c27f7ecd017b180ec12db73d69ac366d71b304ef9f069349ce462de96f04f8f1da317f4f762c95ae" --type-listRepository: rstackjs/rsbuild-plugin-arethetypeswrong
Length of output: 474
🌐 Web query:
Yarn 4.17.0 official release integrity hash SHA-512
💡 Result:
Yarn version 4.17.0 was officially released on June 15, 2026 [1]. Regarding your request for a SHA-512 integrity hash for this release: Yarn 4.x (part of the Berry architecture) does not provide a single global SHA-512 integrity hash for the release itself in the manner of a downloadable binary artifact [2][3]. Instead, Yarn 4.x manages package integrity through a custom checksum system within the yarn.lock file [2][3]. In the Yarn Berry (v2+) architecture, integrity is verified using custom checksums that correspond to the contents of its internal global cache (which uses a zip-based format for efficiency) [2][3]. This differs from the standard SHA-512 subresource integrity (SRI) hashes often found in npm registry metadata for raw tarballs [2][4][3]. Consequently, there is no official "SHA-512 integrity hash" for the Yarn 4.17.0 release itself [2][3]. You can view the official release notes and changelog for version 4.17.0 on the project's GitHub repository [1].
Citations:
- 1: https://github.com/yarnpkg/berry/releases/tag/%40yarnpkg/cli/4.17.0
- 2: https://stackoverflow.com/questions/73709178/yarn-v2-lockfile-how-the-validate-new-checksum
- 3: [Bug?]: custom yarn checksum is bad for file sharing yarnpkg/berry#6297
- 4: https://readoss.com/en/yarnpkg/yarn/fetching-caching-and-the-offline-mirror
🌐 Web query:
site:github.com yarnpkg/berry releases 4.17.0 hash sha512
💡 Result:
Yarn Berry release 4.17.0 was officially published on June 15, 2026 [1]. Regarding the sha512 hash: Yarn Berry (v2+) uses its own custom checksum format within its lockfiles, rather than standard sha512 integrity hashes for the raw tarballs [2]. This internal checksum is used by Yarn for its own integrity validation of the packages it manages [3][2][4]. There is no publicly documented sha512 release hash for the 4.17.0 release itself; for verifying the authenticity of Yarn releases, the standard practice is to rely on the official GitHub release tags and the npm registry, which handle integrity verification via their own mechanisms [1][5].
Citations:
- 1: https://github.com/yarnpkg/berry/releases/tag/%40yarnpkg/cli/4.17.0
- 2: [Bug?]: custom yarn checksum is bad for file sharing yarnpkg/berry#6296
- 3: https://github.com/yarnpkg/berry/blob/c0274d6d7ba5939f447e78aaf16e456a00cf0bd1/packages/yarnpkg-core/sources/hashUtils.ts
- 4: https://github.com/yarnpkg/berry/blob/8fe214dfa72dabbc7134bbd6973cdfce4891cd42/yarn.lock
- 5: https://github.com/yarnpkg/berry/releases
Resolve version discrepancy and verify Yarn 4.17.0 hash origin.
The PR objectives specify updating Yarn to 4.16.0, but this change updates to 4.17.0. Additionally, the sha512 hash c2957de2f9025ab14d63b24d0d8be1f1655810e22c341042c27f7ecd017b180ec12db73d69ac366d71b304ef9f069349ce462de96f04f8f1da317f4f762c95ae cannot be verified against official Yarn 4.17.0 release sources—it does not appear in GitHub release metadata or npm registry integrity data. Clarify whether 4.17.0 is the intended version and provide the correct integrity hash from an official Yarn release source to ensure corepack validates the binary correctly.
🤖 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 `@test/yarn-berry/package.json` at line 9, The packageManager field in
test/yarn-berry/package.json specifies Yarn 4.17.0, but the PR objectives
indicate the update should be to Yarn 4.16.0. Additionally, the provided sha512
hash cannot be verified against official Yarn release sources (GitHub releases
or npm registry). Clarify whether 4.17.0 is the intended target version, then
obtain the correct sha512 integrity hash from an official Yarn release source
and update the packageManager value with both the correct version and verified
hash to ensure corepack can properly validate the binary.
bbc9449 to
416c217
Compare
renovate
Bot
force-pushed
the
renovate/all-minor-patch
branch
from
416c217 to
f631952
Compare
This PR contains the following updates:
^7.58.7→^7.58.92.0.9→2.0.15^0.22.0→^0.23.0^0.6.1→^0.6.2^0.10.3→^0.10.6^0.10.3→^0.10.6^0.10.3→^0.10.6^24.12.4→^24.13.211.5.0→11.7.010.34.1+sha512.b58fbde6dca66a929538021581f648b4570b6ca19b18e7cbd7f2c07a7b24454155388dacdf08f2af3678e88a6d1fe04f9d609df24bf51735a060ea041b374ab7→10.34.3^1.2.3→^1.2.44.15.0+sha512.07ec708ac11e2eaa4ea2b04cfbb272812f7e74a753f1595eaef4486c663a98306a30cca3e6fc40f7a0b168dcfb3a2490b6a5e0501e20fb69cc36f563dd161c53→4.17.0Release Notes
microsoft/rushstack (@microsoft/api-extractor)
v7.58.9Compare Source
Sat, 13 Jun 2026 00:16:18 GMT
Version update only
v7.58.8Compare Source
Mon, 08 Jun 2026 15:15:49 GMT
Patches
web-infra-dev/rsbuild (@rsbuild/core)
v2.0.15Compare Source
What's Changed
New Features 🎉
Performance 🚀
Bug Fixes 🐞
Document 📖
Other Changes
Full Changelog: web-infra-dev/rsbuild@v2.0.14...v2.0.15
v2.0.14Compare Source
What's Changed
Performance 🚀
Other Changes
Full Changelog: web-infra-dev/rsbuild@v2.0.13...v2.0.14
v2.0.13Compare Source
What's Changed
New Features 🎉
Bug Fixes 🐞
Document 📖
Other Changes
Full Changelog: web-infra-dev/rsbuild@v2.0.12...v2.0.13
v2.0.12Compare Source
What's Changed
New Features 🎉
Performance 🚀
Bug Fixes 🐞
Refactor 🔨
Document 📖
Other Changes
Full Changelog: web-infra-dev/rsbuild@v2.0.11...v2.0.12
v2.0.11Compare Source
What's Changed
Bug Fixes 🐞
Document 📖
Other Changes
Full Changelog: web-infra-dev/rsbuild@v2.0.10...v2.0.11
v2.0.10Compare Source
What's Changed
New Features 🎉
Bug Fixes 🐞
Document 📖
Other Changes
Full Changelog: web-infra-dev/rsbuild@v2.0.9...v2.0.10
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/adapter-rslib)
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
pnpm/pnpm (pnpm)
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 iConfiguration
📅 Schedule: (in timezone Asia/Shanghai)
* 0-3 1,15 * *)🚦 Automerge: Enabled.
♻ 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.
This PR was generated by Mend Renovate. View the repository job log.