no-cond-assign analyzes too deep into conditionals

What version are you using?

3.2.2

What did you do?

const arr = [1, 2, 3];

if (arr.some(val => {
  let b = true;
  if (val === 2) {
    b = false;
  }
  return b;
})) console.log('returned true');

What happened?

With this eslintrc:

module.exports = {
    "env": {
        "browser": true,
        "es6": true
    },
    "extends": "eslint:recommended",
    "rules": {
      "no-console": 0,
      "no-cond-assign": [2, 'always']
    }
};

It signaled:

Unexpected assignment within an 'if' statement  no-cond-assign

What did you expect to happen?

It should have ceased to analyze once in the callback of Array.prototype.some and should not care at all about any assignments within. The purpose of the rule is to avoid mistakenly doing an assignment instead of a comparison within a conditional, not to prevent assignments at all.

[Satyam]

@pmcelhaney That rule is exactly the one that the airbnb config has set: https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb-base/rules/errors.js#L7

The code doSomething(foo = 5) whether inside a conditional or not, should produce an error, but not under this rule. Just like a programmer might have mistakenly used an assignment instead of a double or triple equal, the guy writing the above code might have confused the new ES6 default parameter value feature, which is valid for a function declaration but not function invocation.

[platinumazure]

Apologies @nzakas, I hadn’t had time to verify until just now.

Here’s a snippet that repros in the demo:

/* eslint no-cond-assign: ["error", "always"] */
if (arr.some(function (item) { item = 5; })) {
    doSomething();
}

As discussed earlier in the issue, there is a separate issue (parentheses being too zealously considered) that prevents this from showing up as a bug with the default “except-parens” configuration. But I believe we can accept this bug, unless you disagree.