External validators

[jonathanglasmeyer]

An approach discussed in #17 for solving the architectural question of how to integrate support for custom / not-webpack-core validators looks as follows:

• Look in package.json for packages named webpack-validator-plugin-.... These plugins are then automatically used without the user needing to set them up, thereby reducing tooling fatigue.
• Maybe also look if packages of the form ...-loader that export something under ...-loader/validate. This allows webpack plugin maintainers to supply a validation function for their plugin without having to create a new project.
• Additionally, maintain a mapping of webpack configs toplevel property names to required webpack-validator-plugin packages. If such a top level key is used, the user sees a warning/hint to npm install the matching package. Installing it will be the only required step for this package to be then actually used.
• For integration testing, webpack-validator-plugin-... packages could import a set of webpack config test cases from somewhere (new package?) to verify their behaviour.

Any thoughts on this? Will probably have some time on the weekend to tackle this.

Cheers, Jonathan

[nyrosmith]

This sounds very good to me but I think this should be very verbose of what's going on so the user gets an idea of what happens

[jonathanglasmeyer]

Sure. :+1: I'm not sure about the testing aspect. How would validator plugin authors test their stuff? There is some setup overhead involved right? I'm still wondering if the core project should include validator plugins in its tests or if that should be the responsibility of the validator plugin authors.

[kentcdodds]

Yeah, I think we'll have to write this in a modular way so we can have units that can accept stubbed out dependencies. Then we can have a handful of integration tests to make sure it all works together. I'm sure we can do this though :-)

[jonathanglasmeyer]

Will revisit this when we have a monorepo.