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
Change Request: Support additional rule metadata for deprecations #18061
Comments
ping @eslint/eslint-team |
@kecrily please tag @team when moving an issue across the board. I think folks did not get a notification for this. |
Yes, that's true, and "Evaluating" is meant to be when you, personally, are evaluating it. That means you should leave a comment indicating that's what is happening. If instead your intent was to ask other team members for their opinion, then you should also leave a comment and move to "Feedback Needed." In any event, please don't just move the issue into a different column without comment. :) |
My opinion: This is worth exploring, but we should do it through an RFC to make sure it gets the appropriate amount of attention and exploration. Would like some other opinions. |
Is there a strong motivation to have two properties here? As in, is there a time when a rule would reasonably have If the |
If we were designing this from scratch, then yeah I'd likely put everything inside the Would be good to hear any other preferred design choices before I write up the RFC. |
Thinking about it some more, perhaps I can just leave |
The only other point that comes to mind for me is being able to specify options in the new rule. https://github.com/typescript-eslint/tslint-to-eslint-config -> https://github.com/typescript-eslint/tslint-to-eslint-config/blob/470d44de20beb7c7366de993edb8898d0766b8aa/docs/Architecture/Linters.md might be a good reference. Deprecated rules could map to multiple new ones, including specifying options and changed or missing functionality. Not suggesting rules should include a transformer function themselves - just posting as examples of what information users might want to know. |
It seems like there's interest in pursuing further, so marking as accepted and moving to "Waiting for RFC". |
I put together an RFC! |
ESLint version
8.56.0
What problem do you want to solve?
There are long-time rule properties
meta.deprecated
andmeta.replacedBy
that have been intended to document when rules are deprecated and what their replacement rule(s) are. For the most part, usage would look something like this:These properties are often used for generating plugin/rule documentation websites and in documentation tooling like eslint-doc-generator.
But there are some limitations to this current format.
prefix/rule-name
while others just provide it asrule-name
, which can result in ambiguity about whether the replacement rule is in the same plugin, a different third-party plugin, or ESLint core. For third-party plugins, there's no easy way to automatically determine where their documentation is located or how to link to them.What do you think is the correct solution?
I would like to propose an extended
meta.deprecated
/meta.replacedBy
rule property schema to reduce ambiguity and allow additional key details to be represented in it, described below as a TypeScript type for clarity:Real-world example of how this could be used based on the situation in #18053:
This data could be used by documentation websites and tooling like eslint-doc-generator to generate notices like:
We can also support the same
meta.deprecated
andmeta.replacedBy
properties on configurations and processors (the other kinds of objects exported by ESLint plugins), replacingrule
withconfig
orprocessor
as needed.In terms of actual changes needed for this:
meta.replacedBy
in core rules as desired (such as in Docs: Mention Stylistic as the source of replacement rules for all the stylistic rules that got deprecated #18053, Fix: remove custom plugins from replacedBy metadata #13274)This proposal is inspired by:
Related:
Participation
Additional comments
No response
The text was updated successfully, but these errors were encountered: