Provide an output to show config cascade for each rule

[moniuch]

I would like to propose a new command (or flag) that would produce a new type of output for administrative use.
The output would allow to determine the cascade of origins of each rule.

Not sure this is feasible technically, but let me describe how it would help.

1. Why

Given the cascade nature of eslint configs and the rule sources, it can be really difficult in more complex or neglected projects to review or debug the existing configuration, and specifically which configs contribute to introducing a given rule.

During that review process one might need to figure out:

• where a rule originates from,
• whether it is introduced by a plugin or an override,
• how different configurations set the rule's severity, and
• whether removing a specific configuration will leave a given rule still active.

2. How

To help users with it, eslint could offer an output where the cascade of sources is clearly listed, by looking recursively at all overrides as well as extended configs and plugins.

Since the output I would expect is very similar to that from eslint --print-config I would think that a flag could be added to extend this output with additional rule information.

Let's say:

• eslint --print-config --list-rule-sources ./example.ts

The additional bits of meta information would be an array of all the sources introducing given rule, along with its severity.

Example

Given the --print-config output is as follows:

{
  "env": {},
  // ...
  "plugins": [
    "@angular-eslint",
    "@typescript-eslint",
    "@angular-eslint/template"
  ],
  "rules": {
    "if-curly-formatting": [
      1
    ],
    // ...
  }
}

we could have additional key at the root level:

{
  "env": {},
  // ...
  "rules-sources": {
    "if-curly-formatting": [
      {"file": "node_modules/eslint-plugin-first-source", "severity": "error"},
      {"file": "./.eslintrc.json", "severity": "off"},
    ]
  }
}

It's just a very rough example, the details of the format TBD.

3. Performance

I assume retrieving the information I am asking here might be performance costly. Yet, given its administrative value and how much of tedious job it would save me, I would gladly wait longer in order to get reliable data.

[nzakas]

Unfortunately, this is just not feasible going forward. We aren't making any changes to the old config system, and the new config system does away with the concept of files altogether, so there is no source for the data you're looking for.

Your best bet is to run ESLint with --debug and follow the steps there.