feat: add rule logical-assignment-operators

[DMartens]

Fixes #13689

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[x] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

Fixes #13689

What changes did you make? (Give an overview)

Added the rule according to the proposal
Compared to the proposal the if test condition also checks for !!value and Boolean(value) and the check if the problem is fixable also checks for with blocks.
I used the existing operator-shorthand as a template for the documentation and wording of the messages.

Is there anything you'd like reviewers to focus on?

The most important thing is more fix scenarios. I tried to cover all I could think of (comments, parenthesis, whether it should be autofixed).
Also the logic of "isUndefined" is duplicated as ast-utils only has a "isNullOrUndefined", maybe this should be moved to ast-utils.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: DMartens / name: fnx (e7cb5b1)

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	180155d
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/631874f03d8b9400080c72e4

[nzakas]

Thanks for doing this! I left a few small comments but otherwise looks really good. Would like @mdjermanovic to review before merging.

[mdjermanovic]

Very nice work! I left a few comments about things that should be fixed in the code that I noticed on the first pass.

[DMartens]

Thanks for the reviews. I pushed the suggested fixes / features as separate commits for easier reviewing.
Some notes:

• Currently it is not possible to overwrite undefined and then use the assignment pattern (eg. undefined = undefined || 0)
• I tried different situations but the continuation problem for the if pattern is only encountered when the previous statement ends with a closing parenthesis and the assignment target is parenthesized. So I targeted this specifically but there may be other contexts which could trigger the continuation problem
• I chose to add parenthesis based on the precedence for the logical pattern instead of adding parenthesis when the logical expression is not an expression statement

[mdjermanovic]

@DMartens it seems that #16102 (comment) hasn't been addressed. For example, the following if can be safely autofixed to a.b &&= foo; but the current version provides a suggestion.

/* eslint logical-assignment-operators: ["error", "always", { enforceForIfStatements: true }] */

(a) => {
    if (a.b) a.b = foo;
}

[DMartens]

@mdjermanovic I fixed this locally. But I have two questions regarding when to fix/suggest the fix:

1. In the proposal the canBeFixed is linked which also allows fixing for a.b = a.b || c but according to the proposal this should be a suggestion.
2. I think super and meta properties (eg. import.meta) are also save to fix (eg. import.meta.hot = import.meta.hot || false)

[mdjermanovic]

1. In the proposal the canBeFixed is linked which also allows fixing for a.b = a.b || c but according to the proposal this should be a suggestion.

This is different from operator-assignment because logical assignment operators have short-circuiting behavior. In particular, if a.b is truthy, then a.b ||= c doesn't assign to a.b while a.b = a.b || c does assign to a.b, so they are not equivalent.

2. I think super and meta properties (eg. import.meta) are also save to fix (eg. import.meta.hot = import.meta.hot || false)

I agree, it seems that these cases can be safely autofixed.

[nzakas]

@DMartens are you still working on this?

[DMartens]

Thanks for the thorough review. All the suggestions should be implemented as separate commits.

[mdjermanovic]

A few small suggestions, then LGTM.

[mdjermanovic]

LGTM, thanks! Great work.

I'll leave this open for a few days in case someone else wants to review it before merging.

[snitin315]

Great work on this. Thank you for contributing ⭐

[nzakas]

LGTM

[amitbeck]

This rule is a great addition, but it's a shame that it didn't end up being named logical-operator-assignment to align with operator-assignment, as suggested in #13689 (comment).

[mdjermanovic]

This rule is a great addition, but it's a shame that it didn't end up being named logical-operator-assignment to align with operator-assignment, as suggested in #13689 (comment).

@amitbeck thanks for the input! We considered your suggestion but decided on the logical-assignment-operators rule name because "logical assignment operators" is the term used in the proposal and the specification.

[amitbeck]

This rule is a great addition, but it's a shame that it didn't end up being named logical-operator-assignment to align with operator-assignment, as suggested in #13689 (comment).

@amitbeck thanks for the input! We considered your suggestion but decided on the logical-assignment-operators rule name because "logical assignment operators" is the term used in the proposal and the specification.

@mdjermanovic Good to know, thanks for the clarification. It still bothers me that the other rule's name is misaligned with this one but nothing can truly be perfect 🥲

[nzakas]

@DMartens we'd like to pay you for this contribution, but I couldn't find an email address to contact you at. Can you please email contact (at) eslint (dot) org so we can give you instructions? Thanks!