Update: no-self-assign should detect member expression with this #12279
Conversation
|
Hi @saberduck, thanks for the PR! Seems logical to report this as it's a self-assignment of a property. Though, this needs to be evaluated for a semver-minor upgrade because the change produces more warnings by default. |
|
Wondering if this can be handled as a bug fix, as I believe there is no fundamental difference between On the other hand, it could break some builds where this line is used to trigger some setter's side effects. |
|
@mdjermanovic can I help somehow to move this PR forward? Should I change the description to bugfix? |
|
I think this could be considered a bug. (Reproduction demo) Based on that, I will mark as accepted/bug. NOTE: The current commit message is correct, as we want bug fixes that will report more errors to be marked with the "Update:" prefix and included in a minor release. |
|
Also, please accept my apologies for letting this sit for so long. |
|
Looks good to me. Thanks for contributing! |
|
LGTM, just one note. |
a773a61
to
3fd7758
|
LGTM, thanks! |
|
Thanks for contributing! |
b962775
into
eslint:master
|
Thanks @saberduck for contributing to ESLint! |
What is the purpose of this pull request? (put an "X" next to item)
[x] Changes an existing rule
What rule do you want to change?
no-self-assignDoes this change cause the rule to produce more or fewer warnings?
more
How will the change be implemented? (New option, new default behavior, etc.)?
updates default behavior
Please provide some example code that this change will affect:
What does the rule currently do for this code?
doesn't raise an issue
What will the rule do after it's changed?
raise an issue
What changes did you make? (Give an overview)
I updated
no-self-assignrule to support member expression usingthisidentifier.Is there anything you'd like reviewers to focus on?