Repository navigation
chore(deps): update all non-major dependencies - #156
cachekit-renovate-bot[bot] wants to merge 1 commit into
Conversation
cachekit-renovate-bot
Bot
added
the
dependencies
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
Kody Code Review — 2 suggested fixes. 🛠️ Open Agent Prompt |
![kodus-27b[bot]](https://avatars.githubusercontent.com/u/223823690?s=60&v=4){kind=small}
| wasm-bindgen = "=0.2.128" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.105" |
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate exact-pins wasm-bindgen =0.2.128 (Cargo.lock resolves 0.2.128), but ci.yml:227, build-wasm.yml:31 and release-please.yml:254 still install the wasm-bindgen CLI 0.2.121 with the 0.2.121 SHA256. scripts/build.sh:11-17 compares the Cargo.lock version against wasm-bindgen --version and exits 1 with wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.128, which fails the CI wasm job, the build-wasm workflow and the release pipeline. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.128 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.128 x86_64-unknown-linux-musl tarball, and update the js-sys comment to name 0.2.128.
wasm-bindgen = "=0.2.128"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.128 above.
js-sys = "=0.3.105"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.128 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate exact-pins wasm-bindgen =0.2.128 (Cargo.lock resolves 0.2.128), but ci.yml:227, build-wasm.yml:31 and release-please.yml:254 still install the wasm-bindgen CLI 0.2.121 with the 0.2.121 SHA256. scripts/build.sh:11-17 compares the Cargo.lock version against `wasm-bindgen --version` and exits 1 with `wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.128`, which fails the CI wasm job, the build-wasm workflow and the release pipeline. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.128 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.128 x86_64-unknown-linux-musl tarball, and update the js-sys comment to name 0.2.128.
Suggested Code:
wasm-bindgen = "=0.2.128"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.128 above.
js-sys = "=0.3.105"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.128 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.yml
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
126bd20 to
37f9d01
Compare
This comment has been minimized.
This comment has been minimized.
148faa9 to
44ddd03
Compare
| wasm-bindgen = "=0.2.128" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.105" |
There was a problem hiding this comment.
Version drift in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.128, but ci.yml:227, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121 with the 0.2.121 tarball SHA-256. When scripts/build.sh:11-15 reads 0.2.128 from Cargo.lock and compares it to the installed 0.2.121 CLI, it exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.128', which breaks the Workers CI lane, the build-wasm workflow and the release-please wasm publish. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.128 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.128 x86_64-unknown-linux-musl tarball, or keep the crate at 0.2.121.
wasm-bindgen = "=0.2.128"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.128 above.
js-sys = "=0.3.105"
# ALSO update .github/workflows/{ci,build-wasm,release-please}.yml:
# WASM_BINDGEN_VERSION: 0.2.128
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.128-x86_64-unknown-linux-musl.tar.gz>Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version drift in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.128, but ci.yml:227, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121 with the 0.2.121 tarball SHA-256. When scripts/build.sh:11-15 reads 0.2.128 from Cargo.lock and compares it to the installed 0.2.121 CLI, it exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.128', which breaks the Workers CI lane, the build-wasm workflow and the release-please wasm publish. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.128 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.128 x86_64-unknown-linux-musl tarball, or keep the crate at 0.2.121.
Suggested Code:
wasm-bindgen = "=0.2.128"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.128 above.
js-sys = "=0.3.105"
# ALSO update .github/workflows/{ci,build-wasm,release-please}.yml:
# WASM_BINDGEN_VERSION: 0.2.128
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.128-x86_64-unknown-linux-musl.tar.gz>
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
44ddd03 to
112b80b
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (and Cargo.lock resolves 0.2.129), but .github/workflows/build-wasm.yml:31, ci.yml:227, and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121, and WASM_BINDGEN_SHA256 is still the checksum of the 0.2.121 tarball. When scripts/build.sh:11-15 compares the Cargo.lock pin against the installed CLI, it exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', which fails the wasm build in CI and in the release-please publish job. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment on line 23.
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 in
# .github/workflows/{build-wasm,ci,release-please}.yml to 0.2.129Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (and Cargo.lock resolves 0.2.129), but .github/workflows/build-wasm.yml:31, ci.yml:227, and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121, and WASM_BINDGEN_SHA256 is still the checksum of the 0.2.121 tarball. When scripts/build.sh:11-15 compares the Cargo.lock pin against the installed CLI, it exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', which fails the wasm build in CI and in the release-please publish job. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment on line 23.
Suggested Code:
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 in
# .github/workflows/{build-wasm,ci,release-please}.yml to 0.2.129
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
| }, | ||
| "devDependencies": { | ||
| "@cloudflare/vitest-pool-workers": "0.18.7", | ||
| "@cloudflare/vitest-pool-workers": "0.22.0", |
There was a problem hiding this comment.
WHAT: The @cloudflare/vitest-pool-workers dependency jumps from 0.18.7 to 0.22.0.
WHY: This is a multi-minor version bump in a dependency manifest. The team rule requires SCA or audit evidence for dependency changes, plus an updated lockfile, to rule out known CVEs and supply-chain risk.
HOW: Run npm/pnpm audit or an OSV query for 0.22.0, attach the results to the PR description, and include the root lockfile update.
Also found in:
packages/cachekit-core-wasm/Cargo.toml:20-20packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit/package.json:101-101
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File packages/cachekit/package.json:
Line 95:
WHAT: The @cloudflare/vitest-pool-workers dependency jumps from 0.18.7 to 0.22.0.
WHY: This is a multi-minor version bump in a dependency manifest. The team rule requires SCA or audit evidence for dependency changes, plus an updated lockfile, to rule out known CVEs and supply-chain risk.
HOW: Run npm/pnpm audit or an OSV query for 0.22.0, attach the results to the PR description, and include the root lockfile update.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
112b80b to
791e0cf
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version drift in the wasm-bindgen pin in packages/cachekit-core-wasm/Cargo.toml: the crate is bumped to =0.2.129, but every CI workflow still installs wasm-bindgen CLI 0.2.121 (.github/workflows/ci.yml:227, build-wasm.yml:31, release-please.yml:254). scripts/build.sh:11-15 compares Cargo.lock (0.2.129) against wasm-bindgen --version (0.2.121) and exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', which fails the Workers CI lane, the wasm build, and the release build. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, since changing only the version still fails the sha256sum check, and update the stale '0.2.121' comment on line 23.
wasm-bindgen = "=0.2.129"
# ... Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# plus, in ci.yml / build-wasm.yml / release-please.yml:
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version drift in the wasm-bindgen pin in packages/cachekit-core-wasm/Cargo.toml: the crate is bumped to =0.2.129, but every CI workflow still installs wasm-bindgen CLI 0.2.121 (.github/workflows/ci.yml:227, build-wasm.yml:31, release-please.yml:254). scripts/build.sh:11-15 compares Cargo.lock (0.2.129) against `wasm-bindgen --version` (0.2.121) and exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', which fails the Workers CI lane, the wasm build, and the release build. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, since changing only the version still fails the sha256sum check, and update the stale '0.2.121' comment on line 23.
Suggested Code:
wasm-bindgen = "=0.2.129"
# ... Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# plus, in ci.yml / build-wasm.yml / release-please.yml:
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
|
|
||
| [dependencies] | ||
| wasm-bindgen = "=0.2.121" | ||
| wasm-bindgen = "=0.2.129" |
There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no audit or SCA evidence. WHY: Dependency manifest changes must be checked for known CVEs and supply-chain risk. A jump of several patch releases on an exact-pinned toolchain crate also needs its lockfile updated. HOW: Run cargo audit or query OSV for wasm-bindgen 0.2.129 and attach the output to the PR. Commit the updated Cargo.lock, and update the adjacent comment that still references 0.2.121.
Also found in:
packages/cachekit/package.json:95-95packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit/package.json:101-101
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20:
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no audit or SCA evidence. WHY: Dependency manifest changes must be checked for known CVEs and supply-chain risk. A jump of several patch releases on an exact-pinned toolchain crate also needs its lockfile updated. HOW: Run `cargo audit` or query OSV for wasm-bindgen 0.2.129 and attach the output to the PR. Commit the updated Cargo.lock, and update the adjacent comment that still references 0.2.121.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
791e0cf to
e63fb17
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is pinned to =0.2.129 (Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:227, release-please.yml:254 and build-wasm.yml:31 still set WASM_BINDGEN_VERSION: 0.2.121, and ci.yml:231 pins WASM_BINDGEN_SHA256 to the 0.2.121 tarball. scripts/build.sh:11-17 compares the CLI version with the Cargo.lock version and runs exit 1 on mismatch, so the Workers CI lane, the build-wasm workflow and the release wasm build all fail with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', and no wasm artifact can be published. Fix: set WASM_BINDGEN_VERSION to 0.2.129 in all three workflows, update each WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment on line 23 to match.
wasm-bindgen = "=0.2.129"
# ...
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# In the same PR: .github/workflows/{ci,release-please,build-wasm}.yml
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is pinned to =0.2.129 (Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:227, release-please.yml:254 and build-wasm.yml:31 still set WASM_BINDGEN_VERSION: 0.2.121, and ci.yml:231 pins WASM_BINDGEN_SHA256 to the 0.2.121 tarball. scripts/build.sh:11-17 compares the CLI version with the Cargo.lock version and runs `exit 1` on mismatch, so the Workers CI lane, the build-wasm workflow and the release wasm build all fail with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', and no wasm artifact can be published. Fix: set WASM_BINDGEN_VERSION to 0.2.129 in all three workflows, update each WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment on line 23 to match.
Suggested Code:
wasm-bindgen = "=0.2.129"
# ...
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# In the same PR: .github/workflows/{ci,release-please,build-wasm}.yml
# WASM_BINDGEN_VERSION: 0.2.129
# WASM_BINDGEN_SHA256: <sha256 of wasm-bindgen-0.2.129-x86_64-unknown-linux-musl.tar.gz>
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
|
|
||
| [dependencies] | ||
| wasm-bindgen = "=0.2.121" | ||
| wasm-bindgen = "=0.2.129" |
There was a problem hiding this comment.
WHAT: The exact-pinned wasm-bindgen dependency is bumped from 0.2.121 to 0.2.129, with no visible supply-chain or CVE evidence.
WHY: A dependency manifest change must be checked against known advisories. wasm-bindgen also defines the JS/WASM ABI, so a version jump needs a matching lockfile and toolchain (wasm-bindgen-cli) update.
HOW: Run cargo audit or an OSV query for wasm-bindgen 0.2.129 and attach the output to the PR. Update Cargo.lock in the same PR, and confirm the wasm-bindgen-cli version used in the build matches 0.2.129.
Also found in:
packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit/package.json:95-95packages/cachekit/package.json:101-101
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20:
WHAT: The exact-pinned wasm-bindgen dependency is bumped from 0.2.121 to 0.2.129, with no visible supply-chain or CVE evidence.
WHY: A dependency manifest change must be checked against known advisories. wasm-bindgen also defines the JS/WASM ABI, so a version jump needs a matching lockfile and toolchain (wasm-bindgen-cli) update.
HOW: Run `cargo audit` or an OSV query for wasm-bindgen 0.2.129 and attach the output to the PR. Update Cargo.lock in the same PR, and confirm the wasm-bindgen-cli version used in the build matches 0.2.129.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
e63fb17 to
5b5134c
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is bumped to =0.2.129, but every CI workflow still installs the wasm-bindgen CLI 0.2.121 prebuilt with the 0.2.121 SHA256 (ci.yml:227, build-wasm.yml:31, release-please.yml:254). When scripts/build.sh:11-15 reads the pinned version from Cargo.lock (now 0.2.129), it exits with wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129, so the CI WASM build, the build-wasm workflow, and the release job all fail. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment on line 23 to say 0.2.129.
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is bumped to =0.2.129, but every CI workflow still installs the wasm-bindgen CLI 0.2.121 prebuilt with the 0.2.121 SHA256 (ci.yml:227, build-wasm.yml:31, release-please.yml:254). When scripts/build.sh:11-15 reads the pinned version from Cargo.lock (now 0.2.129), it exits with `wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129`, so the CI WASM build, the build-wasm workflow, and the release job all fail. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment on line 23 to say 0.2.129.
Suggested Code:
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/{ci,build-wasm,release-please}.yml
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
|
|
||
| [dependencies] | ||
| wasm-bindgen = "=0.2.121" | ||
| wasm-bindgen = "=0.2.129" |
There was a problem hiding this comment.
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
1fd170f to
ebb0f71
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate now pins wasm-bindgen =0.2.129, but .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still install and SHA256-check the 0.2.121 CLI. In those jobs, scripts/build.sh lines 11-16 compare the Cargo.lock version (0.2.129) against wasm-bindgen --version (0.2.121) and exit 1, so the wasm build fails in CI, in build-wasm, and in the release-please publish job. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and set WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 musl tarball.
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate now pins wasm-bindgen =0.2.129, but .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still install and SHA256-check the 0.2.121 CLI. In those jobs, scripts/build.sh lines 11-16 compare the Cargo.lock version (0.2.129) against `wasm-bindgen --version` (0.2.121) and exit 1, so the wasm build fails in CI, in build-wasm, and in the release-please publish job. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and set WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 musl tarball.
Suggested Code:
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.yml
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
|
|
||
| [dependencies] | ||
| wasm-bindgen = "=0.2.121" | ||
| wasm-bindgen = "=0.2.129" |
There was a problem hiding this comment.
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 in a dependency manifest, with no visible vulnerability or supply-chain evidence. WHY: Dependency upgrades need a CVE and supply-chain check, and the Cargo.lock must be updated to match. wasm-bindgen also must stay ABI-paired with js-sys, and the nearby comment still says 0.2.121. HOW: Attach cargo-audit or OSV output for wasm-bindgen 0.2.129 to the PR. Confirm Cargo.lock is updated in the same PR. Update the pairing comment to reference 0.2.129.
Also found in:
packages/cachekit/package.json:99-99packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit/package.json:105-105
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20:
WHAT: wasm-bindgen is bumped from 0.2.121 to 0.2.129 in a dependency manifest, with no visible vulnerability or supply-chain evidence. WHY: Dependency upgrades need a CVE and supply-chain check, and the Cargo.lock must be updated to match. wasm-bindgen also must stay ABI-paired with js-sys, and the nearby comment still says 0.2.121. HOW: Attach cargo-audit or OSV output for wasm-bindgen 0.2.129 to the PR. Confirm Cargo.lock is updated in the same PR. Update the pairing comment to reference 0.2.129.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
ebb0f71 to
2d81dde
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version mismatch in the wasm-bindgen pin (Cargo.toml:20): the crate pins wasm-bindgen =0.2.129, and Cargo.lock also resolves 0.2.129, but WASM_BINDGEN_VERSION in .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still installs CLI 0.2.121. After merge, scripts/build.sh:11-15 compares the CLI version against Cargo.lock and exits with wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129, which fails the Workers lane, the build-wasm workflow and the release wasm artifact step. Fix: set WASM_BINDGEN_VERSION to 0.2.129 and update WASM_BINDGEN_SHA256 to the matching release tarball checksum in all three workflows, and change the stale 0.2.121 reference in the js-sys comment to 0.2.129.
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# Also bump WASM_BINDGEN_VERSION (and WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in the wasm-bindgen pin (Cargo.toml:20): the crate pins wasm-bindgen =0.2.129, and Cargo.lock also resolves 0.2.129, but WASM_BINDGEN_VERSION in .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still installs CLI 0.2.121. After merge, scripts/build.sh:11-15 compares the CLI version against Cargo.lock and exits with `wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129`, which fails the Workers lane, the build-wasm workflow and the release wasm artifact step. Fix: set WASM_BINDGEN_VERSION to 0.2.129 and update WASM_BINDGEN_SHA256 to the matching release tarball checksum in all three workflows, and change the stale 0.2.121 reference in the js-sys comment to 0.2.129.
Suggested Code:
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# Also bump WASM_BINDGEN_VERSION (and WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.yml
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
|
|
||
| [dependencies] | ||
| wasm-bindgen = "=0.2.121" | ||
| wasm-bindgen = "=0.2.129" |
There was a problem hiding this comment.
WHAT: The exact-pinned wasm-bindgen dependency jumps from 0.2.121 to 0.2.129, and this diff shows no CVE or supply-chain check. WHY: wasm-bindgen generates the JS/WASM ABI glue, so an unvetted version jump can bring in vulnerabilities or ABI regressions. HOW: Run cargo audit or an OSV query for wasm-bindgen 0.2.129, attach the output or advisory links to the PR, and make sure Cargo.lock is updated. Also update the comment on line 23, which still says the pin is paired with 0.2.121.
Also found in:
packages/cachekit/package.json:99-99packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit/package.json:105-105
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20:
WHAT: The exact-pinned wasm-bindgen dependency jumps from 0.2.121 to 0.2.129, and this diff shows no CVE or supply-chain check. WHY: wasm-bindgen generates the JS/WASM ABI glue, so an unvetted version jump can bring in vulnerabilities or ABI regressions. HOW: Run `cargo audit` or an OSV query for wasm-bindgen 0.2.129, attach the output or advisory links to the PR, and make sure Cargo.lock is updated. Also update the comment on line 23, which still says the pin is paired with 0.2.121.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
2d81dde to
0f0c61d
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version drift in packages/cachekit-core-wasm/Cargo.toml:20: the wasm-bindgen crate is exact-pinned to 0.2.129, but ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still install the 0.2.121 CLI and verify it against the 0.2.121 tarball checksum. scripts/build.sh:11-15 reads 0.2.129 from Cargo.lock, finds CLI 0.2.121, and exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', so the workers lane, the wasm build, and the release wasm build all fail. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the stale '0.2.121' comment on line 23.
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version drift in packages/cachekit-core-wasm/Cargo.toml:20: the wasm-bindgen crate is exact-pinned to 0.2.129, but ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still install the 0.2.121 CLI and verify it against the 0.2.121 tarball checksum. scripts/build.sh:11-15 reads 0.2.129 from Cargo.lock, finds CLI 0.2.121, and exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', so the workers lane, the wasm build, and the release wasm build all fail. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the stale '0.2.121' comment on line 23.
Suggested Code:
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.yml
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
| }, | ||
| "devDependencies": { | ||
| "@cloudflare/vitest-pool-workers": "0.18.7", | ||
| "@cloudflare/vitest-pool-workers": "0.23.0", |
There was a problem hiding this comment.
WHAT: This bumps @cloudflare/vitest-pool-workers from 0.18.7 to 0.23.0 with no visible vulnerability or supply-chain check. WHY: It skips several minor versions of a test-runtime package that pulls in workerd/miniflare transitively. Unreviewed transitive jumps can bring in new CVEs or unexpected behavior. HOW: Run an OSV/SCA scan or pnpm audit for the new version and attach the output or advisory links to the PR description. Also confirm the root lockfile is updated with the resolved transitive tree.
Also found in:
packages/cachekit-core-wasm/Cargo.toml:20-20packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit/package.json:105-105
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File packages/cachekit/package.json:
Line 99:
WHAT: This bumps @cloudflare/vitest-pool-workers from 0.18.7 to 0.23.0 with no visible vulnerability or supply-chain check. WHY: It skips several minor versions of a test-runtime package that pulls in workerd/miniflare transitively. Unreviewed transitive jumps can bring in new CVEs or unexpected behavior. HOW: Run an OSV/SCA scan or `pnpm audit` for the new version and attach the output or advisory links to the PR description. Also confirm the root lockfile is updated with the resolved transitive tree.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
0f0c61d to
97c6688
Compare
| "pnpm": ">=11.11.0" | ||
| }, | ||
| "packageManager": "pnpm@11.11.0", | ||
| "packageManager": "pnpm@11.28.5", |
There was a problem hiding this comment.
WHAT: The packageManager field in package.json bumps pnpm from 11.11.0 to 11.28.5, and the PR shows no supply-chain or vulnerability evidence. WHY: The package manager runs install scripts and resolves every dependency, so a toolchain jump is a supply-chain change. Unvetted versions can bring in regressions or known CVEs. HOW: Check pnpm@11.28.5 against OSV or the GitHub advisories and review its release notes. Link that evidence in the PR description. If pnpm's lockfile format changed, regenerate pnpm-lock.yaml and commit it in this PR.
Also found in:
packages/cachekit/package.json:99-99packages/cachekit-core-wasm/Cargo.toml:20-20packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit/package.json:105-105
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File package.json:
Line 12:
WHAT: The `packageManager` field in package.json bumps pnpm from 11.11.0 to 11.28.5, and the PR shows no supply-chain or vulnerability evidence. WHY: The package manager runs install scripts and resolves every dependency, so a toolchain jump is a supply-chain change. Unvetted versions can bring in regressions or known CVEs. HOW: Check pnpm@11.28.5 against OSV or the GitHub advisories and review its release notes. Link that evidence in the PR description. If pnpm's lockfile format changed, regenerate pnpm-lock.yaml and commit it in this PR.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is bumped to =0.2.129 (and Cargo.lock now resolves 0.2.129), but CI still downloads the 0.2.121 wasm-bindgen command-line tool in .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254. scripts/build.sh:11-17 compares the Cargo.lock version with wasm-bindgen --version and exits 1 when they differ, so the Workers lane, the wasm build workflow and the release wasm build will all fail with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129". Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and update WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball. Also update the stale "wasm-bindgen 0.2.121" comment on line 23.
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (+ WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.ymlPrompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the wasm-bindgen crate is bumped to =0.2.129 (and Cargo.lock now resolves 0.2.129), but CI still downloads the 0.2.121 wasm-bindgen command-line tool in .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254. scripts/build.sh:11-17 compares the Cargo.lock version with `wasm-bindgen --version` and exits 1 when they differ, so the Workers lane, the wasm build workflow and the release wasm build will all fail with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129". Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and update WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball. Also update the stale "wasm-bindgen 0.2.121" comment on line 23.
Suggested Code:
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION (+ WASM_BINDGEN_SHA256) to 0.2.129 in
# .github/workflows/ci.yml, build-wasm.yml and release-please.yml
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
97c6688 to
e34bab6
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate pins wasm-bindgen =0.2.129, but ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still install wasm-bindgen CLI 0.2.121 via WASM_BINDGEN_VERSION. When scripts/build.sh:11-15 compares the 0.2.121 CLI against the 0.2.129 version in Cargo.lock, it exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', which fails the wasm build, the Workers test lane, and the release publish step. Fix: set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball in all three workflows.
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate pins wasm-bindgen =0.2.129, but ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still install wasm-bindgen CLI 0.2.121 via WASM_BINDGEN_VERSION. When scripts/build.sh:11-15 compares the 0.2.121 CLI against the 0.2.129 version in Cargo.lock, it exits with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', which fails the wasm build, the Workers test lane, and the release publish step. Fix: set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball in all three workflows.
Suggested Code:
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.yml
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
|
|
||
| [dependencies] | ||
| wasm-bindgen = "=0.2.121" | ||
| wasm-bindgen = "=0.2.129" |
There was a problem hiding this comment.
WHAT: The exact-pinned wasm-bindgen dependency jumps from 0.2.121 to 0.2.129. WHY: Dependency manifest changes must come with vulnerability and supply-chain verification, and the matching lockfile must be updated. HOW: Run cargo audit (or an OSV query) for wasm-bindgen 0.2.129 and attach the output to the PR description. Make sure Cargo.lock is updated in the same PR. Also update the stale comment on line 23, which still says the pinned versions pair with 0.2.121.
Also found in:
packages/cachekit-core-wasm/Cargo.toml:24-24
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20:
WHAT: The exact-pinned wasm-bindgen dependency jumps from 0.2.121 to 0.2.129. WHY: Dependency manifest changes must come with vulnerability and supply-chain verification, and the matching lockfile must be updated. HOW: Run cargo audit (or an OSV query) for wasm-bindgen 0.2.129 and attach the output to the PR description. Make sure Cargo.lock is updated in the same PR. Also update the stale comment on line 23, which still says the pinned versions pair with 0.2.121.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
e34bab6 to
7fa880e
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate and Cargo.lock move to wasm-bindgen 0.2.129, but .github/workflows/ci.yml:278, .github/workflows/build-wasm.yml:31, and .github/workflows/release-please.yml:254 still install the 0.2.121 CLI with the checksum for that tarball. When scripts/build.sh (lines 11-17) compares the Cargo.lock version (0.2.129) against wasm-bindgen --version (0.2.121), it exits with status 1, so the Workers CI lane, the wasm build workflow, and the release wasm build all fail. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the SHA-256 of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment on line 23 to reference 0.2.129.
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate and Cargo.lock move to wasm-bindgen 0.2.129, but .github/workflows/ci.yml:278, .github/workflows/build-wasm.yml:31, and .github/workflows/release-please.yml:254 still install the 0.2.121 CLI with the checksum for that tarball. When scripts/build.sh (lines 11-17) compares the Cargo.lock version (0.2.129) against `wasm-bindgen --version` (0.2.121), it exits with status 1, so the Workers CI lane, the wasm build workflow, and the release wasm build all fail. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and WASM_BINDGEN_SHA256 to the SHA-256 of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the comment on line 23 to reference 0.2.129.
Suggested Code:
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 and WASM_BINDGEN_SHA256 in
# .github/workflows/{ci,build-wasm,release-please}.yml
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
| }, | ||
| "devDependencies": { | ||
| "@cloudflare/vitest-pool-workers": "0.18.7", | ||
| "@cloudflare/vitest-pool-workers": "0.23.0", |
There was a problem hiding this comment.
WHAT: The @cloudflare/vitest-pool-workers devDependency jumps from 0.18.7 to 0.23.0, which spans several minor releases of a 0.x package. WHY: In 0.x versions, minor bumps can change behavior. Dependency changes need CVE/SCA review and a matching lockfile update to limit supply-chain risk. HOW: Run an OSV/npm audit check on the new version. Attach the audit output or advisory links to the PR description, and commit the updated root lockfile.
Also found in:
packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit-core-wasm/Cargo.toml:20-20packages/cachekit/package.json:105-105
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File packages/cachekit/package.json:
Line 99:
WHAT: The @cloudflare/vitest-pool-workers devDependency jumps from 0.18.7 to 0.23.0, which spans several minor releases of a 0.x package. WHY: In 0.x versions, minor bumps can change behavior. Dependency changes need CVE/SCA review and a matching lockfile update to limit supply-chain risk. HOW: Run an OSV/npm audit check on the new version. Attach the audit output or advisory links to the PR description, and commit the updated root lockfile.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
7fa880e to
34fbdda
Compare
| wasm-bindgen = "=0.2.129" | ||
| # js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to | ||
| # accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned | ||
| # to the release paired with wasm-bindgen 0.2.121 above. | ||
| js-sys = "=0.3.98" | ||
| js-sys = "=0.3.106" |
There was a problem hiding this comment.
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate is bumped to wasm-bindgen =0.2.129, but CI still installs the 0.2.121 CLI. ci.yml:278, build-wasm.yml:31 and release-please.yml:254 all set WASM_BINDGEN_VERSION: 0.2.121 with the 0.2.121 SHA256. scripts/build.sh:11-17 reads 0.2.129 from Cargo.lock, compares it to the installed CLI, and exits 1 with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129". As a result the CI wasm build, the build-wasm workflow and the release-please publish job all fail, so no wasm artifact can be built or released. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and update WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl release tarball, or add these files to the Renovate group so they are bumped together.
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.ymlPrompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20 to 24:
Version mismatch in packages/cachekit-core-wasm/Cargo.toml: the crate is bumped to wasm-bindgen =0.2.129, but CI still installs the 0.2.121 CLI. ci.yml:278, build-wasm.yml:31 and release-please.yml:254 all set WASM_BINDGEN_VERSION: 0.2.121 with the 0.2.121 SHA256. scripts/build.sh:11-17 reads 0.2.129 from Cargo.lock, compares it to the installed CLI, and exits 1 with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129". As a result the CI wasm build, the build-wasm workflow and the release-please publish job all fail, so no wasm artifact can be built or released. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and update WASM_BINDGEN_SHA256 to the checksum of the 0.2.129 x86_64-unknown-linux-musl release tarball, or add these files to the Renovate group so they are bumped together.
Suggested Code:
wasm-bindgen = "=0.2.129"
# js-sys ships from the wasm-bindgen workspace and tracks its ABI; needed to
# accept Uint8Array[] (previous master keys) across the boundary. Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# NOTE: also bump WASM_BINDGEN_VERSION/WASM_BINDGEN_SHA256 to 0.2.129 in
# .github/workflows/{ci,build-wasm,release-please}.yml
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
|
|
||
| [dependencies] | ||
| wasm-bindgen = "=0.2.121" | ||
| wasm-bindgen = "=0.2.129" |
There was a problem hiding this comment.
WHAT: The exact-pinned wasm-bindgen dependency is bumped from 0.2.121 to 0.2.129. WHY: Dependency manifest changes need supply-chain and CVE validation. wasm-bindgen generates the JS/WASM ABI glue, so a version jump also needs evidence that the Cargo.lock was updated consistently. HOW: Add cargo-audit or OSV scan output (or advisory links) to the PR description, confirm Cargo.lock is updated in this PR, and update the stale comment that still references 0.2.121.
Also found in:
packages/cachekit/package.json:99-99packages/cachekit-core-wasm/Cargo.toml:24-24packages/cachekit/package.json:105-105
Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk
Prompt for LLM
File packages/cachekit-core-wasm/Cargo.toml:
Line 20:
WHAT: The exact-pinned wasm-bindgen dependency is bumped from 0.2.121 to 0.2.129. WHY: Dependency manifest changes need supply-chain and CVE validation. wasm-bindgen generates the JS/WASM ABI glue, so a version jump also needs evidence that the Cargo.lock was updated consistently. HOW: Add cargo-audit or OSV scan output (or advisory links) to the PR description, confirm Cargo.lock is updated in this PR, and update the stale comment that still references 0.2.121.
Talk to Kody by mentioning @kody
Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
1 participant
This PR contains the following updates:
0.18.7→0.23.03.7.2→3.10.82.2.0→2.4.025.9.4→25.9.94.1.9→4.1.120.28.1→0.28.210.5.0→10.12.010.13.0=0.3.98→=0.3.1063.8.4→3.14.22.3.1→2.6.03.5.3→3.6.1211.11.0→11.28.63.8.4→3.9.102.10.0→2.11.82.11.10(+1)8.62.0→8.71.28.72.04.1.11→4.1.12=0.2.121→=0.2.1291.9.0→1.9.1Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
cloudflare/workers-sdk (@cloudflare/vitest-pool-workers)
v0.22.0Compare Source
Minor Changes
#13830
49d4e00Thanks @penalosa! - Mocking requests with MSW in Worker tests now requires MSW >= 2.14@cloudflare/vitest-pool-workerspreviously 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 usingsetupServer()frommsw/node, or adopt the official@msw/cloudflareintegration viasetupNetwork(). See the updatedrequest-mockingexample fixture for the recommended pattern.Patch Changes
#15211
bc5726bThanks @nithin42! - Honoraccess.devwhen running Workers with@cloudflare/vitest-pool-workers, soctx.access.getIdentity()returns the configured identity just as it does withwrangler dev.#15156
3ddd3ceThanks @dario-piotrowicz! - Fix module resolution for relativerequire()inside CJS deps when the project path contains spacesWhen 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" becauseworkerdpreserves URL encoding in the module name. Encoded module paths are now handled deterministically before CommonJS resolution without altering literal percent sequences.#15150
2cf3143Thanks @kkkhs! - Restore typedinject()keys incloudflareTest()pool optionsinject()insidecloudflareTest()options again infers the value type from the keys you declare in your VitestProvidedContext, and reports misspelled keys. For keys that are only provided at runtime, pass an explicit type argument, e.g.inject<number>("myPort").#15232
8777180Thanks @vicb! - Bumpcapnp-esto 0.0.16.#15185
1f79aceThanks @jamesopstad! - Use a fixed default compatibility date rather than the current dateWhen no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date.
workerdonly accepts a compatibility date up to 7 days beyond its own release, so whenever aworkerdrelease 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
workerdversion that ships with each release, which leaves a week of headroom and updates asworkerdis upgraded.@cloudflare/vite-pluginpreviously 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]:v0.21.3Compare Source
Patch Changes
b8fd112,f0f2054,339509d]:v0.21.2Compare Source
Patch Changes
#15123
d0c976cThanks @dependabot! - WidenWorkerPoolOptionsContext.injecttype to avoidProvidedContextmismatchPreviously, calling
inject()insidecloudflareTest()pool options could fail with a type error when your project'sProvidedContextaugmentation wasn't visible to the pool plugin. Theinjectparameter now accepts any string key and is generic (inject<T>(key)), defaulting tounknownwhen no type argument is provided. This lets you opt in to concrete types (e.g.inject<number>("port")) while avoiding the cross-copyProvidedContextmismatch that occurred when pnpm resolved separate virtual-store instances of vitest.#15148
0b82b15Thanks @jamesopstad! - Ignore anodejs_compatcompatibility flag that the compatibility date already enablesworkerd rejects a compatibility flag that its compatibility date enables by default, so a Worker configured with both a compatibility date of
2026-08-04or later andnodejs_compatfailed to start locally with "The compatibility flag nodejs_compat became the default as of 2026-08-04 so does not need to be specified anymore".The redundant
nodejs_compatandnodejs_compat_v2flags are now dropped when starting the runtime, which has no effect on the resulting Worker because the compatibility date enables both anyway.no_nodejs_compatandno_nodejs_compat_v2still switch Node.js compatibility off, and a flag specified alongside its own opt-out is left alone so that workerd still reports those as contradictory.#15123
d0c976cThanks @dependabot! - Detect Node.js compatibility from the compatibility date, now thatnodejs_compatis enabled by defaultAs of compatibility date
2026-08-04, workerd enables thenodejs_compatandnodejs_compat_v2compatibility flags by default. Previously these tools only treated Node.js compatibility as enabled when one of those flags was listed explicitly, so a Worker on a compatibility date of2026-08-04or later without the flag would get Node.js APIs from the runtime but no Node.js polyfills from the bundler, andprocess.envcould be substituted with an empty object at build time. They now resolve these flags the same way workerd does, and honourno_nodejs_compatto opt out.To keep Node.js compatibility switched off on a newer compatibility date, specify both
no_nodejs_compatandno_nodejs_compat_v2, since each flag has its own default.@cloudflare/vitest-pool-workersneedsnodejs_compat_v2for its own test runner, so it continues to override a project that opts out of it. On a compatibility date that enables the flag anyway, it now drops the opt-out rather than adding the flag back, which workerd would reject — previously this stopped such a project from running any tests at all.wrangler typesalso no longer attributes its@types/nodesuggestion to "thenodejs_compatflag", which it can now make for Workers that do not set the flag at all.#15131
90dd5e5Thanks @vicb! - Bumpcapnp-esto 0.0.15.Also re-generate the types for the latest
.capnpfilesUpdated dependencies [
d0c976c,d0c976c,0b82b15,d0c976c,d0c976c,90dd5e5,3b02915]:v0.21.1Compare Source
Patch Changes
#14882
ab9132dThanks @petebacondarwin! - Report built-in modules that a Worker's compatibility settings don't provide as module errors, instead of crashing workerdPreviously, a Worker whose module graph statically reached a compatibility-gated built-in that wasn't enabled — for example
import "node:child_process"withoutnodejs_compat— took down the runtime with*** Received signal #​11: Segmentation faultbefore any test ran. Vitest reported onlyWorker exited unexpectedly, naming neither the module nor the file that imported it, which made the cause very hard to find. The import didn't even have to be called; being reachable from the entrypoint was enough.The module fallback service answered these specifiers with a redirect to the modules root, but workerd already resolves
node:/cloudflare:/workerd:specifiers there, so the redirect pointed back at the module workerd was in the middle of resolving and it recursed until the stack overflowed. Such a specifier only reaches the fallback service when workerd's own registry has already missed, so it's now reported as not found: workerd raisesNo such module "node:child_process", matching whatwrangler devdoes for the same Worker. The accompanying pool error names the module and points at compatibility flags rather than suggesting you bundle it, which can't help for a module built into the runtime.Updated dependencies [
15cad03,026e058,731b33a,e1b5b4b,5b1b930,6e7d37d,d669088,15cad03,c7aede7,0aa8fa5]:v0.21.0Compare Source
Minor Changes
#14994
2194f88Thanks @emily-shen! - Update the Workers Vitest pool for Miniflare's config-based optionsThe Workers Vitest pool now converts the Miniflare options it creates for test sessions to Miniflare's config-based
workersshape.For the most part, users should not expect to notice any changes.
However, auxiliary workers declared in
miniflare.workersthat rely on relative local imports now need those imported modules to be declared explicitly in the migrated module manifest.Patch Changes
6dbd192,2194f88,2194f88,2194f88,2194f88,2194f88,2194f88,2194f88]:v0.20.3Compare Source
Patch Changes
#15013
8cf78c8Thanks @dario-piotrowicz! - Update undici from 7.28.0 to 7.29.0Updated dependencies [
35c87e9,b4f0c97,8cf78c8,a60ff4d,99eb50c,35c87e9]:v0.20.2Compare Source
Patch Changes
20470fa,9c74538,266172b,a88d169,a88d169,daf65f2,a9e5abb]:v0.20.1Compare Source
Patch Changes
cc63aae,f92d1fc,a249591,f92d1fc,f92d1fc,cec9d88,e0bbf55]:v0.20.0Compare Source
Minor Changes
#14586
5a56ddaThanks @emily-shen! - Breaking change: Remove several options from theminiflareoverride optionsThe following options have been removed from the
miniflareoverride options, as they were not intended to be exposed, were not functional, or have been superseded by other options:wrappedBindingscacheWarnUsagefetchMock: you should useoutboundServiceinsteadcontainerEngine: containers were not supported in vitest-pool-workers. Consider usingcreateTestHarness()instead if you want to test against actual containers.Additionally,
cachehas been deprecated and renamed tocacheAPI, butcacheremains functional.Patch Changes
#14586
5a56ddaThanks @emily-shen! - Preserve the deprecated MiniflarecacheoptionVitest configurations using
cachecontinue to work after the internal Miniflare v5 upgrade. The option is translated tocacheAPI; new configurations should usecacheAPIdirectly.#14586
5a56ddaThanks @emily-shen! - Stop enabling Miniflare's removedunsafeStickyBlobsoptionThe pool no longer sets the
unsafeStickyBlobsMiniflare option, which has been removed. This option was only needed for the Durable Object isolated storage feature that was dropped in 0.13.0, so there is no change in behaviour.Updated dependencies [
5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda,5a56dda]:v0.19.1Compare Source
Patch Changes
01d7020,beec0fb,48f0c6c,8049ca4,d7f38c3,1394867,cc54478,5c25cfe,b21eac2,bb09f1b,1f61001,01d7020,e31ab0f]:v0.19.0Compare Source
Minor Changes
#14879
e6480e3Thanks @dmmulroy! - Add averboseoption tocloudflareTest()andcloudflarePool()configurationSet
verbose: falseto suppress verbose workerd runtime logs, such as caught Durable Object RPC errors. The option defaults totrueto preserve existing output.Patch Changes
#14821
edc203eThanks @mishushakov! - Ignore workerd'sdisconnected: peer disconnected without gracefully ending TLS sessionexception logsWhen tests make real
fetch()calls to external TLS endpoints, servers and load balancers routinely close idle keepalive connections without sending a TLSclose_notify. No request fails — the connection is idle — but workerd logs akj/compat/tls.c++exception with a full stack trace each time, flooding otherwise green test runs. This is the TLS sibling of thedisconnected: ...messages already in the ignore list, so filter it the same way.Updated dependencies [
773ead4,773ead4,09b8a44,4dfb96e,1035f74,e426cb9,3a22ae5,465c0fb,465c0fb,e8b3a9d,552bcfc,b737676,6e0bf6e]:v0.18.8Compare Source
Patch Changes
#14793
7b3fea6Thanks @trafgals! - Prevent worker disposal errors from failing otherwise successful test runsErrors raised while disposing test Workers are now logged for diagnostics rather than overriding the test result. Set
NODE_DEBUG=vitest-pool-workersto view these errors.Updated dependencies [
246ce92,c38a2c3,8416b33,c079ba3,4683ff8,95b026e,02232f3,c4bacec,f8a8c2c,3203b5d]:napi-rs/napi-rs (@napi-rs/cli)
v3.10.8Compare Source
What's Changed
New Contributors
Full Changelog: https://github.com/napi-rs/napi-rs/compare/napi-async-runtime-v0.2.5...@napi-rs/cli@3.10.8
v3.10.7Compare Source
What's Changed
New Contributors
Full Changelog: https://github.com/napi-rs/napi-rs/compare/napi-async-runtime-v0.2.4...@napi-rs/cli@3.10.7
v3.10.6Compare Source
v3.10.5Compare Source
v3.10.4Compare Source
v3.10.3Compare Source
v3.10.2Compare Source
v3.10.1Compare Source
v3.10.0Compare Source
v3.9.1Compare Source
Patch over 3.9.0.
Fixes
WASI threads builds on current toolchains (#3492)
wasm32-wasip1-threadswas failing in two ways: wasi-sdk 34 changed the futex ABI, and Rust nightly started linkingcrt1-reactor.oitself (duplicate_initialize). The CLI now picks the matching emnapi archive; the build crate stops double-linking_initialize.WASI on Android / Termux (#3485)
Generated Node loaders preopened
/, which Termux cannot open (UVWASI_EACCES). Android now preopens the current working directory. Other platforms are unchanged.Generated files share one format (#3501)
JSON / TOML / YAML,
.d.ts, and JS / WASI loaders now use one house style (indent, trailing newline, quotes). Regenerating bindings may produce noisy diffs with no behavior change.Deps
js-yaml4 → 5 (#3344) — YAML dump formatting can change; loaded values should not.Same-day packages
@napi-rs/triples@napi-rs/wasm-runtimev3.9.0Compare Source
v3.8.6Compare Source
v3.8.5Compare Source
v3.8.4Compare Source
v3.8.3Compare Source
v3.8.2Compare Source
v3.8.1Compare Source
v3.8.0Compare Source
v3.7.4Compare Source
v3.7.3Compare Source
paulmillr/noble-hashes (@noble/hashes)
v2.4.0Compare Source
Security and correctness
Misc
t: 3,m: 1024 ** 2KiB (1 GiB),p: 1,dkLen: 32, and a 1 GiBmaxmemlimit; larger-memory calls must setmaxmemexplicitly.maxmemto work forN: 2 ** 20,r: 8, andp: 1nextTickandasyncLoopnow yield throughscheduler.yield()when available orsetTimeoutotherwise, allowing timers, I/O, and rendering to progress. They also accept optional rejection cleanup; async Argon2, PBKDF2, and scrypt use it to wipe work state if scheduling is aborted.v2.3.0Compare Source
Performance
Other changes
HMAC._cloneIntoso it preservescanXOFin issue #134, reported by @ChALkeR, and corrected an Argon2d typo in issue #135.blake2.compressto the internal_compressmethod.vitest-dev/vitest (@vitest/coverage-v8)
v4.1.12Compare Source
🐞 Bug Fixes
View changes on GitHub
v4.1.11Compare Source
🐞 Bug Fixes
View changes on GitHub
v4.1.10Compare Source
🐞 Bug Fixes
View changes on GitHub
evanw/esbuild (esbuild)
v0.28.2Compare Source
Fix tree shaking bug due to TypeScript import alias (#4507)
This release fixes a bug that could cause esbuild to incorrectly tree-shake imports that are used in a TypeScript type alias under certain circumstances. Affected code uses a TypeScript-specific
importassignment and looks something like this:Fix CSS minification bug involving
&(#4497)This release fixes a bug where esbuild's CSS minifier incorrectly removed a
&when it was unsafe to do so. Here is an example:This should match
<span class="a"><span class="b"><span class="b">yes</span></span></span>but not<span class="a"><span class="b">no</span></span>. The old output incorrectly matched both.Avoid overwriting input files without
--allow-overwrite(#4484)For example:
esbuild input.js --outfile=input.jstells esbuild to overwriteinput.jswith the output of running esbuild on it. This was supposed to already be prevented by default, but it accidentally regressed in version 0.17.0 and apparently didn't have any test coverage. The error message was being printed but the input file was still being overwritten. Oops.This release puts the original behavior back. With this release, esbuild should now actually avoid overwriting input files unless `--allow-ove
Configuration
📅 Schedule: (in timezone Australia/Sydney)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ 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 has been generated by Mend Renovate.