fix: Update private-kernel-lib tests for bounded vec change#21907
Merged
Conversation
2 tasks
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Mar 23, 2026
…1909) ## Summary - Pin `typescript@^5.3.3` in docs examples validation to match `yarn-project`. The unpinned `yarn add -D typescript` started pulling TypeScript 6.0, which changed JSON import type inference and made existing `@ts-expect-error` directives unused (TS2578 errors), breaking `example_swap` type-checking. - Use git state (`git show HEAD:...`) instead of filesystem state (`-s`) for yarn.lock emptiness check. When `example_swap` fails, GNU parallel's `--halt now,fail=1` kills other jobs mid-`yarn add` before cleanup traps run, leaving lockfiles dirty on disk. On retry, the check found dirty filesystem state and reported the misleading `token_bridge/yarn.lock is not empty` error. ## Context Multiple unrelated PRs (#21865, #21907, #21812) are failing with: ``` ERROR: token_bridge/yarn.lock is not empty. These files must be committed empty. ``` Root cause chain: 1. `yarn add -D typescript` (unpinned) pulls TS 6.0, released today 2. TS 6.0 improved JSON import type inference, making `@ts-expect-error` directives unused → TS2578 errors in `example_swap` 3. `example_swap` fails → `--halt now,fail=1` kills `token_bridge` mid-`yarn add` → cleanup trap never runs 4. Retry finds dirty `token_bridge/yarn.lock` on filesystem → misleading error ## Test plan - [ ] CI passes on this PR (docs examples validation succeeds) - [ ] Verify `example_swap` and `token_bridge` type-check cleanly with pinned TS 5.x 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
noir-lang/noir#11679 in the Noir compiler removes zeroing of BoundedVec elements past the length of the bounded vec. It is a potential footgun: due to the behavior of
BoundedVec::eqpreviously checking these elements past the length, it meant that when returned from an unconstrained function, users also needed to constrain past-the-length elements, but this was not done in practice.4 tests in private-kernel-lib are breaking with this change, I've edited them to manually create a Vec where each element past the length is zeroed instead.