feat(config): added shareable configuration plugin:jest/all

[nickineering]

This pull request creates an "all" shareable configuration that enables all rules similar to eslint-plugin-react among others. It is a useful starting point for beginners who want to see everything the plugin is capable of before enabling selected rules, and can also make custom configurations less verbose.

I haven't previously contributed to this repository before, so please let me know if I missed anything that should have been included!

[jeysal]

Thanks for the PR @nferrara100!
@SimenB wdyt about this?
I'm unsure if it makes sense to have something like this for this plugin atm - there are rules such as the prefer-to-be-null family where I'd prefer nudging people towards literally doing the exact opposite.

[nickineering]

Thanks for the feedback! I wasn't aware some rules encourage poor practices. In that case would it make sense to deprecate those rules so the best practice is clear, or at the very least include a caution in the readme?

Perhaps this pull request should be modified to explicitly exclude deprecated rules, while still including the remaining rules? As said in my initial comment having an all setting is useful for beginners and as a starting point for other configurations. I would imagine most of the 22 rules not in the recommended configuration still have at least some value in that regard.

[jeysal]

I'd definitely like to change/deprecate some rules first if we'd introduce something like this. Or alternatively as you suggested making it more of a jest/strict that still doesn't include some of the questionable rules.
But let's see what Simen says if he has some time, he's been doing most of the work here lately :)

[SimenB]

I'm down with adding this, as long as we document it as breaking all the time, and we're sure none of the rules conflict (I don't think any do, haven't verified though).

We can also include some sort of strict config, but having an all (even though some rules might be less useful) makes sense to me. I guess the use case is "add all the things", and make rules opt-out rather than opt-in, increasing discoverability?

[nickineering]

I didn't think to check for conflicting rules, but I can't think of any off hand. Is there a good automated way I could test that?

[SimenB]

@nferrara100 no, not really. Just running config on large code bases with all rules and see if the rules conflict as they're fixed or not.

[SimenB]

add a caveat about this not being subject to semver, so use with caution, blahblah 🙂

[nickineering]

Done

[nickineering]

I incorporated the changes to the readme suggested by @SimenB. I also ran the configuration against the React codebase and didn't see anything that appeared abnormal to me. It raised 6645 errors, so obviously I didn't attempt to correct them all, but in general it was a neat way to learn about rules I hadn't used before, which is one of the main use cases for this configuration. I also ran it against a personal codebase of mine and didn't get any conflicts, but that is pretty small so it may have just been luck. If anyone has a more pointed test they would like to see done, or has a more in depth knowledge of the various rules, please let me know.

[SimenB]

Thanks!

[SimenB]

🎉 This PR is included in version 22.7.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