search

biomejs / biome

A toolchain for web projects, aimed to provide functionalities to maintain them. Biome offers formatter and linter, usable via CLI and LSP.
https://biomejs.dev
Apache License 2.0
12.57k stars 394 forks source link

☂️ CSS Formatter #1285

Open faultyserver opened 6 months ago

faultyserver commented 6 months ago

Description

This issue will act as the hub for tracking the CSS formatter as it gets built out. Listed here are all of the different pieces that will need to be implemented to get "complete" support in place. For the most part, this means compatibility with Prettier, and the implementations will inevitably take on the same shape, but we are not currently aiming for perfect parity with Pretttier, as their implementation and tests lean heavily into PostCSS and other facets that we are not yet ready to support.

How to Contribute

Everyone is welcome to contribute pieces here! If you'd like to tackle something, please leave a comment below this issue for which item(s) of the checklist below you'd like to pick up. We will create a separate issue and assign it to you to simplify tracking.

[!NOTE] In order to have the issue assigned to you, you must comment on this issue.

When choosing an item to work on, there are often various pieces that will fit together or be dependent on each other, like attribute_selector requires attribute_name, attribute_matcher, and attribute_matcher_value to be implemented at the same time to get full support.

Also, please only pick a single piece or group to work on at a time, and try to have time available to work on the piece when you select it so that we can keep progressing quickly. If you need any help or have any questions about how to implement formatting in Biome, feel free to ask in the dev-formatter channel in Discord.

Testing

We don't currently have Prettier tests for the CSS formatter, again because much of Prettier's implementation focuses on supporting PostCSS, beyond just standard CSS that Biome supports currently. Instead, please add spec tests under crates/biome_css_formatter/test/specs/css for the feature you are working on. For the most part, Prettier's CSS tests do provide a lot of coverage and examples to pull from.

Node Checklist

The CSS Parser is still in progress, so the set of nodes that need to be formatted is constantly changing. All of the current nodes have been implemented, but as new ones are added, they will need to be formatted as well. Since it's moving so quickly, the list won't be updated here. Instead, there are a number of other general things that need support, listed below.

Once the parser reaches a mostly complete and stable state, we will flesh out the list of remaining types that need formatting support and add them here.

Features and bug fixes

These are features, bug fixes, and other adjustments that need to be made to the formatter to get closer to parity with Prettier.

Formatting Infrastructure

Listed here are various things that are ready to be implemented or fixed that apply to the CSS formatter in general.

Testing:

Releasability

These tasks need to be completed for the CSS formatter to be "publicly available" and on-par with the JS formatter.

faultyserver commented 6 months ago

I'm working on Comment Placement now

tom-sherman commented 6 months ago

Is this the first step in implementing a CSS linter? Or could that be worked on in parallel? (the parser code seems pretty fleshed out already to my naked eye)

denbezrukov commented 6 months ago

Is this the first step in implementing a CSS linter? Or could that be worked on in parallel? (the parser code seems pretty fleshed out already to my naked eye)

