Use this to save yourself some time when working on a webpack configuration.
by kentcdoddsJavaScript
Last 12 weeks · 0 commits
3 of 6 standards met
So the more of those validate functions i'm writing the more i'm asking myself if this approach is optimal. We are in fact doing 95% _schema validation_, a task which a library like joi (or maybe the one you wrote, Kent, api-check ?) solves perfectly, but we are writing this very imperatively and with ad hoc, non-normalized error messages. In fact i am thinking of experimentally starting an alternative approach in another repo, maybe just called and see how far this would replicate the use case of our approach here. The main goal would be finding out where the limits of using a schema validation library would be and maybe check out if the burden of all those manual tests could be "extracted" onto the shoulders of a mature, more generic library -- thereby substantially reducing the error surface.
Right now we are only console.logging warnings. For CI build processes it would be beneficial if the user could opt in to have webpack-validator throw errors on problems. This way cryptic errors from webpack malconfiguration would be replaced with DX-friendlier errors in CI logs. The could be implemented by supplying a 'throwErrors': true configuration option to either the CLI interface or to our default export validate function. Thoughts?
Repository: kentcdodds/webpack-validator-DEPRECATED. Description: Use this to save yourself some time when working on a webpack configuration. Stars: 93, Forks: 5. Primary language: JavaScript. Languages: JavaScript (100%). License: MIT. Open PRs: 0, open issues: 5. Last activity: 5y ago. Community health: 57%. Top contributors: jonathanglasmeyer, sarbbottam, nyrosmith, xjamundx, miguelc1221, kazekagegaara, mikekidder.