lint-to-the-future remove command

[mansona]

We want to be able to run the command npx lint-to-the-future remove "rule-name" and it would remove all rule-name ignores from every file that it happens in.

To be more specific, if you run npx lint-to-the-future list and it reported the following:

{
  '2022-09-30': {
    'lint-to-the-future-ember-template': {
      'no-redundant-landmark-role': [Array]
    },
    'lint-to-the-future-eslint': {
      'ember/no-empty-glimmer-component-classes': [Array],
      'ember/no-classic-components': [Array],
      'ember/no-classic-classes': [Array],
      'ember/require-tagless-components': [Array]
    }
  }
}

and then you ran the following command:

npx lint-to-the-future remove "ember/no-classic-classes"

running npx lint-to-the-future list again would report:

{
  '2022-09-30': {
    'lint-to-the-future-ember-template': {
      'no-redundant-landmark-role': [Array]
    },
    'lint-to-the-future-eslint': {
      'ember/no-empty-glimmer-component-classes': [Array],
      'ember/no-classic-components': [Array],
      'ember/require-tagless-components': [Array]
    }
  }
}

Implementation considerations:

• because of the nature of the plugin structure, there is a possibility that 2 plugins could have the same name for a lint rule. in this case if eslint and ember-template-lint both reported the same name and you tried to remove it I think it's better to have lttf warn the user and maybe pass --all-plugins or something? maybe this could be the default behaviour??
• this is a new command so we would need to add remove() to the public API of a plugin (and document it in the plugin development guide). This means that there could be plugins installed that don't support this remove() functionality. Do we do this with peer dependencies or something to make sure they support the command? or do we just warn the user that they have plugins that don't support it installed with a "update or contact the plugin developers" message.

[rtablada]

While it doesn't look for particular rules, I have implemented a autofix command in https://github.com/rtablada/pod-workflow-cli which will remove lint ignores for a given file or directory (with CLI input or an interactive file tree using inquirer).

While a some of that tool is currently coupled to a pod structure deprecation/lint flow, there could be prior art there that could be moved into a lint-to-the-future command

Consideration here though is that LTTF would likely want to move the logic of regex replacement and delegate that to the plugin.