The issue is only related to CSS formatting. I believe that the linter and formatter can work in parallel. Meanwhile, the parser is still under development (the cst nodes aren't stable and can be changed).

Any help is welcome!

faultyserver commented 6 months ago

Agreed, the parser is pretty far along, but there will be many changes before it can effectively lint full CSS files (for example, we're adding parsing for exact properties now, and each one will have a new node type, so writing lints for them now would require rewriting them entirely later on).

itsjavi commented 6 months ago

I guess this is only about a pure CSS formatter, but what are your plans/thoughts about SCSS?

faultyserver commented 6 months ago

what are your plans/thoughts about SCSS?

It's unlikely that we'll add any non-standard CSS dialects in the short term. SCSS and other dialects like Less and even PostCSS end up diverging pretty far from standard CSS and require very different parsing to handle all of their extensions to the language syntax (e.g., mixins in sass and less, @value in postcss, and so on). Additionally, these dialects have different behavior and rules for the same syntax that ends up being added in future CSS specifications, which makes it more difficult to support them all at the same time.

We may consider adding some support in the future, but for the forseeable future we will be focusing on supporting all of latest, standard CSS.

itsjavi commented 6 months ago

@faultyserver Fair enough, I think it's good to focus on standard CSS first. Also IMHO SCSS will eventually become redundant (once nested CSS is widely supported and many other cool features coming after CSS houdini experiments)

Netail commented 4 months ago

@faultyserver Fair enough, I think it's good to focus on standard CSS first. Also IMHO SCSS will eventually become redundant (once nested CSS is widely supported and many other cool features coming after CSS houdini experiments)

I doubt it will become redundant any time soon, nesting is a small part of the capabilities of sass. (Extending, mixins, functions, arrays, maps)

Sass is the most used CSS tooling (49% in The State of Frontend 2022 - the results of 2023 are not out yet) and would definitely be worth supporting. Frameworks like NextJS support this by default and I believe sass has a public parser which could be utilised?

Marcisbee commented 4 months ago

@faultyserver Fair enough, I think it's good to focus on standard CSS first. Also IMHO SCSS will eventually become redundant (once nested CSS is widely supported and many other cool features coming after CSS houdini experiments)

I doubt it will become redundant any time soon, nesting is a small part of the capabilities of sass. (Extending, mixins, functions, arrays, maps)

Sass is the most used CSS tooling (49% in The State of Frontend 2022 - the results of 2023 are not out yet) and would definitely be worth supporting. Frameworks like NextJS support this by default and I believe sass has a public parser which could be utilised?

There is work being done to add functions and mixins to CSS too: https://github.com/w3c/csswg-drafts/issues/9350

Netail commented 4 months ago

@faultyserver Fair enough, I think it's good to focus on standard CSS first. Also IMHO SCSS will eventually become redundant (once nested CSS is widely supported and many other cool features coming after CSS houdini experiments)

I doubt it will become redundant any time soon, nesting is a small part of the capabilities of sass. (Extending, mixins, functions, arrays, maps) Sass is the most used CSS tooling (49% in The State of Frontend 2022 - the results of 2023 are not out yet) and would definitely be worth supporting. Frameworks like NextJS support this by default and I believe sass has a public parser which could be utilised?

There is work being done to add functions and mixins to CSS too: w3c/csswg-drafts#9350

Correct there is some work being done for functions and mixins (again not all sass features yet), how long till this draft becomes reality and how long till the adoption is reasonable? Might take 2-3 years. Houdini currently has 73%.

Besides, couldn't the same be said for Typescript as typings in Javascript is in the works xd

finnan444 commented 3 weeks ago

BTW if sass is not supported why in documentation css super languages are mentioned? --css-formatter-enabled=<true|false> — Control the formatter for CSS (and its super languages) files.

KurtGokhan commented 1 week ago

In my opinion, no amount of new CSS features will be enough to replace Sass completely. For me, Sass is more useful for having a modular code structure. It is like a missing piece between the CSS and the bundler. Although Tailwind and other no-CSS libraries are quite popular lately, I think Sass is still the best tool for anyone writing their own design system.

But I understand it expands the scope a lot. So maybe it can be added as a plugin later (not sure if plugin system will support this), or it can have a minimal set of features (quotes, spacing, no prettier compatibility).

Netail commented 1 week ago

In my opinion, no amount of new CSS features will be enough to replace Sass completely. For me, Sass is more useful for having a modular code structure. It is like a missing piece between the CSS and the bundler. Although Tailwind and other no-CSS libraries are quite popular lately, I think Sass is still the best tool for anyone writing their own design system.

But I understand it expands the scope a lot. So maybe it can be added as a plugin later (not sure if plugin system will support this), or it can have a minimal set of features (quotes, spacing, no prettier compatibility).

Fully agree on this one, it could be a plugin or like jsonc options within the base language (in this case css)