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
Update: add enforceInMethodNames option to no-underscore-dangle (fixes #7065) #7234
Conversation
@gabro, thanks for your PR! By analyzing the annotation information on this pull request, we identified @peteward44, @gyandeeps and @vitorbal to be potential reviewers |
Thanks for the pull request, @gabro! I took a look to make sure it's ready for merging and found some changes are needed:
Can you please update the pull request to address these? (More information can be found in our pull request guide.) |
Thank you for your pull request. It looks like this may be your first contribution to a jQuery Foundation project, if so we need you to sign our Contributor License Agreement (CLA). 📝 Please visit http://contribute.jquery.org/CLA/ to sign. After you signed, the PR is checked again automatically after a minute. If there's still an issue, please reply here to let us know. If you've already signed our CLA, it's possible your git author information doesn't match your CLA signature (both your name and email have to match), for more information, check the status of your CLA check. |
@@ -42,6 +42,7 @@ This rule has an object option: | |||
* `"allow"` allows specified identifiers to have dangling underscores | |||
* `"allowAfterThis": false` (default) disallows dangling underscores in members of the `this` object | |||
* `"allowAfterSuper": false` (default) disallows dangling underscores in members of the `super` object | |||
* `"enforceInMethodNames": false (default) allows dangling underscores in method names` |
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 if the name is "enforce" then it _dis_allows dangling underscores?
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 would make sense, but I was confused by the other options.
allowAfterSuper
=> disallows?
I assumed the description referred to the effect of the default option.
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, i hadn't read it that way. sounds good :-)
Hi @gabro, thanks a lot for your contribution. Could you do us a favor and fill in the template for proposing a rule change? We need all of this information in order to determine whether or not the change is a good candidate for inclusion. Thanks! |
Hi Vitor, I didn't complete the template because I understood it wasn't needed when there's an issue associated to it. gabriele On 26 Sep 2016, 11:18 +0200, Vitor Balocco notifications@github.com, wrote:
|
@gabro Oh sorry, that's my bad, I didn't notice there was already an issue associated with it. In that case, please disregard what I said :) |
Marking this as "do not merge" for now until we accept the corresponding issue (#7065) |
Just a heads up: we have moved to a new CLA checker on pull requests. Even if you've previously signed our CLA, we will need to you sign the new one. To do so, look at the status checks for licence/cla and click the "Details" link. Sorry for the inconvenience. |
ping @gabro |
@alberto not sure what the ping was about, but I took the opportunity to rebase the branch on top of master :) |
565016b
to
401ff81
Compare
Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn't get enough support from the team and so I'm closing it. While we wish we'd be able to accommodate everyone's requests, we do need to prioritize. We've found that issues failing to reach consensus after a long time tend to never do it, and as such, we close those issues. This doesn't mean the idea isn't interesting, just that it's not something the team can commit to. |
@not-an-aardvark this is a PR, not an issue; and the corresponding issue (#7065) is still open. Shouldn't this PR be left open until that issue is closed? |
Good point, I'll reopen this for now. |
lib/rules/no-underscore-dangle.js
Outdated
function checkForTrailingUnderscoreInMethodDefinition(node) { | ||
const identifier = node.key.name; | ||
|
||
if (typeof identifier !== "undefined" && hasTrailingUnderscore(identifier) && enforceInMethodNames) { |
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 feel like the enforceInMethodNames
guard should come first in this conditional so that hasTrailingUnderscore()
isn't called every time.
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 makes sense, I'll change it.
lib/rules/no-underscore-dangle.js
Outdated
const identifier = node.key.name; | ||
const isMethod = node.method; | ||
|
||
if (typeof identifier !== "undefined" && hasTrailingUnderscore(identifier) && enforceInMethodNames && isMethod) { |
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.
Same comment as above.
lib/rules/no-underscore-dangle.js
Outdated
const identifier = node.key.name; | ||
const isMethod = node.method; | ||
|
||
if (typeof identifier !== "undefined" && hasTrailingUnderscore(identifier) && enforceInMethodNames && isMethod) { |
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 the check for isMethod
necessary here? It doesn't look like this ever evaluates to falsey in the tests. Additionally, if we can remove this, I believe checkForTrailingUnderscoreInMethodDefinition
and checkForTrailingUnderscoreInMethodProperty
become the same function and we can just use one function for both MethodDefinition
and 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.
I don't recall the reason (it's been a while since I've implemented this 😅) but I think you're right.
I'll squash the two functions together.
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, wait, I think I remembered why this is different. We don't want to report on any property, but only on method properties. So for instance:
const obj = {
_foo: 'bar', // this is fine
_bar() { } // this will trigger the rule
}
The only discriminant between the two is the method
property on the Property
node.
Thanks for contributing to ESLint! Just a few comments. |
LGTM |
@kaicataldo I've squashed the two functions together, but I've kept the |
@gabro Ah, makes sense, thanks! And appreciate you responding so quickly after the delay on our side. Looks like linting is currently failing - mind taking a look? I'd love to land this! |
LGTM |
@kaicataldo woops, I missed a dot at the end of the reporter message. I also took the opportunity to rebase so to replicate it locally. It should be ok now. |
LGTM |
@kaicataldo the CI seems happy now :) |
@eslint/eslint-team I think this is good to go. Its been here for almost a year now. We should take action on this. |
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.
One last thing, but otherwise this LGTM. Would you mind adding a test for the case you outlined in this comment?
Thanks for contributing!
LGTM |
@kaicataldo done :) |
…t#7065) When enforceInMethodNames is true, the rule checks for dangling underscores in method names too. This includes methods of classes and method properties of objects. The rule is false by default.
LGTM |
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, this LGTM!
🎉 |
What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[x] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
#7065
Please check each item to ensure your pull request is ready:
What changes did you make? (Give an overview)
When
enforceInMethodNames
istrue
, the rule checks for danglingunderscores in method names too. This includes methods of classes
and method properties of objects.
The rule is
false
by default, in order to preserve backward compatibility.Is there anything you'd like reviewers to focus on?
Nothing in particular.