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:
|
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:
|
f6afba7 to
08f7897
Compare
| "pnpm": ">=11.11.0" | ||
| }, | ||
| "packageManager": "pnpm@11.11.0", | ||
| "packageManager": "pnpm@11.28.4", |
There was a problem hiding this comment.
WHAT: The pinned package manager in package.json moves from pnpm@11.11.0 to pnpm@11.28.4.
WHY: Corepack downloads and runs this exact tool version in CI and on dev machines, so the bump is a supply-chain change. Without checking release notes and advisories, a vulnerable or tampered release could slip in, or lockfile behavior could change unexpectedly.
HOW: Before merging:
- Check pnpm@11.28.4 for known CVEs (OSV/SCA query or GitHub advisories) and link the results in the PR description.
- Verify the version is an official release, ideally pinning it with an integrity hash (e.g. "pnpm@11.28.4+sha512.").
- Regenerate and commit pnpm-lock.yaml if the lockfile format or resolution changed.
Also found in:
packages/cachekit-core-wasm/Cargo.toml:20-20packages/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 package.json:
Line 12:
WHAT: The pinned package manager in package.json moves from pnpm@11.11.0 to pnpm@11.28.4.
WHY: Corepack downloads and runs this exact tool version in CI and on dev machines, so the bump is a supply-chain change. Without checking release notes and advisories, a vulnerable or tampered release could slip in, or lockfile behavior could change unexpectedly.
HOW: Before merging:
- Check pnpm@11.28.4 for known CVEs (OSV/SCA query or GitHub advisories) and link the results in the PR description.
- Verify the version is an official release, ideally pinning it with an integrity hash (e.g. "pnpm@11.28.4+sha512.<hash>").
- Regenerate and commit pnpm-lock.yaml if the lockfile format or resolution changed.
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 drift in packages/cachekit-core-wasm/Cargo.toml: the crate pins wasm-bindgen to =0.2.129 (Cargo.lock resolves 0.2.129), but ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still install wasm-bindgen CLI 0.2.121 and verify it against a 0.2.121 SHA-256. scripts/build.sh:11-15 compares the Cargo.lock version with wasm-bindgen --version, so the Workers CI lane, the tag-triggered wasm build and the release wasm build all exit 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 replace WASM_BINDGEN_SHA256 with the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the line 23 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"
# 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 drift in packages/cachekit-core-wasm/Cargo.toml: the crate pins wasm-bindgen to =0.2.129 (Cargo.lock resolves 0.2.129), but ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still install wasm-bindgen CLI 0.2.121 and verify it against a 0.2.121 SHA-256. scripts/build.sh:11-15 compares the Cargo.lock version with `wasm-bindgen --version`, so the Workers CI lane, the tag-triggered wasm build and the release wasm build all exit 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 replace WASM_BINDGEN_SHA256 with the checksum of the 0.2.129 x86_64-unknown-linux-musl tarball, and update the line 23 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"
# 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:
|
08f7897 to
ed8299d
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/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121 with the matching 0.2.121 WASM_BINDGEN_SHA256. scripts/build.sh:11-16 compares the Cargo.lock version against wasm-bindgen --version and exits 1 on mismatch, so the CI wasm job, the build-wasm workflow and the release-please wasm publish step 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 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/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: wasm-bindgen is pinned to =0.2.129 (and Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121 with the matching 0.2.121 WASM_BINDGEN_SHA256. scripts/build.sh:11-16 compares the Cargo.lock version against `wasm-bindgen --version` and exits 1 on mismatch, so the CI wasm job, the build-wasm workflow and the release-please wasm publish step 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 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/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.
| }, | ||
| "devDependencies": { | ||
| "@cloudflare/vitest-pool-workers": "0.18.7", | ||
| "@cloudflare/vitest-pool-workers": "0.22.0", |
There was a problem hiding this comment.
WHAT: The dependency @cloudflare/vitest-pool-workers jumps from 0.18.7 to 0.22.0 with no supply-chain validation evidence. WHY: Dependency manifest changes need CVE and supply-chain review. In a 0.x package, a jump across several minor versions may also bring breaking changes and transitive dependency shifts. HOW: Run an OSV/SCA audit (e.g., npm audit or osv-scanner) for the new version. Attach the results or advisory links to the PR description, and confirm the root lockfile is updated.
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: The dependency @cloudflare/vitest-pool-workers jumps from 0.18.7 to 0.22.0 with no supply-chain validation evidence. WHY: Dependency manifest changes need CVE and supply-chain review. In a 0.x package, a jump across several minor versions may also bring breaking changes and transitive dependency shifts. HOW: Run an OSV/SCA audit (e.g., `npm audit` or osv-scanner) for the new version. Attach the results or advisory links to the PR description, and confirm the root lockfile is updated.
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:
|
ed8299d to
fc4c510
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 (matching Cargo.lock), but .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still set WASM_BINDGEN_VERSION to 0.2.121 with the old WASM_BINDGEN_SHA256. Because scripts/build.sh:11-16 exits 1 when the CLI version differs from the Cargo.lock version, the 'Workers lane' CI job, the tag-triggered wasm release build, and the release-please wasm build all fail with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', so the wasm artifact cannot be built or published. 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 release tarball, and update the line 23 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"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 (+ 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 mismatch in packages/cachekit-core-wasm/Cargo.toml: wasm-bindgen is pinned to =0.2.129 (matching Cargo.lock), but .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254 still set WASM_BINDGEN_VERSION to 0.2.121 with the old WASM_BINDGEN_SHA256. Because scripts/build.sh:11-16 exits 1 when the CLI version differs from the Cargo.lock version, the 'Workers lane' CI job, the tag-triggered wasm release build, and the release-please wasm build all fail with 'wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129', so the wasm artifact cannot be built or published. 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 release tarball, and update the line 23 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"
# NOTE: also bump WASM_BINDGEN_VERSION=0.2.129 (+ 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.
|
|
||
| [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 visible vulnerability or supply-chain check. WHY: Dependency manifest changes must be validated for known CVEs and risky transitive changes. wasm-bindgen generates the JS/WASM ABI glue, so its supply-chain integrity matters. 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 it 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: wasm-bindgen is bumped from 0.2.121 to 0.2.129 with no visible vulnerability or supply-chain check. WHY: Dependency manifest changes must be validated for known CVEs and risky transitive changes. wasm-bindgen generates the JS/WASM ABI glue, so its supply-chain integrity matters. 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 it 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:
|
fc4c510 to
b5083d2
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 (matching Cargo.lock), but WASM_BINDGEN_VERSION is still 0.2.121 in .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254. scripts/build.sh (lines 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.129', which fails the CI wasm job, the build-wasm workflow, and the release pipeline. Fix: set WASM_BINDGEN_VERSION to 0.2.129 in all three workflows, and change the stale 0.2.121 reference in the comment on line 23 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"
# NOTE: also bump WASM_BINDGEN_VERSION 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: wasm-bindgen is pinned to =0.2.129 (matching Cargo.lock), but WASM_BINDGEN_VERSION is still 0.2.121 in .github/workflows/ci.yml:278, build-wasm.yml:31, and release-please.yml:254. scripts/build.sh (lines 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.129', which fails the CI wasm job, the build-wasm workflow, and the release pipeline. Fix: set WASM_BINDGEN_VERSION to 0.2.129 in all three workflows, and change the stale 0.2.121 reference in the comment on line 23 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"
# NOTE: also bump WASM_BINDGEN_VERSION 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.
| }, | ||
| "devDependencies": { | ||
| "@cloudflare/vitest-pool-workers": "0.18.7", | ||
| "@cloudflare/vitest-pool-workers": "0.22.0", |
There was a problem hiding this comment.
WHAT: The devDependency @cloudflare/vitest-pool-workers jumps from 0.18.7 to 0.22.0, which spans several minor releases.
WHY: Dependency changes need a CVE and supply-chain check. A jump this size can bring in new transitive dependencies and breaking behavior in the test runtime.
HOW: Run an OSV/SCA scan or npm audit/pnpm audit on the new version and attach the output or advisory links to the PR description. Confirm the root lockfile is updated with this bump.
Also found in:
packages/cachekit-core-wasm/Cargo.toml:20-20packages/cachekit/package.json:105-105packages/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/package.json:
Line 99:
WHAT: The devDependency @cloudflare/vitest-pool-workers jumps from 0.18.7 to 0.22.0, which spans several minor releases.
WHY: Dependency changes need a CVE and supply-chain check. A jump this size can bring in new transitive dependencies and breaking behavior in the test runtime.
HOW: Run an OSV/SCA scan or `npm audit`/`pnpm audit` on the new version and attach the output or advisory links to the PR description. Confirm the root lockfile is updated with this bump.
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:
|
b5083d2 to
b0c9817
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 line 20: the wasm-bindgen crate pin and Cargo.lock (line 861) are now 0.2.129, but .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION to 0.2.121 and verify WASM_BINDGEN_SHA256 against the 0.2.121 tarball. When the Workers lane, build-wasm or the release job runs, scripts/build.sh:11-15 compares the Cargo.lock version (0.2.129) with the installed CLI (0.2.121), prints error: wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129 and exits, breaking the wasm artifact build, the workerd test lane and the published wasm package. 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"
# AND in .github/workflows/{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 mismatch in packages/cachekit-core-wasm/Cargo.toml line 20: the wasm-bindgen crate pin and Cargo.lock (line 861) are now 0.2.129, but .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION to 0.2.121 and verify WASM_BINDGEN_SHA256 against the 0.2.121 tarball. When the Workers lane, build-wasm or the release job runs, scripts/build.sh:11-15 compares the Cargo.lock version (0.2.129) with the installed CLI (0.2.121), prints `error: wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129` and exits, breaking the wasm artifact build, the workerd test lane and the published wasm package. 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"
# AND in .github/workflows/{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.
| }, | ||
| "devDependencies": { | ||
| "@cloudflare/vitest-pool-workers": "0.18.7", | ||
| "@cloudflare/vitest-pool-workers": "0.22.0", |
There was a problem hiding this comment.
WHAT: The devDependency @cloudflare/vitest-pool-workers jumps from 0.18.7 to 0.22.0, several minor versions in a 0.x package. WHY: In 0.x releases, minor bumps can carry breaking changes and pull in different transitive dependencies such as wrangler, miniflare and workerd. This adds supply-chain and CVE risk that has not been reviewed. HOW: Run an OSV/SCA scan or npm audit for the new version and attach the output or advisory links to the PR description. Confirm the root lockfile is updated with the resolved transitive tree, and check the changelog for breaking changes.
Also found in:
packages/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 devDependency @cloudflare/vitest-pool-workers jumps from 0.18.7 to 0.22.0, several minor versions in a 0.x package. WHY: In 0.x releases, minor bumps can carry breaking changes and pull in different transitive dependencies such as wrangler, miniflare and workerd. This adds supply-chain and CVE risk that has not been reviewed. HOW: Run an OSV/SCA scan or `npm audit` for the new version and attach the output or advisory links to the PR description. Confirm the root lockfile is updated with the resolved transitive tree, and check the changelog for breaking changes.
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:
|
b0c9817 to
4c5a6ac
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 Cargo.toml: the wasm-bindgen crate is now pinned to =0.2.129 (Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121 with its SHA256. scripts/build.sh:11-17 compares the Cargo.lock version with the wasm-bindgen --version output and exits 1 when they differ. Every CI wasm build and the release-please publish job therefore fail with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129". Bypassing the guard would also produce glue code whose ABI does not match the module, which fails at runtime. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and update WASM_BINDGEN_SHA256 to the 0.2.129 musl tarball's checksum. Also change the comment on line 23 to say 0.2.129.
wasm-bindgen = "=0.2.129"
# ... Exact-pinned
# to the release paired with wasm-bindgen 0.2.129 above.
js-sys = "=0.3.106"
# AND update WASM_BINDGEN_VERSION to 0.2.129 (plus the matching WASM_BINDGEN_SHA256 of the 0.2.129 x86_64-unknown-linux-musl tarball) 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 Cargo.toml: the wasm-bindgen crate is now pinned to =0.2.129 (Cargo.lock resolves 0.2.129), but .github/workflows/ci.yml:278, build-wasm.yml:31 and release-please.yml:254 still set WASM_BINDGEN_VERSION: 0.2.121 with its SHA256. scripts/build.sh:11-17 compares the Cargo.lock version with the `wasm-bindgen --version` output and exits 1 when they differ. Every CI wasm build and the release-please publish job therefore fail with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129". Bypassing the guard would also produce glue code whose ABI does not match the module, which fails at runtime. Fix: in all three workflows, set WASM_BINDGEN_VERSION to 0.2.129 and update WASM_BINDGEN_SHA256 to the 0.2.129 musl tarball's checksum. Also change the comment on line 23 to say 0.2.129.
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"
# AND update WASM_BINDGEN_VERSION to 0.2.129 (plus the matching WASM_BINDGEN_SHA256 of the 0.2.129 x86_64-unknown-linux-musl tarball) 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.22.0", |
There was a problem hiding this comment.
WHAT: The dependency @cloudflare/vitest-pool-workers is bumped from 0.18.7 to 0.22.0 with no CVE or supply-chain evidence. WHY: Dependency manifest changes must be checked for known vulnerabilities and risky transitive jumps, and a jump across several minor versions can pull in significant transitive changes. HOW: Run an OSV/SCA scan or npm audit for the new version, attach the result to the PR description, and confirm the root lockfile is updated.
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: The dependency @cloudflare/vitest-pool-workers is bumped from 0.18.7 to 0.22.0 with no CVE or supply-chain evidence. WHY: Dependency manifest changes must be checked for known vulnerabilities and risky transitive jumps, and a jump across several minor versions can pull in significant transitive changes. HOW: Run an OSV/SCA scan or `npm audit` for the new version, attach the result to the PR description, and confirm the root lockfile is updated.
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:
|
4c5a6ac to
b8e0c26
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 also resolves 0.2.129), but CI still installs CLI 0.2.121 via WASM_BINDGEN_VERSION: 0.2.121 in .github/workflows/build-wasm.yml:31, ci.yml:278, and release-please.yml:254, with the 0.2.121 tarball SHA-256 in build-wasm.yml:35. When scripts/build.sh (lines 11-15) compares the Cargo.lock version against wasm-bindgen --version, it exits with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129", so the build-wasm job, the CI wasm lane, 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 reference in 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 (0.2.129) and WASM_BINDGEN_SHA256 in
# .github/workflows/build-wasm.yml, ci.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 pinned to =0.2.129 (Cargo.lock also resolves 0.2.129), but CI still installs CLI 0.2.121 via `WASM_BINDGEN_VERSION: 0.2.121` in .github/workflows/build-wasm.yml:31, ci.yml:278, and release-please.yml:254, with the 0.2.121 tarball SHA-256 in build-wasm.yml:35. When `scripts/build.sh` (lines 11-15) compares the Cargo.lock version against `wasm-bindgen --version`, it exits with "wasm-bindgen CLI 0.2.121 != pinned crate version 0.2.129", so the build-wasm job, the CI wasm lane, 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 reference in 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 (0.2.129) and WASM_BINDGEN_SHA256 in
# .github/workflows/build-wasm.yml, ci.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.
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:
|
1 participant
This PR contains the following updates:
0.18.7→0.22.00.23.03.7.2→3.10.82.2.0→2.4.025.9.4→25.9.94.1.9→4.1.110.28.1→0.28.210.5.0→10.12.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.53.8.4→3.9.93.9.102.10.0→2.11.78.62.0→8.71.1=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.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-overwriteis explicitly present. This is done by not writing out any files when a build error is encountered.Fix incorrect code generated when using top-level await (#4498)
Previously esbuild could generate code containing a syntax error in complex scenarios involving top-level await used in a dependency cycle. The problem was a missing
asyncon one or more module wrapper closures. With this release, esbuild now uses a fixed-point iteration algorithm to correctly annotate all dependencies in the cycle as needing anasyncmodule wrapper.Fix a minification bug with lowered logical assignment operators (#4508)
This release fixes a bug that could cause esbuild to generate incorrect code for logical assignment operators when lowering them to an older target environment. Specifically the lowering process requires duplicating the left-hand side, but esbuild incorrectly failed to count the d
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.