-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Fix: id-blacklist should ignore ObjectPatterns (fixes #12787) #12792
Conversation
@jpramassini eslint/tests/lib/rules/id-blacklist.js Line 69 in ec3983c
Your changes should pass these test cases. // valid
{
code: “const { foo: bar } = baz”,
options: [“foo”],
parserOptions: { ecmaVersion: 6 }
}
// invalid
{
code: “const { foo: bar } = baz”,
options: [“bar”],
parserOptions: { ecmaVersion: 6 },
errors: [
// ...
]
} |
@yeonjuan This is a very good point, dumb mistake on my part. I'll update my test cases later today. Update: My code doesn't work with accurate test cases, so I'll revisit my approach 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.
Thanks for contributing! I don't think this current iteration is going to work since BlockStatement
nodes aren't related to the bug in question. Here's what the AST looks like for a destructured assignment.
I also want to note that the fix should be to not warn on destructured assignments at all. From the rule docs (emphasis my own):
Ideally, I do think the rule should warn when a property is renamed to a blacklisted identifier name in a destructuring assignment, but I also think that can (and probably should) be done in a separate PR as a separate bug fix. |
@kaicataldo Thanks for the help on the AST! I'll take another crack at this. |
@kaicataldo Updated to ignore in Object Pattern nodes, and removed the error test case as we want to ignore it for this PR. |
You got it! Feel free to reach out with any questions you have :) |
We're getting closer! Thanks for working on this. |
Do we want an error test case for |
Sorry, that wasn't a great example. I think a test for the destructured parameters is sufficient. In the example above, that would be having |
That being said, additional tests are always welcome :) |
I think between the existing function name tests and the added nested and destructured arguments we should be covered, so I left it out. |
One last thing from me: do you mind updating the PR title to more accurately reflect the current iteration of this PR? |
} else if (node.parent.type === "Property") { | ||
|
||
if (shouldReport(effectiveParent, name)) { | ||
report(node); | ||
} | ||
|
||
// Report anything that is a match and not a CallExpression | ||
// Report anything that is a match and not a CallExpression |
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.
Mind undoing this? This is referring to the following block and I think it's clearer to have it indented as it was.
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.
Just pushed a commit that should fix this, the commit has these lined up properly but for some reason the diff doesn't seem to have updated.
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.
Yeah, I see that. Strange :/ Seems like something on GitHub's end?
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.
Seems like it. This is the first time I've had this happen. 🤷♂
Re the commit message check that's failing now: How about changing it to |
Thanks for your patience and help, sorry for all the small gotchas here. |
You're doing great. We really appreciate the contribution! |
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.
This LGTM. Thank you for contributing to ESLint!
Awesome, thanks again for all of your help! |
@@ -65,6 +65,26 @@ ruleTester.run("id-blacklist", rule, { | |||
code: "var obj = { key: foo.bar };", | |||
options: ["f", "fo", "fooo", "b", "ba", "barr", "bazz", "bingg"] | |||
}, | |||
{ | |||
code: "const {foo: bar} = baz", | |||
options: ["foo", "bar"], |
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.
@jpramassini
Hi, In my opinion, this case should be included in invalid
because it makes a new identifier bar,
which is in the id-blacklist.
Ideally, I do think the rule should warn when a property is renamed to a blacklisted identifier name in a destructuring assignment, but I also think that can (and probably should) be done in a separate PR as a separate bug fix.
I got it
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.
Yeah, this should definitely be invalid at some point due to the spirit of the rule. I added that to try and illustrate for now that that's intended behavior for now. Should I make a separate issue to make sure that gets tracked?
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.
Should I make a separate issue to make sure that gets tracked?
Maybe it would be welcomed, but it is up to you. :)
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.
An issue would be great!
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.
LGTM, thanks for fixing this!
@kaicataldo Unsure of where to put this, this seems like the best place to follow up. For the issue to track the reassignment identifier warning for this rule, should that issue be categorized as a bug fix, or is it a rule change proposal? |
I think it should be categorized as a semver-minor bug fix (reported as a bug fix). |
@kaicataldo New issue here: #12807 |
…slint#12792) * Fix: Ignore destructured object property reassignments. (fixes eslint#12787) * Updated to ignore blacklisted id's in ObjectPattern nodes. * Remove console.log. * Added tests for nested destructuring and destructuring function parameters. * Fix typo. * Undo accidentally auto-fixed comment indent.
What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[X] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
#12787
What changes did you make? (Give an overview)
I modified the should report logic to check that the
effectiveParent
'sparent
is a block statement and added tests for the case.Is there anything you'd like reviewers to focus on?
Thoughts on any potentially cleaner ways to accomplish this? This is my first PR to ESLint so I want to make sure it's up to snuff.