css: keep '/' and '*' delims separated when minifying token lists

[robobun]

Repro

const b = await Bun.build({ entrypoints: ["e.css"], minify: true });
// e.css:
//   :root { --a: x / * y }
//   .k { color: red }
console.log(await b.outputs[0].text());
// => :root{--a:x/*y}.k{color:red}

The /* after x opens a comment. Reparsing Bun's own output drops .k { color: red } (and everything after it) entirely. esbuild preserves the value byte-for-byte.

Cause

TokenList::to_css (src/css/properties/custom.rs) already computes ws_before = !has_whitespace && (d == '/' || d == '*') precisely to prevent this, but Printer::delim routes ws_before through Printer::whitespace(), which writes nothing when minifying. The arm then sets has_whitespace = true regardless of whether a byte was actually written, so the following *'s guard is skipped too. Adjacent / and * delims collapse to /*.

The same applies to any unparsed property value (not just --custom) and to token-list arguments inside functions.

Fix

After printing a / or * delim in minify mode, peek at the next token: if it's the other half of the pair, emit a real space via write_char. This is precise: a lone / or * (e.g. --a: 16 / 9) still minifies to 16/9 with no extra bytes, and non-minified output is unchanged.

input	before	after
--a: x / * y	x/*y	x/ *y
--a: x * / y	x*/y	x* /y
--a: 16 / 9	16/9	16/9
--a: x / y	x/y	x/y
--a: x / / y	x//y	x//y

Verification

New minify_test cases in test/js/bun/css/css.test.ts cover / then *, * then /, a chain / * / *, unknown properties, function arguments, the unchanged single-delim cases, and the non-minified round-trip. They fail on the current release (x/*y) and pass with the fix. Full css.test.ts (1129 tests), test/js/bun/css/doesnt_crash.test.ts (61 tests), and test/bundler/css/ (168 tests) pass.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 1 minute

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: 4c9de20c-c70d-4895-8378-bc71593a2e94

📥 Commits

Reviewing files that changed from the base of the PR and between 3f5d816 and 540a493.

📒 Files selected for processing (2)

• src/css/properties/custom.rs
• test/js/bun/css/css.test.ts

---

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

[robobun]

^{Updated 11:05 AM PT - Jul 7th, 2026}

❌ @robobun, your commit 540a493 has some failures in Build #69965 (All Failures)

---

🧪   To try this PR locally:

bunx bun-pr 33683

That installs a local version of the PR into your bun-33683 executable, so you can run:

bun-33683 --bun