New Rule: continuation-linebreak

Please describe what the rule should do:

This rule sets a strict style guideline for multiline arrow functions and expression statements; it can be customized to require or disallow a line break after => or =.

Ending a line with => or = causes a readability issue by ambiguating what the assignment or function body contains. Moving the function body or second line of assignment inline beside => or = should fix this issue.

This rule can be auto-fixed by bumping the second line to be inline beside => or =. This can also be fixed by wrapping the multiline body in parentheses (see "multilineParens": true option).

Future Rule Extension: Add a guideline for object’s that have keys and values multiple lines i.e. that end a line with a :.

Potential Options:

Array options:

• ["always", { "multilineParens": false }] - (default) require that a an assignment or arrow function must always have a line break i.e. always break on = or =>. This option takes an additional object parameter with the property multilineParens. Setting "multilineParens": true would require that multiline statements be wrapped in parentheses.

• ["never", { "multilineParens": false }] - requires that there should never be a linebreak in the middle of a continuation, i.e. never break on a = or =>. This takes an additional object parameter with the property multilineParens. Setting "multilineParens": true would require that multiline statements be wrapped in parentheses.

• ["conditional", { "multilineParens": false, "maxLength": 80 }] - requires that statements shorter than the maxLength should be inline and statements that are longer than the maxLength need to be split up on multiple lines. This option takes an additional object parameter with the properties multilineParens and maxLength. "multilineParens": true would require wrapping rule violations in parentheses if they exceed the maxLength and inline the continuation when the line length is below the maxLength. The maxLength property can have a default value of 80.

What category of rule is this? (place an “X” next to just one item)

• Enforces code style
• Warns about a potential error
• Suggests an alternate way of doing something
• Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

Option: "always", { "multilineParens": false }

These options are compatible with Prettier’s auto formatting

// bad
x => "foo";

// bad
(x) => {
  return foo;
}

// bad
const foo = bar
  ? 1
  : 2;

// bad
const foo = "bar";

// good
x =>
  "foo";

// good
(x) =>
  {
    return "foo";
  }

// good
const foo =
  "bar";

// good
const foo =
  bar
  ? 1
  : 2;

Option: "always", { "multilineParens": true }

// bad
x => "foo";

// good
x => (
  "foo"
);

Option: "never", { "multilineParens": false }

// bad
x =>
  "foo";

// bad
(x) =>
  {
    return "foo";
  }

// bad
const foo =
  "bar";

// bad
const foo =
  bar
  ? 1
  : 2;

// good
x => "foo";

// good
(x) => {
  return foo;
}

// good
const foo = bar
  ? 1
  : 2;

// good
const foo = "bar";

Option: "never", { "multilineParens": true }

// bad
x =>
  "foo";

// good
x => (
  "foo"
);

Option: "conditional", { "multilineParens": false, "maxLength": 20 }

default maxLength can be 80, I’m using 20 for demonstrative purposes

// bad
x => "longLongName";

// bad
x =>
  "foo";

// bad
const foo =
  "bar";

// bad
const foo = bar ? 1 : "longLongName";

// good
x =>
  "longLongName";

// good
x => "foo";

// good
const foo = "bar";

// good
const foo = bar
  ? 1
  : "longLongName";

Option: "conditional", { "multilineParens": true, "maxLength": 20 }

default maxLength can be 80, I’m using 20 for demonstrative purposes

// bad
x => "longLongName";

// good
x => (
  "longLongName";
);

Why should this rule be included in ESLint (instead of a plugin)?

This rule is very wide-reaching and can improve overall code style.

[ilyavolodin]

In general I’m 👍 for the described scenarios (btw, thanks a lot for providing such clear rule request, it really helps). I’m just not sure about conflating arrows and equal operator into the same rule. I understand the goal, just not sure it makes sense when you are just looking through the list of rules. Would operator-linebreak: ['error', { "overrides": { "=": "none" } }] cover your equal operator requirements? Or do you want the expression to be always wrapped into parentheses? If it covers what you want, then I would suggest creating a separate rule arrow-linebreak without conditional option as described above (conditional can always be added later if needed).

[ljharb]

@not-an-aardvark @platinumazure it seems like the two paths forward are either:

1. this rule, without the “conditional” option
2. add => support to non-block-statement-body-position and = support to operator-linebreak

Are one of those palatable?