[robobun]

Problem

• The CSS printer puts a stray space in front of not in @supports conditions, in both normal and --minify output:
  • @supports not (display: grid) {} prints as @supports not (display: grid){} (two spaces)
  • @supports (a) and (not (b)) {} prints as ... and ( not (b))
  • @import url(x.css) supports(not (a)); prints as supports( not (a))
  • the @supports wrapper the bundler generates for a bundled @import ... supports(not (a)) has the same two spaces
• Cause: SupportsCondition::to_css (src/css/rules/supports.rs:153) writes " not " for the Not variant, but every site that can precede a condition already writes its own separator: SupportsRule::to_css writes "@supports ", to_css_with_parens_if_needed writes the grouping (, and the @import printer writes " supports(".
• @media not ... and @container not ... already print correctly; their shared printer in src/css/media_query.rs writes "not ".

Fix

• Write "not " instead of " not ". The comment in media_query.rs that cited the " not " contract as a reason SupportsCondition is printed separately is deleted, since that reason no longer exists.
• Correct because the Not variant is only ever printed from those three call sites, each of which has already emitted the separator, and needs_parens always returns true for Not, so a Not nested in and/or/not is always preceded by (. The output now matches lightningcss (1.30.2) byte for byte for every input in the tests.
• Verified:
  • test/js/bun/css/css.test.ts, new supports block (after media, where css: parse (property: value) @supports conditions as declarations and merge same-condition rules #38589 and css: merge adjacent @supports rules with the same condition instead of dropping the later one #33680 also add theirs, so whichever lands later folds its cases into the one block on rebase): 14 minify round trips covering @supports not, not over selector(), not over an and/or group, not (not ...), not as either operand of and/or, and @import ... supports(not ...) with and without a media list. All 14 fail on the released bun with the stray space as the only difference, and pass with this change. The declarations in these inputs are written pre-minified ((display:grid)) so the expectations do not change when css: parse (property: value) @supports conditions as declarations and merge same-condition rules #38589 starts minifying them.
  • test/bundler/esbuild/css.test.ts, css/CSSAtSupportsNotCondition: exact (not whitespace insensitive) comparison of non-minified bundler output covering an @supports not rule, the wrapper generated for a bundled conditional @import, and a supports(not ...) clause on an external @import. Fails before, passes after.
  • Full test/js/bun/css/css.test.ts and test/bundler/esbuild/css.test.ts pass with the debug build; no existing test or snapshot depended on the old spacing.
• Deliberately not included here, because they are separate bugs in the same printer with their own fixes:
  • parenthesized (property: value) conditions are kept as raw text instead of being parsed as declarations, and declaration_to_css drops the vendor prefix of a prefixed declaration (supports(-webkit-mask: none) prints as supports((mask:none))): both fixed by css: parse (property: value) @supports conditions as declarations and merge same-condition rules #38589.
  • #[derive(ToCss)] structs write a separator after a None field, so align-items:center minifies to align-items: center: a separate fix is being prepared.
• Related open PRs touching @supports: css: keep scanning an @supports condition after a nested block #38552 (parser, scanning past nested blocks), css: parse (property: value) @supports conditions as declarations and merge same-condition rules #38589 (declaration conditions), css: merge adjacent @supports rules with the same condition instead of dropping the later one #33680 (merging same-condition rules). The source change here is independent of all three and merges cleanly with each; only the test block overlaps with css: parse (property: value) @supports conditions as declarations and merge same-condition rules #38589 and css: merge adjacent @supports rules with the same condition instead of dropping the later one #33680, as described above.

Background

• SupportsCondition (src/css/rules/supports.rs) is the parsed form of a <supports-condition>, used by both the @supports rule and the supports() clause of @import. It is a tree of Not / And / Or nodes over leaf conditions (Declaration, selector(...), or an unknown parenthesized blob kept as raw text).
• to_css_with_parens_if_needed prints a child node and wraps it in (...) when needs_parens says the grammar requires it; for Not children that is always, since not may only appear directly after @supports, supports(, or an opening paren.
• When the bundler inlines a stylesheet pulled in through @import ... supports(cond), it wraps the imported rules in a synthesized SupportsRule carrying that condition (src/bundler/linker_context/prepareCssAstsForChunk.rs), which is why the bundler output was affected by the same line.
• This is not a regression from the Rust port; the previous implementation printed the same " not ".

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 8 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: e23805c1-c652-4ff2-93aa-44a8768a961e

📥 Commits

Reviewing files that changed from the base of the PR and between eabb96d and 7f4afa2.

📒 Files selected for processing (4)

• src/css/media_query.rs
• src/css/rules/supports.rs
• test/bundler/esbuild/css.test.ts
• test/js/bun/css/css.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Reproduced on the released bun (1.4.0) and on main at eabb96d with cssInternals.minifyTest / bun build: @supports not (display: grid) {} printed as @supports not (display: grid){} (two spaces), (a) and (not (b)) as ( not (, and @import ... supports(not (a)) as supports( not (. The bundler's generated @supports wrapper for a conditional @import had the same double space.

Fix: SupportsCondition::to_css now writes not without a leading space (src/css/rules/supports.rs); every caller already writes its own separator. Output matches lightningcss for all of the tested inputs. The stale comment in media_query.rs that cited the old " not " contract is removed.

Tests: supports block in test/js/bun/css/css.test.ts (14 cases, placed after the media block, the same spot where #38589 and #33680 add theirs) and css/CSSAtSupportsNotCondition in test/bundler/esbuild/css.test.ts. All fail on the released bun with the stray space as the only difference and pass with this change.

Out of scope, handled separately: declaration parsing and vendor prefix printing of @supports conditions (#38589), and the derived ToCss separator bug that prints align-items: center under --minify (separate fix in progress).

[claude]

LGTM — one-character printer fix with thorough coverage.

Checked all three call sites that precede SupportsCondition::to_css: SupportsRule::to_css writes @supports , to_css_with_parens_if_needed writes (, and both ImportRule/ImportConditions write supports( — each already emits its own separator, and needs_parens unconditionally returns true for Not, so no path is left without a preceding delimiter. The comment update in media_query.rs correctly drops the now-stale " not " contract reference. Tests cover top-level not, nested-in-and/or/not, selector(), @import supports(), and the bundler-synthesized wrapper, with exact-string assertions that pin the whitespace.

Extended reasoning...

Overview

A one-character fix in src/css/rules/supports.rs: SupportsCondition::to_css for the Not variant now writes b"not " instead of b" not ", plus a two-word comment update in src/css/media_query.rs removing the stale mention of the old " not " contract. Two test files gain new cases: 14 minify_test round-trips in test/js/bun/css/css.test.ts and one exact-comparison itBundled in test/bundler/esbuild/css.test.ts.

Security risks

None. This changes only whitespace in serialized CSS output; no parsing, no allocation, no external input handling.

Level of scrutiny

Low. A single-byte change to a string literal in the CSS printer, with the invariant (every caller already writes its own separator) verified against all call sites: SupportsRule::to_css (src/css/rules/supports.rs:444), to_css_with_parens_if_needed (src/css/rules/supports.rs:140), and both @import printers in src/css/rules/import.rs:76-81 and :244-250. needs_parens returns true unconditionally for Not (src/css/rules/supports.rs:127), so nested Not is always preceded by (. This matches the existing "not " behavior for @media/@container in condition_to_css (src/css/media_query.rs), and the PR states output now matches lightningcss byte-for-byte.

Other factors

Test coverage is well above the bar: the new supports describe block covers not at top level, over selector(), over and/or groups, doubly nested, as first and non-first operand of and/or, in @import supports() with and without a media list, plus round-trip idempotence. The bundler test uses .toBe() (exact, not whitespace-insensitive) specifically to catch the whitespace regression across all three affected surfaces. No existing snapshot depended on the old spacing (only toEqualIgnoringWhitespace tests touched @supports before). No prior reviewer comments to address.

[robobun]

^{Updated 1:03 PM PT - Aug 14th, 2026}

@robobun, your commit 4452e16 is building: #96528

[claude]

LGTM — one-byte string-literal fix with thorough test coverage.

What was reviewed:

• Verified all three callers of SupportsCondition::to_css (@supports , supports( in @import, and the ( from to_css_with_parens_if_needed) already emit their own separator, and needs_parens returns true for Not, so no context loses the space.
• The media_query.rs change only trims a stale reference to the old " not " contract from an existing comment; the comment-cop bot fired on the diff touching that block, not on new content.
• New tests use exact (not whitespace-insensitive) comparison and cover not at top level, nested in and/or/not, over selector(), in @import supports(), and in the bundler-generated wrapper.

Extended reasoning...

Overview

This PR fixes a cosmetic bug in the CSS printer: SupportsCondition::to_css wrote b" not " with a leading space, producing double spaces (@supports not) or ( not in output. The fix drops the leading space to b"not ". A stale mention of the old contract in a comment in media_query.rs is trimmed. 14 new minify_test cases and one exact-match itBundled test are added.

Security risks

None. This is a whitespace change in serialized CSS output.

Level of scrutiny

Low. The functional change is a single byte removed from a string literal in the printer. I traced every site that can reach the Not arm of SupportsCondition::to_css: SupportsRule::to_css writes @supports (trailing space); the two @import printers in import.rs write supports then ( before recursing; and to_css_with_parens_if_needed writes ( first, which is always taken for Not children because needs_parens unconditionally returns true for that variant. The PR description's claim that every caller already emits a separator holds, so removing the leading space cannot produce @supportsnot or )not anywhere.

Other factors

• Test coverage is strong: exact-string assertions (not toEqualIgnoringWhitespace) that would catch both the old bug and any future missing-space regression, covering top-level not, not nested inside and/or/not (both operand positions), not selector(), @import ... supports(not ...) with and without a trailing media list, and the bundler's synthesized @supports wrapper. The three round-trip tests confirm the minified output re-parses to itself.
• The github-actions comment-cop flag on media_query.rs:24 is a false positive — the PR shortens a pre-existing comment block rather than adding a justification for a workaround.
• No existing snapshots depended on the old spacing (the description states full css.test.ts and esbuild/css.test.ts pass), and I found no other string literals containing " not " in the supports printer that would need the same fix.

[claude]

LGTM — one-character fix (" not " → "not ") in SupportsCondition::to_css, plus deletion of a stale comment that referenced the old contract.

What was reviewed:

• Traced every caller that can precede a printed Not: SupportsRule::to_css (writes @supports ), ImportRule::to_css / ImportConditions::to_css (write supports(), and to_css_with_parens_if_needed (writes (; needs_parens is unconditionally true for Not) — each already emits the separator.
• Checked remaining SupportsCondition references (context.rs, custom.rs, values/color.rs) — none print Not through a different path.
• Existing @supports bundler assertions use toEqualIgnoringWhitespace, so no snapshot depended on the old double space; the new bundler test uses exact .toBe on purpose.
• comment-cop feedback on media_query.rs was addressed in 7f4afa2 — the note is now a pure deletion.

Extended reasoning...

Overview

The PR removes a stray leading space from the @supports not printer. The functional change is a single byte in src/css/rules/supports.rs (b" not " → b"not "). A three-line comment in src/css/media_query.rs that documented the old " not " contract as a reason SupportsCondition doesn't implement QueryCondition is deleted. Fourteen minify_test round-trips are added to test/js/bun/css/css.test.ts and one exact-output itBundled case to test/bundler/esbuild/css.test.ts.

Correctness

I enumerated every site that can print a SupportsCondition. The Not variant is only reachable as (a) the top-level condition of SupportsRule::to_css, which writes "@supports " first; (b) the supports(...) clause of ImportRule / ImportConditions, which write " supports" then ( for the non-Declaration branch; or (c) a child of Not/And/Or via to_css_with_parens_if_needed, where needs_parens returns true for Not unconditionally so it is always preceded by (. There is no path where dropping the leading space fuses not into a preceding token. The other SupportsCondition references in context.rs, properties/custom.rs, and values/color.rs construct or store conditions but do not print them through a separate route.

Security risks

None. This is CSS output whitespace only; no parsing of untrusted input changed, no allocation, no unsafe code touched.

Level of scrutiny

Low. The source change is one character with an unambiguous, mechanically-verifiable effect, the comment change is a pure deletion of a stale note, and coverage is thorough (top-level, nested under and/or/not, over selector(), in @import supports(...) with and without a media list, plus the bundler-synthesized wrapper). Existing @supports assertions in the bundler suite use toEqualIgnoringWhitespace, so nothing depended on the old double space.

Other factors

The two comment-cop notes on media_query.rs were addressed in 7f4afa2 (the SupportsCondition sentence was deleted rather than reworded) and both threads are resolved. The PR description accurately scopes out adjacent bugs (declaration parsing, vendor-prefix printing, derived-ToCss separator) to their own PRs.

[Jarred-Sumner]

Landed in #47025 (7942008).

Print @supports not conditions without a leading space. 88 real stylesheets