-
Notifications
You must be signed in to change notification settings - Fork 4.7k
fix(bake): validate app.bundlerOptions values are objects #30653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 This assertion is ineffective:
.not.toThrow("reached unreachable code")passes when a different error is thrown, and this config (missingframework) will throw'app' is missing 'framework'right after bundlerOptions parsing — so the test passes for the wrong reason and would still pass if theminify: falsefix were reverted. CLAUDE.md also explicitly forbids tests that check for absence of panic messages. Assert the expected error instead, e.g..toThrow("'app' is missing 'framework'"), which proves execution got past minify parsing.Extended reasoning...
What the bug is
The new test
'minify as false does not crash'asserts:This violates the explicit rule in the repo's CLAUDE.md (line ~126): "NEVER write tests that check for no 'panic' or 'uncaught exception' or similar in the test output. These tests will never fail in CI." The string
"reached unreachable code"is the panic message produced bybun.debugAssert— i.e. exactly the kind of negative-panic check the guidelines forbid.Why the assertion is ineffective
There are two independent reasons this test cannot catch a regression of the
minify: falsefix:.not.toThrow(<msg>)passes on a different error. Per Jest/Bun semantics,.not.toThrow("X")passes if the callback throws nothing or throws an error whose message does not contain"X". It only fails if the callback throws an error containing"X".A debug-build panic isn't a catchable JS error. The original failure was
bun.debugAssertinsideJSValue.get(), which aborts the process. An in-processexpect().not.toThrow()cannot observe a process abort — the test runner just dies. And in release builds,debugAssertis compiled out entirely.The specific code path that hides the regression
Looking at
UserOptions.fromJSinsrc/bake/bake.zig, afterbundlerOptionsis parsed the very next step is:The test config
{ app: { bundlerOptions: { server: { minify: false } } } }has noframeworkkey, soserve()will throw'app' is missing 'framework'. That error message does not contain"reached unreachable code", so.not.toThrow("reached unreachable code")passes.Step-by-step proof that the test passes even if the fix is reverted
Suppose the minify handling is reverted to the buggy form (
isBoolean() and asBoolean()falling through to property reads onfalse):JSValue.get()hitsbun.debugAssert(target.isObject())and the process aborts. No JS error is thrown; the test file simply crashes (which CLAUDE.md notes does not reliably fail CI). The.not.toThrow(...)assertion never gets to evaluate a thrown error.bun.debugAssertis a no-op.get("whitespace")etc. on the JS valuefalseeither returns nothing useful or proceeds; eventually execution reaches theframeworkcheck and throws'app' is missing 'framework'..not.toThrow("reached unreachable code")→ passes.In neither build does the assertion fail. The test therefore provides zero regression coverage for the bug it was written to guard against.
Impact
This is a test-quality issue rather than a production bug, but it ships a permanently-green test that gives false confidence. If the
minify: falsehandling regresses, this test will not catch it.How to fix
Change the assertion to positively verify that bundlerOptions parsing succeeded and execution reached the next validation step:
This proves
minify: falsewas accepted (no panic, no"Expected minify to be a boolean or an object"error) and parsing continued to the framework check. Alternatively, supply a validframeworkand assert it does not throw at all — but asserting the specific downstream error is the simplest change that turns this into an effective regression test.