Use SWC as parser

[alexander-akait]

I start work on rust based CSS parser/visitor/codegen - https://github.com/swc-project/swc. I suggest that we should consider to use it as future CSS parser. A lot of great opportunities for us - new rules, better checks, recover mode and more and more. I will not talk about perf and memory usage here.

Notes:

1. At-rules, selectors and values AST included, we can drop postcss-selector-parser, postcss-value-parser, postcss-media-query-parser packages, they are outdated and doesn't support many CSS features.
2. Due above point it will make it possible write new rules for @media, selectors, values and etc, most of rules can be rewritten on a much smaller number of lines, which means we need less time for maintenance.
3. Resistance to input problems, we can parse even broken CSS, like do browser by default (recovery mode).
4. Sass/Less/etc - in core we ignore these constructors (isStandard* utils), but due above point we still have tokens (on nodes where we can't create AST) so it will be possible still analyze/stringify/reparse them, also we can do swc parser expandable, this is not difficult, but that would still require someone to implement the parsers. Although to be honest, I'm pretty skeptical about Sass/Less/etc, yes, these are still very popular instruments, but more and more opportunities we can see in CSS, therefore, I think that they are living out their days. Anyway it won't require huge changes from stylelint-scss/etc because we still not provide them AST of prelude of at-rules (i.e. @media), values, etc.
5. CSS-in-JS, I don't think this is a big problem too, we should covert JS to CSS, just replace JS expressions on valid CSS code, i.e. color: __embeded_value___, I think we already do it (I have not tested).
6. AST for calc/min/max, AST for an+b syntax and more.

Questions/ideas:

1. We can implement swc to postcss AST converter for easy migration, postcss AST is not full, so converter will not be big and not hard to implement.
2. I think we can start to rewrite rule by rule to avoid big and long refactor. We have many tests so catching problems will be easy.
3. No need isStandard* utils, if node has tokens property (recovery mode), it means no AST present for node and should be ignored.
4. JS parser can be replaces on swc parser too. In roadmap - HTML/XML parser and markdown parser too.
5. Rewrite stylelint on rust 😄

Sometimes it's time to look at old things in a new way.

Feel free to questions and feedback, thanks ⭐

[jeddy3]

Very interesting. I'm aware of the buzz around SWC, as it brings a lot to the table.

We've touched on the benefits of a more granular parser before in #5061. Especially, parser-level validation of things like mathematical expressions. Am I right in thinking that the parser will already catch a::before::after {} from #5575?

We generally bump into issues when working with values or units (e.g. unit-no-unknown), less so for at-rules names (e.g. at-rule-no-unknown. A gradual migration would suit this as we could target the more problematic areas first. Am I right in thinking that rules and plugins can still be written in JavaScript, even though the parser itself is written in Rust?

As you said, the benefits to the user are:

• compatibility with upcoming, edge or complex CSS features, e.g. custom property values
• new rules, especially around an+b selector syntax, calculations and at-rules (media queries, support features, container queries and other upcoming conditionals like @when)

There are a number of unknowns, though, especially around languages like SCSS.

Right now, we're focused on the 14.0.0 release. Once the dust settles on that, I think we can circle back around to this issue.

There's no harm in investigating this further, though. We'll need to weigh up all the pros and cons as things become clearer, but we should be open to the possibility of using the SWC parser.

Related: #5499

[alexander-akait]

Am I right in thinking that the parser will already catch a::before::after {} from #5575?

Yes, but due Resistance to input problems we still can have AST, but contains errors for AST nodes

Am I right in thinking that rules and plugins can still be written in JavaScript, even though the parser itself is written in Rust?

Yes, we just use swc as parser, just replace import postcss from 'postcss'; on import swc from "@swc/core";, nothing more, maybe in the future we decide to move on rust based rules (they may well be combined with js rules).

There's no harm in investigating this further, though. We'll need to weigh up all the pros and cons as things become clearer, but we should be open to the possibility of using the SWC parser.

yes, it is just discussion.

Anyway, swc allows (will allow, we need just do method public in swc) parse selectors, at-rules, values, so we can do smoothly migration, migrate from postcss-selector-parser/postcss-value-parser/postcss-media-parser on swc. You probably already noticed that they have not been fixed/improved for a long time.

[jeddy3]

Anyway, swc allows (will allow, we need just do method public in swc) parse selectors, at-rules, values, so we can do smoothly migration, migrate from postcss-selector-parser/postcss-value-parser/postcss-media-parser on swc. You probably already noticed that they have not been fixed/improved for a long time.

Fantastic! The media query parser is a great first candidate as we've some hacky stuff to support range contexts.

[jeddy3]

Closing in favour of stylelint/css-parser#2