eslint: New MemberExpression functionality in indent rule is a breaking builds

What version of ESLint are you using?

3.2.0

What parser (default, Babel-ESLint, etc.) are you using?

default

Please show your full configuration:

indent: 2

What did you do? Please include the actual source code causing the issue.

This throws an error:

var foo = bar.baz()
            .bip()
            .boop();

What did you expect to happen?

I expected the indentation to be counted from bar and not var. Or at least to be able to turn off indentation checking for MemberExpressions. So I expected no error.

What actually happened? Please include the actual, raw output from ESLint.

error Expected indentation of 2 space characters but found 12

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 4
Comments: 28 (27 by maintainers)

Commits related to this issue

Fix: ignore MemberExpression in VariableDeclarators (fixes #6795) Chained properties on objects will typically not be indented as the rule expects in variable declarations. For now, ignore variable d... — committed to Trott/eslint by Trott 8 years ago
Fix: ignore MemberExpression in VariableDeclarators (fixes #6795) Chained properties on objects will typically not be indented as the rule expects in variable declarations. For now, ignore variable d... — committed to Trott/eslint by Trott 8 years ago
Fix: ignore MemberExpression in VariableDeclarators (fixes #6795) Chained properties on objects will typically not be indented as the rule expects in variable declarations. For now, ignore variable d... — committed to Trott/eslint by Trott 8 years ago
Docs: clarify minor releases and suggest using `~` to version (fefs #6795) — committed to eslint/eslint by hzoo 8 years ago
Docs: suggest using `~` to version (refs #6795) — committed to eslint/eslint by hzoo 8 years ago
Fix: ignore MemberExpression in VariableDeclarators (fixes #6795) Chained properties on objects will typically not be indented as the rule expects in variable declarations. For now, ignore variable d... — committed to Trott/eslint by Trott 8 years ago
Fix: ignore MemberExpression in VariableDeclarators (fixes #6795) Chained properties on objects will typically not be indented as the rule expects in variable declarations. For now, ignore variable d... — committed to eslint/eslint by Trott 8 years ago
Docs: clarify minor releases and suggest using `~ to version (#6804) * Docs: suggest using `~` to version (refs #6795) * fixes — committed to eslint/eslint by hzoo 8 years ago

Most upvoted comments

Maybe adding an alerting system would be beneficial for ESLint. It looks like Greenkeeper immediately caused failures on ~100 repos (including our own) after the last ESLint version was pushed, it would be simple to create a script that scrapes that a few minutes after publishing. If a non-major version causes an abnormal amount of Greenkeeper “breaking” PRs, that is probably a pretty good indicator that something is wrong.

connor4312 on Jul 30, 2016

@ljharb yes, exactly.

nzakas on Aug 1, 2016

Oops, forgot to mention, I think #6798 is along the lines of what we probably should have done initially. I’m not sure of #6796 without getting a better understanding of the original intent.

nzakas on Jul 30, 2016

I think one concern with the “indent” rule particularly is that because each of the suboptions accepts an integer, there’s no way to disable that category of checking.

I think if that was possible - by passing null, or -1, or “off”, or something - then it wouldn’t be so disruptive if a minor version added a new category type.

ljharb on Jul 30, 2016

According to our semver policy this is not a breaking change -

Minor release (might break your lint build) A bug fix in a rule that results in ESLint reporting more errors.

So these changes are completely justified since they were released in minor.

If we not provide an option for this and make your preference by default, then another user might pop up with the complete opposite request saying that this -

var foo = bar.baz()
    .bip()
    .boop();

Is now showing errors.

Having said that, if this change is as invasive as you said it is, then, in my eyes, we could consider following approach - revert that change, provide a specific option for MemberExpressions without default and release it in another minor while considering setting default for major release.

In any case this does not look as a bug, strictly speaking

markelog on Jul 29, 2016