Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect usage of deprecated rules #90

Closed
matthieu-crouzet opened this issue Sep 16, 2024 · 2 comments
Closed

Detect usage of deprecated rules #90

matthieu-crouzet opened this issue Sep 16, 2024 · 2 comments

Comments

@matthieu-crouzet
Copy link

It would be great to have a CLI to retrieve the list of deprecated rules activated (warn/error).
With that it would be easy to detect when some rules became deprecated while upgrading ESLint plugins versions.

The rule could be well deactivated if it is set to off for the same set or a superset of files compare to the set of files for which it is activated.
e.g.

[
  // Config coming from an external ESLint plugin
  {
    rules: {
      'my-deprecated-rule-1': 'warn',
      ...
    },
    files: ['**/*.{c,m,}{t,j}s']
  },
  // Local overrides
  {
     rules: {
       'my-deprecated-rule-1': 'off',
       ...
     },
    files: ['**/*']
  },
  {
     rules: {
       'my-deprecated-rule-2': 'off',
       ...
     },
    files: ['**/*.ts']
  }
]

In this case my-deprecated-rule-1 is well deactivated but my-deprecated-rule-2 is not because still activated for ['**/*.{c,m,}js', '**/*.{c,m}ts']

It also could be great to detect "useless overloaded" rules
e.g.

[
  // Config coming from an external ESLint plugin
  {
    rules: {
      'my-rule': ['error', { configItem: 1 }]
    }
  },
  // Local override
  {
    rules: {
      'my-rule': ['error', { configItem: 1 }]
    }
  }
]

In this case I want to be aware that my local override is useless as it's already configured like that (only if the glob of the override is equal or a subset of the one defined in configuration from the plugin)

@ferferga
Copy link

Deprecated rules are shown straightaway in the UI:

Image

If you mean it in a CLI environment only, that is something with a bigger scope (I'd rename this issue to "Provide a CLI interface" in that case), since the inspector right now is just GUI-based, there's no CLI functionality.

Perhaps, it could even be said that it's out of the scope of this project and might fall better into upstream (eslint)?

@antfu
Copy link
Collaborator

antfu commented Oct 28, 2024

Yeah, I think the point of having a UI inspector is that we would have complex requirements/viewports towards the config data, which CLI couldn't easily represent. Redoing the features of the inspector in CLI is considered out-of-scope of this project.

@antfu antfu closed this as not planned Won't fix, can't repro, duplicate, stale Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants