Question
CSS Formatting: Transitioning from Prettier to Biome AST-based output
Zo Dey
0 reputation · 14 Jun 2025, 22:43 UTC
66.2K views
Loading…
0 reputation · 14 Jun 2025, 22:43 UTC
Biome provides a unified toolchain for CSS formatting and linting, utilizing a deterministic AST-based approach to replace standalone tools like Prettier. While this architecture ensures consistent output regardless of input spacing, the transition involves moving from a separate configuration ecosystem to a centralized biome.json file.
When migrating complex stylesheets, there is uncertainty regarding how Biome handles specific legacy CSS patterns that are technically valid but deviate from strict modern specifications. Ensuring that the formatter does not introduce regressions in layout-critical spacing requires a clear understanding of the current AST implementation boundaries.
1. Does Biome’s CSS formatter maintain full parity with Prettier’s handling of nested at‑rules?
Biome’s CSS formatter is AST‑based and deterministic, which means it will re‑print a parsed syntax tree regardless of the original whitespace. However, its support for complex nested at‑rules (e.g., @media inside @supports, nested @layer, or custom @font-face variants) is still evolving. In recent releases (v1.10.x), Biome supports standard nesting but may skip or emit warnings for non‑standard or vendor‑specific constructs that Prettier would tolerate. Therefore, full parity is not guaranteed until you run a targeted comparison against your own codebase.
2. What is the recommended method for verifying that AST‑based formatting does not alter the visual intent of legacy CSS‑in‑JS patterns?
Because Biome’s formatter operates on standalone CSS files, any CSS embedded in template literals (styled‑components, Emotion, etc.) is only reformatted if the library outputs a separate CSS file or if you run Biome on the generated CSS. The safest verification workflow is:
biomenpx @biomejs/biome format --writegit diff -w to confirm that only formatting changes (whitespace, quote style, line width) are present.npx prettier --check comparison to identify divergence.When the formatter introduces non‑whitespace changes that you cannot manually reconcile, consider isolating those files in a separate commit, or temporarily disabling Biome for the affected patterns until the tool’s next release adds full support.
Do you use any custom at‑rule syntax or legacy CSS hacks (e.g., underscore hacks, expression()) that might be unsupported by Biome? This detail could affect the recommendation for handling those cases.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 15 Jun 2025, 09:30 UTC
One thing worth adding to the verification checklist: the biome migrate CLI converts a top-level Prettier config but does not translate Prettier's overrides array. If your setup formats .module.css or third-party vendored CSS differently from the rest, those per-glob rules must be recreated manually in biome.json — otherwise Biome will apply the default formatter settings everywhere, which can produce a much larger diff than expected on the first run.
Also, because Biome's output is deterministic per version rather than per config alone, pin the exact Biome version in CI (and in your package manager lockfile) before rolling out the format commit. Upgrading Biome later can silently change formatting decisions for nested at-rules even with an unchanged config, turning a routine dependency bump into a repo-wide reformat. Treat formatter upgrades as their own dedicated commits so any layout-affecting diff stays reviewable in isolation.