Documentation for CSS Features
onigoetz opened this issue · comments
Describe the feature
I saw that the changelog has many mentions for CSS features (parser, linter, minifier )
I would be very interested to see the documentation but couldn't find it, is there anything published yet ?
And some side questions
- There is the @parcel/css package that seems to provide similar CSS features, is there some collaboration between the two projects ?
- Does it have to be in the same bundle ? (related to #3899) I would be very interested to have the CSS linter for example in a project but wouldn't need the JavaScript compiler (just an example)
Babel plugin or link to the feature description
No response
Additional context
No response
It's not published yet
There is the @parcel/css package that seems to provide similar CSS features, is there some collaboration between the two projects ?
Parcel is just CSS bundler and minifier, we use another approach - AST (parser/codegen/etc) + transformations + plugins support (in future), so it's a slightly different approaches.
But yes we should improve docs here, it is young and there are a lot of rooms to improve
It's not only a bundler and minifier. They also provide vendor prefixing and fallbacks (nesting, css colors level 4 fallback and more)
I'm also pretty sure they want to add plugin support.
@devongovett built it. He certainly knows better what will and will not come in @parcel/css future
@devongovett Not fully truth, we use the both approaches, trying to parser known and provide more better AST structures where we known how to parser, if we can't parser we provide generic AST (at the moment we are not processing too many things, but it designed to do it and we are continuing improve it).
We want to help not only bundling, our area is more - linter/formatter/etc so we need AST here and some more generic structures (especial for recovery mode), so author can write plugins for future CSS syntax without problems.
Parcel CSS works more like browsers and fully parses all known properties, whereas SWC provides a more generic AST that each consumer must interpret themselves.
This statement is not entirely correct. We also parser like a browser, just what the browser cannot parse, we put it in common AST structures, as I said earlier.
I suggested working together on it in the past (#2884), but the SWC developers wanted to go in a different direction.
No one refused to help, you want to develop it in another repository, like a side project, unfortunately, this approach in organizational terms does not suit us