New rule proposal: prefer-ternary

[jmoore914]

Please describe what the rule should do:
Replace an if/then/else statement with a single-line consequence and alternate with a ternary expression.

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

[ ] Warns about a potential error (problem)
[X ] Suggests an alternate way of doing something (suggestion)
[ ] Enforces code style (layout)
[ ] Other (please specify:)

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

let a =''
if(conditional){
  a=3
}
else{
  a=4
}

if(conditional){
  return 3
}
else{
  return 4
}

Why should this rule be included in ESLint (instead of a plugin)?
Using an if/then/else statement typically results in more lines of code than a single lined ternary expression, which leads to an unnecessarily larger codebase that is more difficult to maintain.

Additionally, as in the first example, using an if/then/else statement can result in defining variables using let or var solely to be reassigned within the blocks. This leads to varaibles being unnecessarily mutable and prevents prefer-const from flagging the variable.

Are you willing to submit a pull request to implement this rule?
Yes

[ljharb]

How often are if/else blocks reducible to a single expression such that this rule will provide value?

[platinumazure]

Hi @jmoore914, thanks for the issue.

To expand on @ljharb's point, it seems that the rule would need to detect not only that the consequent and alternate blocks have one statement, but that they have the same basic type and form. It might be good to provide some more examples with other types of statements that could be reducible in the manner you described.

[jmoore914]

I can't comment on exactly how often this pattern is used but I know I have used it in the past and seen it in other codebases.

@platinumazure yes, it would detect whether the bodies are one line and the same type (ExpressionStatement, ReturnStatement, or CallExpression) and there would be options for which type of expression this would flag (e.g. flag ReturnStatements but not CallExpressions).
I've already written the rule for my own use, but I thought others might find it useful. Would you like me to link the github or would you prefer just more examples?

[kaicataldo]

Would you like me to link the github or would you prefer just more examples?

Both would be helpful :)

[jmoore914]

Here's the repo: https://github.com/jmoore914/eslint-plugin-jmoore914/tree/prefer-ternary

I can try to come up with some more examples sometime soon!

[jmoore914]

Here's some examples that are actually from the eslint source code:

if (Array.isArray(sourceDef)) {
     target[key] = [...sourceDef];
} else {
     target[key] = [sourceDef];
}

let messageType;

if (message.fatal || message.severity === 2) {
     messageType = chalk.red("error");
} else {
     messageType = chalk.yellow("warning");
}

if (isLexDef) {
     expected = true;
} else {
     expected = leadingComments.length > 0;
}

if (switchNode.cases.length > 0 && options.SwitchCase === 0) {
     caseIndent = switchIndent;
} else {
     caseIndent = switchIndent + (indentSize * options.SwitchCase);
}

if (iterator.valid) {
     this._rbTree = iterator.update(value);
} else {
     this._rbTree = this._rbTree.insert(key, value);
}

if (node.arguments.length) {
     openingParen = sourceCode.getFirstTokenBetween(node.callee, node.arguments[0], astUtils.isOpeningParenToken);
} else {
     openingParen = sourceCode.getLastToken(node, 1);
}

if (switchNode.cases.length > 0 && options.SwitchCase === 0) {
     caseIndent = switchIndent;
} else {
     caseIndent = switchIndent + (indentSize * options.SwitchCase);
}

There are a ton more but does that give you an idea of what this rule would be looking at?

[kaicataldo]

Thanks for sharing these. I personally don't think this reaches the high bar we have to set for core rules now that we have so many of them.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[seansfkelley]

Hey @jmoore914 I would be interested in this rule; did you end up publishing it somewhere?

[jmoore914]

Hey @jmoore914 I would be interested in this rule; did you end up publishing it somewhere?

It hasn't quite been finished yet but take a look here: sindresorhus/eslint-plugin-unicorn#514