New: Allow plugins to define rule replacements

[pavloconuve]

Summary

Provide better error message for removed rules by allowing plugins to define rule replacements.

Related Issues

Adding deprecation message to ESLint itself (#1549).

[eslint-deprecated]

Hi @mykhalov!, thanks for the Pull Request

The first commit message isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The commit message tag must be one of the following:

  The Tag is one of the following:

  • Fix - for a bug fix.
  • Update - either for a backwards-compatible enhancement or for a rule change that adds reported problems.
  • New - implements a new feature.
  • Breaking - for a backwards-incompatible enhancement or feature.
  • Docs - changes to documentation only.
  • Build - changes to build process only.
  • Upgrade - for a dependency upgrade.
  • Chore - for anything that isn't user-facing (for example, refactoring, adding tests, etc.).

  You can use the labels of the issue you are working on to determine the best tag.

• There should be a space following the initial tag and colon, for example 'New: Message'.

• The first letter of the tag should be in uppercase

Read more about contributing to ESLint here

[eslint-deprecated]

Hi @mykhalov!, thanks for the Pull Request

The first commit message isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The commit message tag must be one of the following:

  The Tag is one of the following:

  • Fix - for a bug fix.
  • Update - either for a backwards-compatible enhancement or for a rule change that adds reported problems.
  • New - implements a new feature.
  • Breaking - for a backwards-incompatible enhancement or feature.
  • Docs - changes to documentation only.
  • Build - changes to build process only.
  • Upgrade - for a dependency upgrade.
  • Chore - for anything that isn't user-facing (for example, refactoring, adding tests, etc.).

  You can use the labels of the issue you are working on to determine the best tag.

• There should be a space following the initial tag and colon, for example 'New: Message'.

Read more about contributing to ESLint here

[nzakas]

This section should explain how you plan to implement this. Please look at the ESLint code and figure out which files would need to change. There are plenty of examples of already-merged RFCs in this repo to see what is expected.

[nzakas]

There’s really no other alternatives? What about plug-ins themselves continuing to ship a rule that always reports that the rule is replaced by another rule?

[nzakas]

None?

[nzakas]

Does this mean you already know how to implement this change?

[pavloconuve]

After digging into eslint and eslintrc source code it seems like there is a great effort required to provide a dynamic list of replacements vs reading from a JSON config as ESLint currently does. That effort doesn't seem to match the would-be benefit for development experience.

[nzakas]

Thanks @mykhalov.