Improve configuration validation

[onigoetz]

Fixes #567

This pull request introduces a custom validator that replaces jest-validate

Improvements over the previous implementations are:

• You can now set a function as a renderer
• Validations can be more precise
• Linters are validated (check that key is a glob, and that values are a string or array of strings)
• valid values for renderer are now explicit, where any string was possible before
• Check that ignore is an array of strings

I tried to use joy yup and schema-utils to express the schema to validate, but it felt more verbose and less flexible with regard to the number of possible options.

I just ensured that current tests pass, I can write more tests if needed.

[codecov]

Codecov Report

Merging #572 into master will increase coverage by 0.12%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #572      +/-   ##
==========================================
+ Coverage   98.02%   98.14%   +0.12%     
==========================================
  Files          13       13              
  Lines         354      377      +23     
  Branches       45       52       +7     
==========================================
+ Hits          347      370      +23     
  Misses          7        7

Impacted Files	Coverage Δ
src/getConfig.js	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 406a0c0...130720e. Read the comment docs.

[okonet]

I’m wondering why you decided to ditch the jest-validate since it was giving the flexibility of providing it with updated config a and get the deprecation warnings automatically. Also lots of these now hard coded checks does make the code less maintable. Have you considered adding the fix as a special case like we did with globs?

[onigoetz]

Because in the current version, jest-validate can't handle different types in the same fields, this will come in version 24 (https://github.com/facebook/jest/blob/master/packages/jest-validate/src/index.js#L18)

Also, jest-validate while being easier to setup is way less precise as it stops at the type of value in the field.

[okonet]

I’m wondering when 24 is going to be released and if we can contribute our use case to it. The reason I pushing back is that change going to introduce a lot of chore related to the config to maintainers (reas: me) and I don’t have enough time for this right now. So if we could stick to an automated yet not perfect solution I’d prefer that instead.

[onigoetz]

I'll check for alternative solutions then

[onigoetz]

Hi @okonet, I changed the implementation to use yup instead.
The code is smaller in terms of boilerplate, but there is still more code than before.

In exchange, the configuration validation is more precise and I added more tests to ensure it won't take you by surprise in the future.

[okonet]

That's much better! Thanks for working on it.

[okonet]

BTW I noticed that Jest v24 was released but I guess jest-validate still has some limitations, right?

[okonet]

🎉 This PR is included in version 8.1.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[onigoetz]

Awesome, thanks for the release :)

I also saw it was released, It solves the issue of having multiple types for the same field, which is one part of the PR. It doesn't help have more precise diagnostics on the types and linter object