New Feature Proposal - Auto-Gen Todo List

Right now there isn’t (to my knowledge, please correct me if I’m wrong 😀 ) the capability for ESLint to suppress the current violations so existing code bases can adopt ESLint with CI without having to fix their existing files first.

I’d like to change that, using Rubocop’s auto-generated configuration as inspiration. I’ve already developed a proof of concept solution that:

• Generates a .eslintrc-todo.yml based on the currently reported violations, and disables those rules for the affected files:

overrides:
  -
    rules:
      class-methods-use-this: 0
    # Note that files are excluded on a per-rule basis.
    files:
      - src/ZhuLi/DoTheThing.js
      - src/ZhuLi/DoTheOtherThing.js

• Adds the new .eslintrc-todo.yml entry to the extends entry and recreates the .eslintrc.yml file.

Proposed Solution

I’m planning to:

• Leverage the solution above and add support for updating the other configuration file types (with the exception of .eslintrc.js, not sure how I’d update a JS file).
• Wire the solution to the CLI and add a --create-todo option.
• Exclude the todo list config file when re-running with --create-todo.

Questions

1. Would a PR for this feature be accepted?
2. Are there any issues with the high-level approach I’ve outlined?
3. Are there any areas I should pay close attention to as I’m building this?

[richseviora]

@ndushay I’ve created eslint-takeoff as an alternative if/until this capability is added to ESLint itself. PRs, suggestions, bug reports are welcome 😄

[richseviora]

I’m familiar with “probably overthinking” things too. 🤣

The workflow I’ve found works best is almost what you described, the only difference is that I drop the overrides for that file first and then fix them. Lets me take advantage of IDE integration instead of having to drop back out to CLI to check as necessary.