feat: additional rule metadata for deprecations #124
Conversation
| 5. Which "extension points" (rules, processors, configurations, parsers, formatters) shold be supported? | ||
| 6. Should the `rule` key be dependent on the "extension point" (e.g. `processor` for processors) or renamed (e.g. ``) so that it is the same property name for all? |
There was a problem hiding this comment.
I think the scope of this RFC is just rules deprecations. But if we are already anticipating that other extension points (processors, configurations, parsers, formatters) will have deprecation info, with the same shape, then a more generic name like replacement might have sense, so that it's the same property name for all.
There was a problem hiding this comment.
I do not know of examples for other extension points being deprecated but especially with the introduction of language plugins, I can see some processors being deprecated (e.g. eslint-plugin-markdown).
Co-authored-by: Milos Djermanovic <[email protected]>
| - Ensure these properties are allowed on configurations, parsers and processors | ||
| - Add any additional information to these properties in core rules as desired (such as in <https://github.com/eslint/eslint/issues/18053>) | ||
| - Update ESLint's website generator to take into account the additional information for rule doc deprecation notices | ||
| - Update [LintResult.usedDeprecatedRules](https://github.com/eslint/eslint/blob/0f5df509a4bc00cff2c62b90fab184bdf0231322/lib/eslint/eslint.js#L197-L211) |
There was a problem hiding this comment.
Can you add more details about this change? Shall we keep the existing replacedBy: string[] property and/or add a new one with the DeprecatedInfo object?
There was a problem hiding this comment.
I think that removing or changing the format of DeprecatedRuleInfo.replacedBy could break existing tools like custom formatters. Maybe it would be better to expose the RuleMeta.deprecated object as a new property of DeprecatedRuleInfo?
There was a problem hiding this comment.
I think we should normalize the old and new format for replacedBy and provide the new data if available under a new property named info as this backwards-compatible.
There was a problem hiding this comment.
I think we should normalize the old and new format for
replacedByand provide the new data if available under a new property namedinfoas this backwards-compatible.
Sounds good to me.
| - Ensure these properties are allowed on configurations, parsers and processors | ||
| - Add any additional information to these properties in core rules as desired (such as in <https://github.com/eslint/eslint/issues/18053>) | ||
| - Update ESLint's website generator to take into account the additional information for rule doc deprecation notices | ||
| - Update [LintResult.usedDeprecatedRules](https://github.com/eslint/eslint/blob/0f5df509a4bc00cff2c62b90fab184bdf0231322/lib/eslint/eslint.js#L197-L211) |
There was a problem hiding this comment.
I think that removing or changing the format of DeprecatedRuleInfo.replacedBy could break existing tools like custom formatters. Maybe it would be better to expose the RuleMeta.deprecated object as a new property of DeprecatedRuleInfo?
|
@DMartens there's a bunch of feedback here. Are you still working on this? |
|
Sorry for dropping the ball on this.
I am still committed to finishing this proposal. |
Co-authored-by: Milos Djermanovic <[email protected]>
nzakas
added
Final Commenting
|
Final commenting period has ended, so merging. @DMartens feel free to open an implementation PR when ready. |
Summary
This is a continuation of #116 by @bmish to specify additional properties for rule deprecations.
The main changes are:
meta.deprecatedand deprecatemeta.replacedBykind,deprecatedSince,availableUntilRelated Issues