#24 use PostCSS result.warn API to send messages as well

[sebastienbarre]

This addresses issue #24 by pushing the warning message using the PostCSS API:

  result.warn(message, { node: usage, plugin: 'doiuse' }) 

This has no visible side-effect unless the warnings are handled downstream, either by looping over the warnings array and outputting them to the console, or by using a pretty-printer like postcss-reporter.

This PR also displays feature in parenthesis at the end of the message. This can in turn be leveraged to suppress the corresponding warning using the new ignore option. The tests were updated accordingly.

Here is an output example when using doiuse from webpack + postcss-loader, note how it flows with other PostCSS plugins that comply with the result.warn API (here, stylelint and postcss-bem-linter):

$ webpack
src/css/App.css
2:5   ⚠  Expected indentation of 2 spaces (indentation) [stylelint]

src/css/Vote.css
13:1  ⚠  Invalid component selector ".Foo" [postcss-bem-linter]

src/css/typography.css
10:3  ⚠  rem (root em) units not supported by: IE (8,9,10) (rem) [doiuse]
14:3  ⚠  rem (root em) units not supported by: IE (8,9,10) (rem) [doiuse]

Thanks

[anandthakker]

Looks great to me!

Just thing I'm unclear about. You said

This PR also displays feature in parenthesis at the end of the message. This can in turn be leveraged to suppress the corresponding warning using the new ignore option.

But aren't we already using the ignore option before even emitting the warning?

[sebastienbarre]

@anandthakker sorry this was confusing. Yes we are using ignore before the warning is emitted. But if you want to ignore something else, how do you know which keyword to put in ignore without looking at the code? By displaying it in the warning message, you can subsequently ignore it if you need to.

My use case here is that I try to support IE8 in my CSS. For example, by providing fallbacks for rem or rgba through other PostCSS filters. Since doiuse still warn me about it, I wanted a way to ignore these messages. CSS shadows or gradients are also features that don't really break the UI experience if they are not supported -- I don't need to be warned about the fact that they won't show up in IE8.

[anandthakker]

Ohhh, yes, great point, I understand what you mean now. Awesome--thanks. I'll go ahead and merge this, and bump an npm release.

Also, I've added you as a collaborator as per http://openopensource.org/

[sebastienbarre]

Thanks. I appreciate you accepted all those PRs. I'm done messing with your code :)