search

kentcdodds / webpack-validator-DEPRECATED

Use this to save yourself some time when working on a webpack configuration.
MIT License
93 stars 8 forks source link

Opt-in error throwing #34

Closed jonathanglasmeyer closed 5 years ago

jonathanglasmeyer commented 8 years ago

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?

nyrosmith commented 8 years ago

I think that the lib itself should not throw errors and for CI the cli should be used. Some Build mechanisms don't care about errors but exit codes. But I might be wrong...

sarbbottam commented 8 years ago

I guess @jonathanewerner is suggesting to process.exit(1) on errors along with logging, if desired by passing throwErrors: true as config.

nyrosmith commented 8 years ago

I think I should not coment before I had my first cup of coffee... That's totally valid. If it's ok I'll implement this behavior when my changes to configuration-validator are done.

jonathanglasmeyer commented 8 years ago

Morning. Same timezone here, first coffee coming. :) :coffee: @sarbbottam that's exactly what I'm suggesting. I think it's an orthogonal question if the user wants to use a cli tool for that for that or if they want to wrap their config object with our validate function. Both approaches should allow throwing errors. (cli: --throw-errors, programmatic: {throwErrors: true}). @nyrosmith: Do it. :+1:

jonathanglasmeyer commented 8 years ago

@nyrosmith would you like to assign yourself to this issue?

nyrosmith commented 8 years ago

Done

nyrosmith commented 8 years ago

It's on hold until the new configuration-validator API is done.