Add support for postcss loader

[jonathanglasmeyer]

I added "skeletonic" support for the postcss property used by postcss-loader and added a webpack config of mine to verify acceptance.

This is a cool project, I'd like to get involved. 👍

[kentcdodds]

Sorry it took so long for me to get to you on this one!

I love it and I'm glad you want to get involved!

I'm not sure how I want to handle 3rd party plugin options. Part of me wants to just include them by default, but another part of me wants to require people to explicitly import them.

What I mean is, people would have to do:

var validateWebpack = require('webpack-validator')

module.exports = validateWebpack(config, [
  validateWebpack.postcss,
  validateWebpack.eslint,
  // etc...
])

Thoughts? I can see benefits/drawbacks for both. 💭

[jonathanglasmeyer]

That's the crucial question. On one hand this is a tool to reduce tooling
fatigue, so like the baseline premise should be sensible defaults over
configuration for this thing. When I'm already fatigued I def will not care
to configure Yet Another Tool.
On the other hand I guess that we'd want plugin authors to be able to write
their own validators and make them pluggable into webpack-validator via
require 'webpack-validator-postcss-loader-plugin' or even require postcss-loader/validate.
A problem is see with this approach is how the full config integration
tests should be run when plugins are externalized.

I wonder if it's possible to find a middleground. So maybe start integrated
and move to externals later. Or intelligently find installed external
validators in node modules folder according to something like the proposed
naming schemes above and automatically use them, plus curate the existing
selection of external validators in a very visible way in the README?
Maybe even messages like "You seem to be using postcss loader. To validate
it, npm install webpack-validators-postcss-loader-plugin". (If the plugin
author exposes it as postcss-loader/validate, the integration could happen
completely automatically.)

Just some thoughts. :)

[kentcdodds]

I'm sold. Let's do this.

[jonathanglasmeyer]

Do...what?😃
The formatting of my last message was weird (I sent it per mail). I've edited my last message so that it shows the whole text now.

[kentcdodds]

Yeah, noticed that after the fact :-)

I was sold when you said:

When I'm already fatigued I def will not care to configure Yet Another Tool.

One of the goals of this project is to reduce fatigue, not increase it!

[jonathanglasmeyer]

Ok so what does that imply for the plugin architecture I proposed? What if plugins are just required by webpack-validator itself and the user doesn't have to care about installing and configuring them? Wouldn't we get the best of two worlds: ease of setup while still being able to run ntegration tests including those blessed plugins; plus allowing webpack loader authors/contributors to maintain these validators without having to PR this project each time the plugin interface changes?

Finally, users could opt-in to supplying other, not-yet-blessed or custom plugins themselves.

[kentcdodds]

That'd be cool. I definitely would like to have a spec that said: "Check the user's package.json and if there's anything that starts with webpack-, attempt a require('webpack-whatever/validate'). That would be interesting. I'm definitely interested in a PR about that. Want to file an issue to track that?

[jonathanglasmeyer]

Will do. Probably will find time to work on it on the weekend.