-
Notifications
You must be signed in to change notification settings - Fork 4.7k
bake: validate app.bundlerOptions and its subfields are objects
#30409
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.
🔴 When
minifyis the booleanfalse, this enters theisBoolean()branch, skips the innerif (asBoolean())block, and breaks withminify_syntax/minify_identifiers/minify_whitespacestillnull— so in production (bake.zig:792-794doesorelse (mode != .development)) an explicitminify: falseis silently ignored and minification stays on. This is technically pre-existing release-build behavior, but since this PR is rewriting these exact lines to "fix the minify handling" it's the right place to also fix the semantic: drop the inner guard and assignminify_options.asBoolean()to all three fields (matchingJSBundler.zig:694-698).Extended reasoning...
What the bug is
BuildConfigSubset.fromJSparsesapp.bundlerOptions.{server,client,ssr}.minify. After this PR the boolean path is:When the user passes
minify: false,isBoolean()is true so we enter the outer branch, butasBoolean()is false so we skip the assignments andbreak :brk. The three?boolfields onBuildConfigSubsetkeep their default value ofnull.Code path that triggers it
production.zig:238-241callsframework.initTranspilerWithOptions(..., .production_static, ..., options.bundler_options.server.minify_whitespace, options.bundler_options.server.minify_syntax, options.bundler_options.server.minify_identifiers)(and likewise forclient/ssr).bake.zig:792-794:mode = .production_static,null orelse (mode != .development)evaluates totrue.So
app.bundlerOptions.server.minify = false(andclient/ssr) produces a fully-minified production build.Why existing code doesn't prevent it
Nothing else writes these fields. The
null→ default fallback ininitTranspilerWithOptionsis intentional for the unset case, but here the user explicitly set a value and we dropped it. Note that the object form works correctly —minify: { whitespace: false, syntax: false, identifiers: false }reaches thegetBooleanLoosecalls and sets the fields tofalse, so the boolean shorthand is now inconsistent with the long form.Step-by-step proof
Config:
fromJSseesminify_options= JSfalse.minify_options.isBoolean()→true, enter branch.minify_options.asBoolean()→false, skip inner block.break :brk→options.minify_whitespace == null,options.minify_syntax == null,options.minify_identifiers == null.production.zig:239passes those threenulls intoinitTranspilerWithOptions.bake.zig:792-794:null orelse (.production_static != .development)→null orelse true→true.minify_syntax = minify_identifiers = minify_whitespace = true. The user'sminify: falsewas a no-op.Impact
Users who try to disable minification for a Bake production build via the boolean shorthand get minified output anyway, with no error or warning. The only escape hatches are the object form or
--debug-disable-minify(production.zig:244-248). This is surprising because every otherminifyparser in the repo honorsfalse.Relationship to this PR / pre-existing behavior
In release builds the old code had the same net effect: the old condition was
if (minify_options.isBoolean() and minify_options.asBoolean()), which was false forminify: false, and execution then fell through togetBooleanLoose(global, "whitespace")on a boolean primitive —false.whitespaceisundefined, so the fields stayednull. So the semantic bug pre-dates this PR.However, this PR explicitly restructures these exact lines and the description says it "fixes the
minifyhandling to correctly break out of the block whenminify: falseis passed." It fixes the debug assert (good) but preserves the semantic no-op. Since the author is already rewriting this hunk and the correct behavior is well-established elsewhere, this is the right PR to fix it rather than leaveminify: falsehalf-broken.Fix
Drop the inner guard and assign the boolean to all three fields, matching
JSBundler.zig:694-698,JSTranspiler.zig, andbunfig.zig:(Equivalently, add an
elsethat sets all three tofalse.)