Use PostCSS

[ai]

fastparse is awesome tool. But if you will move to PostCSS you will have these benefits:

1. Most of source map code will be in PostCSS.
2. You can replace url() and support @import with full CSS parsing. It is much safer. We are already have awesome plugins for url() and @import.
3. PostCSS has “Safe Mode” to parse any legacy CSS (even broken).
4. Right now @ben-eb creating awesome modular CSS minifier (it is much easier to fix and develop modular tool) cssnano. Right now it has better results that [clean-css] without advanced mode. So, when it became equal to clean-css, we can use it, because it is a PostCSS plugin with same source map support.

@markdalgleish what do you think as PostCSS plugin developer?

[markdalgleish]

@ai It worked really well for me given I had zero experience beforehand.

One question I have though—does PostCSS parse selectors into an AST? I'm currently transforming selectors using regular expressions which I know isn't going to work in the long run, and it'd be much better to operate on an AST instead of a string.

[ai]

@markdalgleish there is no selector parser right now and you can use css-selector-parser. @ben-eb is developing new parser, but as I know it will not be ready in this month.

[sokra]

PostCSS is nice. We previously used a full parser for the url() and imports (and now local) parsing, but using a simple string parser has the following benefits:

• Performance (we are just do RegExp matching)
• Compatible with future CSS extension of weird syntax used by some libs (This occured with the previous parser css loader chokes on valid CSS #43 Getting CSS validation error for valid css file (0.7.0). #16 Getting optimisation issue with some CSS #36 Module build failed: Error: Please check the validity of the CSS block starting from the line #3288 #24, this may not be an issue currently, but could be in future when PostCSS get less maintained).
• We can easily add our own parsing stuff (like locals) and don't need to traverse the AST (which may change)
• We don't need a full AST
• It works and is simple

I'm fine with changing the css minimizer to PostCSS if it's better.

[ai]

@sokra but it is not safe ;).

a {
    content: "do not use url(path)";
}

[ai]

@sokra and more details for you reasonable counterarguments:

• Of course, regexp shouldbe faster, than parser. But PostCSS is one of the fastest parsers written on JS. It is 4.5 times faster, that gonzales, that you use before.
• PostCSS Safe Mode is a answer for future compatible. It will parse anything.
• What is a locals? Is it relevant for postcss-local-scope?
• We need a AST to safe change CSS.
• It is not really simple right now. You have a lot of soure map code, which will be removed with PostCSS. PostCSS already had good postcss-url and postcss-import by @MoOx. You can use them and it will clean your code and be better for maintaining.

[sokra]

If you want to do a PR, feel free to do so, but I still think it not worth the work. The current parser is functional and works fine. postcss-url and postcss-import won't help here, because they do it different than the css-loader.

[MoOx]

The current parser is functional and works fine

Not really, there is some case where latest css syntax is causing issue (if you minify) which break the process.

[sokra]

The minimizer and the parser are separate things in the css-loader. I'm fine with replacing the minimizer with PostCSS (that not much work).

[airtonix]

css-loader shouldn't do any post processing...