Setup Travis CI

[jonathanglasmeyer]

We need Travis to npm run validate.

Blockers:

• [x] #35 for node compat

[sarbbottam]

https://github.com/kentcdodds/webpack-validator/issues/26 seems to be related.

[jonathanglasmeyer]

@kentcdodds As admin access to this repo is needed, i can't set it up alone. :) Could you setup the integration? Or what's the best way to go forward here?

[kentcdodds]

Yeah, I'll do that. Thanks for the ping!

I'll hold off on semantic-release until I feel like we can come out of beta.

What we need to come out of beta?

1. configuration-validator needs to stabilize its API (@nyrosmith is working on a refactor I think)
2. We need to flesh out the validators for all built-in properties

Other stuff on the roadmap can wait I think. Thoughts? :thought_balloon:

[nyrosmith]

configuration-validator API changes are my highest Prio but I am unsure if I have time during weekend to get the changes done. I think it is important to ship something usefull even if it is incomplete. People can use it even when not feature complete and give early feedback. Eg I plan to integrate this lib asap and can do dogfooding while adding stuff

[kentcdodds]

I am unsure if I have time during weekend to get the changes done.

Take your time :-) Don't kill yourself (or your relationships) over an open source lib :-)

I think it is important to ship something usefull even if it is incomplete.

Me too! That's why beta is shipped and people can use it today. Though I should probably do another release with the handful of new validators that we've gotten. I'll do that now :+1:

[kentcdodds]

Get it while it's hot! npm i -D webpack-validator@1.0.0-beta.7 :fire: :-)

[jonathanglasmeyer]

I'm not even sure if fleshing out validators would be a requirement for going out of beta. I mean it's usable now and I'd argue that spellchecking plus whitelisting satisfies a MVP, no? The earlier we get started with automatic releases the better I think.

[kentcdodds]

@jonathanewerner you're probably right... I just didn't want people to start using it, then upgrade and get a bunch of new errors and perhaps break builds etc. I guess we could just make every validator change a breaking change :-/ Though ESLint is similar and doesn't do this...

[jonathanglasmeyer]

Interesting question how to handle semver with a tool like this. I guess a breaking change would be a change of webpack-validators user facing api, whereas new errors thrown wouldn't count as breaking in our case. You don't want people to hesitate updating this because of major-version-update fear. It's expected behavior for this tool to yell as often as possible. I'm just thinking loud, not 100 percent convinced of my argumentation. :D

[kentcdodds]

ping @jonathanewerner https://github.com/kentcdodds/webpack-validator/pull/33

[jonathanglasmeyer]

Wow you're fast. Good stuff. I think a related task would be letting the user opt in to error throwing, defaulting to console.warn.

[kentcdodds]

Actually, right now we're not throwing errors at all. But when we build the CLI (I think @nyrosmith is working on that too) then we could have people opt-into throwing when there are errors.

[kentcdodds]

To be clear, the difference between an error and a warning is just the color. It's currently just using console.log

[jonathanglasmeyer]

I was thinking hypothetically. :) I'm not sure if cli usage is a dependency of this idea -- will create a task for this to flesh this out.

[jonathanglasmeyer]

Extracted this idea to #34.