Indent level for fat arrow functions

Tell us about your environment

• ESLint Version: 3.19.0
• Node Version: 6.9.5
• npm Version: 3.10.0

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

Please show your full configuration:

{
    "extends": "standard",
    "plugins": [
        "standard",
        "promise"
    ]
}

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

describe('AuthenticationService', () => {
  describe('login', () => {
    it('should not be able to login with wrong credentials',
       inject([AuthenticationService, MockBackend], () => {
         failCheck(
           () => service.login('admin', 'admin'),
         );
       },
    ));

    it('should be able to login with correct credentials',
       inject([AuthenticationService, SessionService, MockBackend],
              () => {
         successCheck(
           () => service.login('admin', 'admin'),
         );
      }),
    );
  });
});

What did you expect to happen? The successCheck should be correctly indented.

It would be nice if the line break resets the indent to the value of inject + 2 instead of orientating at the indent level of the parameter.

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

  14:10  error  Expected indentation of 16 spaces but found 9  indent
  17:7   error  Expected indentation of 14 spaces but found 6  indent

[not-an-aardvark]

@CSchulz In theory, yes. However, we generally only add options to rules if they meet a set of guidelines, such as being generally applicable to many developers. (We can’t add options for every possible preference, because maintaining all the options would impose a large maintenance burden .) It’s possible that this option meets those criteria, but I’m not sure whether it does.

Could you elaborate on what the flag would do? How would it affect arrow function indentations in general? For example, would it affect arrow functions that are not function arguments?

[not-an-aardvark]

Closing because this is working as intended, but feel free to create a new issue if you’d like to make a proposal for a new option.