Migrate to PostCSS?

[ben-eb]

What do you think of switching from rework to PostCSS? Number of benefits includes:

• Great support for nested rules which would help fix https://github.com/SlexAxton/css-colorguard/issues/25.
• First class source maps, which are automatically updated whenever you would modify nodes. https://github.com/SlexAxton/css-colorguard/issues/8
• Would be very straightforward to do something like this also. https://github.com/SlexAxton/css-colorguard/issues/1
• You would be able to report colour collisions in the browser and the CLI with https://github.com/postcss/postcss-reporter & https://github.com/postcss/postcss-browser-reporter

[SlexAxton]

Totally for it. Just a matter of doing the work.

[ben-eb]

I did the easy bit of switching parsers (https://github.com/ben-eb/css-colorguard/commit/21efa9be177463d9a2b7d4d125608ed37a2e48c4) but I think we can do better when it comes to the logging. We can use the messages API (https://github.com/postcss/postcss/blob/master/docs/api.md#nodewarnresult-message) and warn of color differences directly on each declaration node. Then, we pass those messages to a reporter plugin further along in the PostCSS instance.

Perhaps for an integrated API we should have a look at bundling postcss-reporter, but leave it out if people would like to integrate css-colorguard into an existing PostCSS instance. This is the approach I used here: https://github.com/ben-eb/stylehacks/blob/master/src/index.js#L57-L59

Anyway I didn't want to break the existing API without your thoughts on the matter, so let me know what you think to these breaking changes:

• module.exports becomes a PostCSS plugin for easy ecosystem integration.
• module.exports.inspect is removed and becomes module.exports.process, which wraps the plugin with an API like colorguard.process(css, opts).
• Reporting in JSON is replaced with the PostCSS messages API.

If it's OK I'd also like to change the test suite around to use https://github.com/substack/tape which makes your test dependencies explicit, avoiding the /* global */ comments. :smile:

[SlexAxton]

Just marking that I'm not ignoring this. Almost definitely want to do this, in fact, but haven't had a chance to dig in. Thanks for your work so far.

There are lots of ways to avoid /* global */ comments without burning down the forest, but if it makes you happy enough to contribute a full PostCSS refactor, you can switch the tests to anything you want.

[ben-eb]

Would you like me to implement those proposed changes?

[SlexAxton]

Yea. We'll just bump major versions. Looks like a much more standard/predictable output than what I am currently doing. Let me know if you have questions.