-
Notifications
You must be signed in to change notification settings - Fork 29.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
tools: avoid let in for loops #9049
Conversation
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 the PR! This generally looks good to me, aside from one small change.
return { | ||
'ForStatement': (node) => testForLoop(node), | ||
'ForInStatement': (node) => testForLoop(node), | ||
'ForOfStatement': (node) => testForLoop(node) |
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.
The implementation for ForStatement
nodes looks good. I think checking ForInStatement
and ForOfStatement
nodes is a good idea, but I don't think this rule is correctly checking those nodes at the moment, since they don't have an init
property. Instead, I think you would want to check the left
property.
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.
Ah that's right. Thank you for pointing that out! I feel silly about that one. I will update the file.
So it looks like you will need to add an entry into the You can check http://eslint.org/docs/developer-guide/working-with-rules#runtime-rules for more details edit: you may want to alternatively put it in once the rule is added you will notice TONS of failures in our test / benchmark directories. You will likely want to fix all of those in a separate commit. Once you have done that you will want to rebase the rule to after the changes, so that the repo will always be in a working state.
this will give you a list of commits, you can then move the commits around in that list, save, and close. This will edit the history You will likely want to compile and test locally to make sure it works.
Let me know if you have any questions 😄 |
* Report function to test if the for-loop is declared using `let`. | ||
*/ | ||
function checkForLet(node) { | ||
if (testForLoop(node) || testForInOfLoop(node)) { |
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 don't think that we need to run both checks on every iteration. It may be better to have a bit of repeated code instead of doing an extra evaluation on every for loop.
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.
That makes a lot of sense! I will update the test and add it to the .eslintrc. I was wondering if it would be more appropriate to report an error or simply a warning on the rule?
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 go with error.
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.
@thealphanerd okay! thank you
Is there any context on why to avoid |
|
||
return { | ||
'ForStatement': (node) => checkForLet(node), | ||
'ForInStatement': (node) => checkForLet(node), |
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.
Use checkForLet
(point-free style). (node) => checkForLet(node)
is a unnecessary wrapper.
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.
@princejwesley I think this was based on the way a number of other lint rules have been designed
@Trott can you chime in?
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 the suggestion from @princejwesley is a good one. The other tests that use a wrapper are also passing context
because it is out of scope the way they are written, but not this one.
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.
Thank you @princejwesley ! I've learned (more formally) about tacit programming from this review. :)
@cosmosgenius See #8637. At the moment, |
Nit: To be consistent with naming conventions in ESLint itself, maybe change the name of the rule from |
@@ -0,0 +1,41 @@ | |||
/** | |||
* @fileoverview Prohibit the use of `let` in `for` loops. |
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.
Nit: Maybe specify that it's just the declarations (or whatever the right terminology is)? I think this makes it sound like we're forbidding it in the body as well, but we're not.
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.
from the mdn docs
I think it would make sense to refer to it as the prohibit the use of let in for loop initialization
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.
@Trott Definitely agree with you. I changed the wording to have Prohibit the use of
letas the loop variable in the initialization of for, and the left-hand iterator in forIn and forOf loops.
Which may be too verbose? I just missed @thealphanerd comment before changing this. Let me know what you think!
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 OK with comments being verbose. 👍
Aside/question: I know there are benchmarks that show |
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.
Only change I'd want to see is reporting the right column, although honestly, if that is onerous or controversial, this can land as is.
*/ | ||
function checkForLet(node) { | ||
if (testForLoop(node) || testForInOfLoop(node)) { | ||
context.report(node, msg); |
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.
Nit: In my opinion, this ends up reporting the wrong column. It indicates the issue is in the column where for
starts, but it should really report the column where let
occurs. Is it possible to fix that? Maybe instead of returning a boolean, testForLoop()
and friends can return the offending node and that can be passed to context.report()
rather than the for
node?
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 @Trott, with the review given from @thealphanerd, I broke up this function and returned the offensive node as you suggested to report the correct column!
Oh, and +1 to adding it to |
thanks for the review @Trott @jessicaquynh if you move the rule to the |
LGTM. |
nit: the subsystem should be tools, not eslint, in the commit message. Thanks for the patience through the review process @jessicaquynh 🎉 |
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
This adds a new ESLint tool to check for let declarations within the for, forIn, forOf expressions. Fixes: nodejs#9045 Ref: nodejs#8873
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
This adds a new ESLint tool to check for let declarations within the for, forIn, forOf expressions. Fixes: nodejs#9045 Ref: nodejs#8873 PR-URL: nodejs#9049 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Teddy Katz <teddy.katz@gmail.com> Reviewed-By: Prince John Wesley <princejohnwesley@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Landed in b16a97e |
This adds a new ESLint tool to check for let declarations within the for, forIn, forOf expressions. Fixes: #9045 Ref: #8873 PR-URL: #9049 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Teddy Katz <teddy.katz@gmail.com> Reviewed-By: Prince John Wesley <princejohnwesley@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
This adds a new ESLint tool to check for let declarations within the for, forIn, forOf expressions. Fixes: #9045 Ref: #8873 PR-URL: #9049 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Teddy Katz <teddy.katz@gmail.com> Reviewed-By: Prince John Wesley <princejohnwesley@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
This adds a new ESLint tool to check for let declarations within the for, forIn, forOf expressions. Fixes: nodejs#9045 Ref: nodejs#9553 Ref: nodejs#8873 PR-URL: nodejs#9049 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Teddy Katz <teddy.katz@gmail.com> Reviewed-By: Prince John Wesley <princejohnwesley@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
This adds a new ESLint tool to check for let declarations within the for, forIn, forOf expressions. Fixes: #9045 Ref: #9553 Ref: #8873 PR-URL: #9049 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Teddy Katz <teddy.katz@gmail.com> Reviewed-By: Prince John Wesley <princejohnwesley@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Checklist
Affected core subsystem(s)
Tools.
Description of change
This adds a new ESLint tool to check for let declarations within the for, forIn, forOf expressions.
Fixes: #9045
Ref: #8873