feat(eslint-plugin): Regenerate recommended config

[bradzacher]

Also fix the bugs in the generation script.

Fixes #353

[mysticatea]

Would you ensure this will be released in the next major version? (semantic-release or conventional commits seem to require BREAKING CHANGE: text in the commit message)

[j-f1]

Should we add a check in CI that regenerates the config and ensures that it isn’t changed from the committed version?

[ldrick]

This PR is related and fixed in #313 too

[bradzacher]

@ldrick yeah I know, but your changes are a lot heavier and require some discussion from the core team first.
I wanted to wait, but I thought that as this was much smaller, I could slip it in quickly to correct the config before your PR is discussed and merged.

---

@j-f1 I thought about doing that right now, but I wanted this to be a tiny PR to slip in quickly to fix the issue.
I was thinking we could wait for #313 to be merged before setting up that CI script.
Hoping that we can discuss and merge that PR reasonably quickly.

---

@mysticatea - is adding new rules to the recommended config considered a breaking change?
Removing them from recommended could certainly be considered breaking, but isn't adding new rules a backwards compatible feature addition?

If it is breaking, then either:

• we're going to either be waiting a long time to add new rules to the recommended set (because we don't hugely want to release breaking changes to just do that one thing).
• or we're going to get super high version numbers because of the number of rules that are being added (there's 10 open PRs to add new rules, if each of those is released individually and added as recommended at the same time, we'll be at v11 [yes, I doubt we'd add all of them to recommended, and I doubt they'll be released individually, but the point still stands]).

[codecov]

Codecov Report

Merging #354 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master     #354   +/-   ##
=======================================
  Coverage   97.24%   97.24%           
=======================================
  Files          67       67           
  Lines        2357     2357           
  Branches      336      336           
=======================================
  Hits         2292     2292           
  Misses         44       44           
  Partials       21       21

Impacted Files	Coverage Δ
packages/typescript-estree/src/parser.ts	93.06% <ø> (ø)	⬆️
packages/eslint-plugin/src/util/createRule.ts	100% <ø> (ø)	⬆️
packages/parser/src/parser.ts	100% <ø> (ø)	⬆️
packages/parser/src/analyze-scope.ts	98.69% <ø> (ø)	⬆️
.../eslint-plugin/src/rules/promise-function-async.ts	100% <ø> (ø)	⬆️
packages/eslint-plugin/src/util/misc.ts	80% <0%> (ø)	⬆️

[mysticatea]

Should we add a check in CI that regenerates the config and ensures that it isn’t changed from the committed version?

It's better, but I didn't request such a check. I just wanted to make sure it because the commit message didn't contain any sign about breaking changes.

is adding new rules to the recommended config considered a breaking change?

Definitely yes. It's a breaking change because the CI builds which use the recommended config gets reporting the new errors then fail. We must not break user's CI builds without a major release.

ESLint Semantic Versioning Policy is useful for plugins as well.

Generally, ESLint doesn't update recommended preset when a new rule is added. They consider to update the recommended preset when making a major release, like eslint/eslint#11518.

[bradzacher]

We should make note of the elsint semver policy in our readmes for future reference.

I'll close this then, considering we're doing a breaking change, we can wait for #313