Closed shvaikalesh closed 1 year ago
https://github.com/postcss/sugarss
We add it as a dependency to postcss-brunch
and process .sss
files without additional configuration.
Zero-config is good, but this is a plugin. Even if it's widely used, it may not be as popular in 1-2 years, and then we'll need to extract the functionality, while breaking the compatibility.
Otherwise, to support .sss
and other parsers, we would need to add a config option. Same
Even if it's widely used, it may not be as popular in 1-2 years, and then we'll need to extract the functionality, while breaking the compatibility.
holds true for option, but requires additional setup by users.
:-1: postcss-brunch isn't opinionated. maintaining another dependency would be a burden. this feels like it'd belong better in something like sugarss-brunch
.
Brunch itself is opinionated. However, it is not quite about that: we should support PostCSS parsers. If the user has sugarss parser in package.json, postcss-brunch
should use it.
Agree on sugarss-brunch
.
If we do sugarss-brunch
we end up maintaining several copy-pasted Brunch plugins for each parser PostCSS will ever have. It is way better to analyze package.json
for PostCSS parsers instead of separate plugins.
what do you mean?