feat: treat unknown nodes as having the lowest precedence

[bradzacher]

Prerequisites checklist

• I have read the contributing guidelines.

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

[x] Changes an existing rule (template)

#17173

What changes did you make? (Give an overview)

This PR changes the getPrecedence util so that it assumes all unknown nodes have the lowest possible precedence.
This means that lint rules will assume the unknown nodes require parentheses when evaluating or creating fixes.

I have included some test cases for TS code to validate the behaviour works as intended.

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

[mdjermanovic]

I think we should keep the current behavior (assuming that unknown nodes have higher precedence and thus require parentheses around known nodes) in the following cases:

eslint/lib/rules/logical-assignment-operators.js

Lines 373 to 374 in f82e56e

	const requiresOuterParenthesis = logical.parent.type !== "ExpressionStatement" &&
	(astUtils.getPrecedence({ type: "AssignmentExpression" }) < astUtils.getPrecedence(logical.parent));

eslint/lib/rules/prefer-exponentiation-operator.js

Line 62 in f82e56e

astUtils.getPrecedence(parent) >= PRECEDENCE_OF_EXPONENTIATION_EXPR &&

[bradzacher]

I think we should keep the current behavior (assuming that unknown nodes have higher precedence and thus require parentheses around known nodes) in the following cases

For the logical-assignment-operators case....

I looked at this case deeply and I realised that it is impossible to hit for unknown nodes!

In order for you to hit this case you need code like this:

a.b.c || (a.b.c = d as number)

But syntactically we already know that d as number doesn't need parentheses! If it needed to be wrapped then the expression wouldn't have ever been parsed as an assignment expression and thus the rule wouldn't have fired on the code.

EG annotated the rule will only match on this case if it's:

a.b.c || (a.b.c = d as number)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LogicalExpression
          ^^^^^^^^^^^^^^^^^^^  AssignmentExpression
                  ^^^^^^^^^^^  unknown node

If intstead it was parsed as

a.b.c || (a.b.c = d as number)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LogicalExpression
          ^^^^^^^^^^^^^^^^^^^  unknown node
          ^^^^^^^^^            AssignmentExpression

Then the rule wouldn't ever fire because the selector specifically looks for right.type = AssignmentExpression.

Which is why I didn't touch the logic here - because it's already working correctly!

I.e. for a.b.c || (a.b.c = d as number) the suggestion is a.b.c ||= d as number
and for a.b.c || (a.b.c = (d as number)) the suggestion is a.b.c ||= (d as number)
Both of which are syntactically correct.

---

For the prefer-exponentiation-operator case - yup this was an unhandled case - fixed.

[mdjermanovic]

In order for you to hit this case you need code like this:

a.b.c || (a.b.c = d as number)

The code I linked checks logical expression's parent to determine whether the resulting assignment expression (||=) should be parenthesized in relation to that node. For example, let's say there's an unknown expression type SomethingExpression with operator something that happens to have precedence lower than || but higher than ||=.

a.b.c || (a.b.c = d) something number
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SomethingExpression

Fix without parentheses would be wrong:

a.b.c ||= d something number
          ^^^^^^^^^^^^^^^^^^
          SomethingExpression 

The correct fix should be:

(a.b.c ||= d) something number
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SomethingExpression 

[bradzacher]

I see what you're saying - I just don't have an example of any code where the code is parsed like that.
The only examples I have parse as

a.b.c || (a.b.c = d) as number
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   LogicalExpression
         ^^^^^^^^^^^^^^^^^^^^^   unknown node

Which means to get this code to parse in the order you want you need parentheses

(a.b.c || (a.b.c = d)) as number
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unknown node
^^^^^^^^^^^^^^^^^^^^^^           LogicalExpression

Which then degenerates to a plain old, non special syntax case and is fixed correctly to

(a.b.c ||= d) as number

I reviewed the precedence of all TS syntax and all of it has a higher precedence than both assignments and logicals.
the only syntax with lower precedence than logicals are: spreads, yield, ternaries, assignments
the only syntax with lower precedence than assignments are: spreads, yield

So the only way I could create a test case for your example is to fabricate a hypothetical AST.
Happy to change the code (latest commit does) - I just don't have a test for it.

[mdjermanovic]

So the only way I could create a test case for your example is to fabricate a hypothetical AST.
Happy to change the code (latest commit does) - I just don't have a test for it.

In that case, there's no need for a test case for this example. The code change LGTM.

[mdjermanovic]

Just a small change to sync code with ast in one example, then LGTM.

[nzakas]

LGTM. Just waiting for @mdjermanovic to verify his changes.

[mdjermanovic]

LGTM, thanks!