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
New: no-global-assign
rule (fixes #6586)
#6746
Conversation
LGTM |
@alberto, thanks for your PR! By analyzing the annotation information on this pull request, we identified @mysticatea, @jrajav and @nzakas to be potential reviewers |
@@ -1,6 +1,7 @@ | |||
/** | |||
* @fileoverview Rule to flag adding properties to native object's prototypes. | |||
* @author David Nelson | |||
* @deprecated in ESLint v3.2.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.
Sorry, I don't remember what did we decide. Do we just leave the old rule unchanged, or should we remove all of the code and just do module.exports = require('./no-global-assign');
? I guess former, since we don't want new changes to the rule to be propagated to deprecated 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.
Yes, that's what we decided in #6586 (comment)
Oh, we should deprecate no-native-reassign rule, not no-extend-native rule. |
Is the deprecated rule removed from rule list page? |
Oops! 😅
No. I don't think it should be removed since it's still available and actually part of |
no-global-assign
rule (fixes #6585)no-global-assign
rule (fixes #6586)
LGTM |
Looks good to me. Thank you! |
We also need to figure out where to list deprecated rules and add a deprecation notice to the rule docs. Possibly, we should add this into the rule |
docs: { | ||
description: "disallow assignments to native objects or read-only global variables", | ||
category: "Best Practices", | ||
recommended: true |
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.
Not actually recommended, correct?
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.
Oh, you are right
Yes, I think deprecated should become another meta property. I think @mysticatea already assumed as such with his PR for |
I'm 👍 on |
I would be willing to help out with this issue if no one minds. I also had
|
@vitorbal No, it's all yours. |
LGTM |
I have updated the PR with the suggestions above and added a new section @vitorbal now that I had a look at how the generation is done, I realized that maybe you referred to the changes in the site repo? Let me know if there is anything else needed here |
@alberto I think you actually got it covered now with your latest commits. edit: Ok, I think I figured it out. I will send a PR in the site repo for adding the list of deprecated rules in |
@@ -8,6 +8,13 @@ | |||
{ "name": "Stylistic Issues", "description": "These rules relate to style guidelines, and are therefore quite subjective:" }, | |||
{ "name": "ECMAScript 6", "description": "These rules relate to ES6, also known as ES2015:" } | |||
], | |||
"deprecated": { | |||
"name": "Deprecated", | |||
"description": "These rules have been deprecated and replaced by newer rules.", |
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.
For the "removed" rules we end the description with a colon instead of a dot. Should we do the same here for consistency?
@@ -209,6 +209,10 @@ function generateRuleIndexPage(basedir) { | |||
find(path.join(basedir, "/lib/rules/")).filter(fileType("js")).forEach(function(filename) { | |||
var rule = require(filename); | |||
|
|||
if (rule.meta.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.
Do we want to skip this entirely? Shouldn't there be a category for that?
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 could add it to the categoriesData.deprecated.rules
array here instead of doing it manually in https://github.com/eslint/eslint/pull/6746/files#r72645142
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 think that is a good idea. Less manual work is always preferable.
LGTM |
PR updated with suggestions from above. |
LGTM |
Lgtm |
LGTM |
What issue does this pull request address?
#6586
What changes did you make? (Give an overview)
Duplicate and rename
no-native-reassign
tono-global-assign
and mark the former as deprecated.Is there anything you'd like reviewers to focus on?
Let me know if the deprecation messages are enough and if the commit message and tag are correct for this kind on change.