-
Notifications
You must be signed in to change notification settings - Fork 14
Support new DeprecatedInfo format for rule meta.deprecated
#730
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
base: main
Are you sure you want to change the base?
Changes from 3 commits
8c38608
4436953
a0f8b6f
783837b
22be021
d90c3bb
479b0d8
ede4a08
4903b0d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -10,6 +10,7 @@ import { | |||||
| import { findConfigEmoji, getConfigsForRule } from './plugin-configs.js'; | ||||||
| import { | ||||||
| RuleModule, | ||||||
| DeprecatedInfo, | ||||||
| Plugin, | ||||||
| ConfigsToRules, | ||||||
| ConfigEmojis, | ||||||
|
|
@@ -104,6 +105,7 @@ const RULE_NOTICES: { | |||||
| fixable: boolean; | ||||||
| hasSuggestions: boolean; | ||||||
| urlConfigs?: string; | ||||||
| deprecatedInfo: boolean | DeprecatedInfo | undefined; | ||||||
| replacedBy: readonly string[] | undefined; | ||||||
| plugin: Plugin; | ||||||
| pluginPrefix: string; | ||||||
|
|
@@ -187,8 +189,8 @@ const RULE_NOTICES: { | |||||
| return `${emojis.join('')} ${sentences}`; | ||||||
| }, | ||||||
|
|
||||||
| // Deprecated notice has optional "replaced by" rules list. | ||||||
| [NOTICE_TYPE.DEPRECATED]: ({ | ||||||
| deprecatedInfo, | ||||||
| replacedBy, | ||||||
| plugin, | ||||||
| pluginPrefix, | ||||||
|
|
@@ -197,6 +199,43 @@ const RULE_NOTICES: { | |||||
| ruleName, | ||||||
| urlRuleDoc, | ||||||
| }) => { | ||||||
| // use object type `DeprecatedInfo` | ||||||
|
||||||
| if (typeof deprecatedInfo === 'object') { | ||||||
| const replacementRuleList = (deprecatedInfo.replacedBy ?? []) | ||||||
| .map(({ rule }) => | ||||||
| rule && rule.name | ||||||
| ? rule.url | ||||||
| ? `[\`${rule.name}\`](${rule.url})` | ||||||
| : `\`${rule.name}\`` | ||||||
| : undefined, | ||||||
| ) | ||||||
| .filter((rule): rule is string => typeof rule === 'string'); | ||||||
|
|
||||||
| return `${EMOJI_DEPRECATED} This rule is deprecated${ | ||||||
|
||||||
| return `${EMOJI_DEPRECATED} This rule is deprecated${ | |
| return `${EMOJI_DEPRECATED} This rule has been deprecated${ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, sorry, I'm not a native speaker of english
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want a comma-separative list with spaces.
| ? ` It was replaced by ${String(replacementRuleList)}.` | |
| ? ` It was replaced by ${replacementRuleList.join(', ')}.` |
I'm fixing in the existing code too: #731
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be improved even further, like
? ` It was replaced by ${
replacementRuleList.length > 1
? `${replacementsRuleLists.slice(0, -1).join(', ')} and ${String(replacementsRuleList.at(-1))}`
: replacementsRuleLists[0]
}.`There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to that. Would want to extract a helper function for it.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an interesting idea to use the hostname, but I think I'd rather just use this, and keep everything related to deprecations on the same line.
| ? `${EOL}${EOL}Read more at [${new URL(deprecatedInfo.url).hostname}](${deprecatedInfo.url})` | |
| ? `[Read more](deprecatedInfo.url).` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See this comment for desired format: #730 (comment)
bmish marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, while it's a nice idea to warn about this, I'd rather use a new lint rule in eslint-plugin-eslint-plugin to do this:
eslint-doc-generator is not really intended to warn about deprecations or older styles. That's the job of eslint-plugin-eslint-plugin.
So I'd like to remove the warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me it seems that the DeprecatedInfo has shifted the responsibility of correct links/data of deprecated rules towards the maintainers of eslint plugins. I think eslint-doc-generator should just display the data of the deprecated rules which makes the usage of getLinkToRule in [NOTICE_TYPE.DEPRECATED] obsolete. Please let me know if this is the desired approach.
To your question about this, I think I would still like to automatically fill in links for rules where we can. Including URLs in rule definitions is burdensome, and while rules theoretically could be responsible for it now, I assume many will omit it. However, we can try to use getLinkToRule as a follow-up if you'd like, doesn't have to be in the first version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to give it a shot. But first let me check if I understood it correctly and considered the relevant cases:
In case a user of eslint-doc-generator has set ReplacedByInfo#url we're good to go. Otherwise we'd use getLinkToRule as a fallback. The one case that's bothering me is when only ReplacedByInfo#name is set. If it has a plugin prefix we should compare it with the argument pluginPrefix to determine if it's an internal or external rule because we can't rely on ReplacedByInfo#plugin being set. If the name does not have a plugin prefix, getLinkToRule is used to determine if it is a built-in eslint rule or a internal plugin rule, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not totally sure. getLinkToRule might not handle every situation here.
If any scenarios are ambiguous or overly-complicated, we can just omit the link in them and consider as a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is boolean included here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typescript would complain about it when it's passed to
ruleNoticeStrOrFn(ts2322) becausemeta?.deprecatedstill includes thebooleantypeThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's call this
deprecatedto match the rule property name.