Add prefer-conditional-expression rule

[andy-hanson]

PR checklist

• Addresses an existing issue: #0000
• New feature, bugfix, or enhancement
  • Includes tests
• Documentation update

Overview of change:

Added the prefer-conditional rule, which warns on let x; if (so) { x = 1; } else { x = 2; }.
Not sure if this should do anything about if (so) { return 1; } else { return 2; }. Thoughts?

CHANGELOG.md entry:

[new-rule] prefer-conditional

[adidahiya]

a better name would be prefer-ternary-declaration

[adidahiya]

what happens if there is complex logic in these branches? I would prefer to use this more verbose pattern over a ternary if switching to a ternary meant a very long multiline statement.

[andy-hanson]

The rule needs x = <<code>> exactly, it doesn't just search to see if it appears somewhere. So normally that would filter out complex logic.
Maybe you were thinking of something like this?

let x: number[];
if (so) {
	x = [1,2,3].map(n => {
		switch (n) {
			... lots of code ...
		}
	});
} else {
	x = [];
}

Maybe the rule could only activate if the expression takes up a single line.

[adidahiya]

Yeah, that's a good example. In that case I personally would prefer to keep the if / else blocks; I generally only want to use ternarys when each RHS expression is a single line. If this is going to be a core rule, I think it should be more conservative than it is now -- can you make that change?

[adidahiya]

can you please change the rule name? I think simply "conditional" is too vague because if-else statements are often described as conditionals as well. For example, no-conditional-assignment applies to the conditional expression as part of an if or else statement.

I would be happy with prefer-conditional-operator or prefer-ternary-expression

[andy-hanson]

How about prefer-conditional-expression? if and ? ... : are both conditionals, but ? ... : is an expression and if is a statement.

[adidahiya]

Ok, works. The ESTree spec calls it a conditional expression 👍

[lambda-fairy]

Is this rule documented anywhere? I don't see it in the rules list.

[mwld]

Thanks for new awesome rules with the 5.3.0 release! As @lfairy said it would be great to have the new rules listed in the docs with the release.
Even the release note is currently linking to non-existent rule URLs:

• https://palantir.github.io/tslint/rules/prefer-object-spread/
• https://palantir.github.io/tslint/rules/prefer-conditional-expression/

I also recognized that most of the mentioned [new-rule-option]s there are not yet documented on their doc pages. E.g.:

• https://palantir.github.io/tslint/rules/indent/
• https://palantir.github.io/tslint/rules/object-literal-sort-keys/
• https://palantir.github.io/tslint/rules/quotemark/

Shouldn't it be mandatory to update the docs with rule changes?

[ajafff]

The docs are located in a different branch that needs to be updated when releasing a new version. Seems like this was forgotten? @nchen63 @adidahiya

[adidahiya]

yep, thanks for the heads up, looks like we missed updating the docs for 5.3. we'll update them today!