✅ Deploy Preview for docs-eslint canceled.

Thanks for the submission. Can you please update the description with the same fields we have in our bug report template? Thanks.

Thanks for the submission. Can you please update the description with the same fields we have in our bug report template? Thanks.

Thanks for mentioning the template i have updated the pr description to include the templete please review it

I believe this fix addresses #20410, but it’s assigned to someone else.

And please double-check the PR template. It seems a malformed code block is still breaking the template.

I believe this fix addresses #20410, but it’s assigned to someone else.

And please double-check the PR template. It seems a malformed code block is still breaking the template.

To clarify — PR #20701 addresses SequenceExpression support in the update clause, not the statically-false condition case described in the issue.

I believe this fix addresses #20410, but it’s assigned to someone else.

And please double-check the PR template. It seems a malformed code block is still breaking the template.

This pr is not related to #20410

This PR addresses a completely different scenario where the update clause is a SequenceExpression. Currently, we handle:

1. UpdateExpression – i++, i--
2. AssignmentExpression – i += 1, i -= 1

Please create a separate issue to track this case - SequenceExpression. Based on the team’s decision, you may proceed with the implementation.

There can be multiple cases
case 1: Mixed UpdateExpression + AssignmentExpression

case 2: Three values separated by comma

case 3: for(var i = 10; i < 20; i--, i++) {} - different directions

Scenario 1:
i-- → i = i - 1 and i++ → i = i + 1 the net effect No change to i

Condition: i < 20 → always true result in infinite loop.

Scenario 2:
i-- → i = i - 1 and i = i + 2 → increases i by 2 the effect i = i + 1

Condition: i < 20 → runs from 10 to 19 and stops when i becomes 20 Normal loop (not infinite)

Ideally if the counter appears more than once in the sequence, treat direction as unknown and we should skip i guess.

Did the changes as described in the issue

Lines 164–182 in lib/rules/for-direction.js:

if (update.type === "SequenceExpression") {
    const counterExpressions = update.expressions.filter(
        expr => getDirectionFromExpression(expr, counter) !== 0,
    );

    if (
        counterExpressions.length === 1 &&
        getDirectionFromExpression(counterExpressions[0], counter) === wrongDirection
    ) {
        report(node);
    }
}

This uses .filter() to collect all expressions that modify the counter, then only reports if exactly one expression modifies the counter and it moves in the wrong direction. If the counter appears more than once (e.g., i--, i++ or i--, i += 2), counterExpressions.length will be > 1, so the rule treats the direction as unknown and skips — exactly as proposed in #20726.

The corresponding test cases are already in place:

Valid (counter modified multiple times → direction unknown, skip):

"for(var i = 10; i < 20; (i--, i++)){}"
"for(var i = 10; i < 20; (i--, i += 2)){}"
"for(var i = 0; i < 10; (i++, i--)){}"
"for(var i = 0; i < 10; (i-=1, i+=2)){}"

Invalid (exactly one expression moves counter in wrong direction):

"for(var i = 0; i < 10; (i--, j++)){}"
"for(var i = 10; i > 0; (i++, j--)){}"
"for(var i = 0; i < 10; (i-=1, j++)){}"
// ...and more

Let me know if any additional test cases or changes are needed!

Before procceding with fixing all found issue i want a member confirmation to proceed

I think this copilot review was trigger by me by mistake

In the SequenceExpression path, counterExpressions filters on getDirectionFromExpression(...) !== 0. For AssignmentExpression on the counter where the RHS isn't statically known (e.g. i += STEP_SIZE), getAssignmentDirection returns 0, so that expression is excluded even though it does modify the counter. This can lead to false reports when the sequence contains one known-direction update plus another counter update with unknown direction (overall direction should be treated as unknown and skipped). Consider separating (1) “does this expression modify the counter?” from (2) “what is its direction?”, and treat any additional/unknown counter modifications (including nested SequenceExpressions) as making the direction indeterminate.

Applied this change as requested by @mdjermanovic.

I've updated the implementation to introduce a getMutatingExpressions helper that safely extracts all expressions modifying the counter. This successfully separates the check for "does it modify the counter?" from "what is its direction?". It now perfectly handles indeterminate assignments (like i += STEP_SIZE) as well as flattened nested SequenceExpressions.

I also added tests to verify these edge cases are properly skipped without throwing false positive reports.