Extend whitespace linting functionality

[arhontmw]

Rule Suggestion

Extends the functionality proposed in #1588.
The amendments listed below make whitespace rules more customizable

Is your rule for a general problem or is it specific to your development style?
The proposal introduces changes to whitespace rule and adds several new rules in order to solve the general problem of whitespace linting.

What does your suggested rule do?
My suggestion:

• Get rid of check-type option of whitespace rule - instead use more consistent typedef-whitespace rule (see PR [bugfix][enhancement][rule-change] Get rid of check-type option in whitespace rule #4110)
• Add rule ternary-operator-spacing that checks a presence or absence of whitespace-like symbols before and/or after question and colon tokens in ternary conditional expression (see PR [new rule]: ternary-operator-spacing #4109 )
• Add rule key-spacing that determines whether a space is required before and/or after a colon in a property/destructuring assignment (see PR [new rule] Key spacing rule #4111)
• Get rid of check-branch option of whitespace rule and instead use the new rule space-after-branch (see PR [new rule] Space after branch #4112) that requires or restricts whitespace after branching keywords

List several examples where your rule could be used
The rules suggested are appropriate for the situations when someone's coding style is not supported by the current version of tslint. E.g. the current version does not check the following:

• Space before colon in property/desctructuring assignment
• No space before question token in ternary operator
• No space after branching keywords (for, if, which, ...)

[johnwiseheart]

I think the primary discussion here is whether these things should be integrated into whitespace or not. My feeling is that the whitespace rule deals with almost all (if not all) whitespace issues and we should keep it that way, but I could also see an argument for splitting the rule into multiple. Thoughts @giladgray @suchanlee

[giladgray]

i would prefer to minimize the number of rules by making individual ones smarter. if the whitespace rule can handle everything (without being too unwieldy) then we should do that.

[arhontmw]

So what: we need to revisit the whole whitespace rule in order to implement the proposed amendments?

[arhontmw]

@johnwiseheart @giladgray ?

[johnwiseheart]

I mean, in a way yeah. I wouldn't say we have to revisit the whole thing, just that it makes more sense for them to be added to the whitespace rule than to just be tacked on as separate new rules.

[JoshuaKGoldberg]

Also relevant: discussions in #628 and linked issues.

[JoshuaKGoldberg]

💀 It's time! 💀

TSLint is being deprecated and no longer accepting pull requests for major new changes or features. See #4534. 😱

If you'd like to see this change implemented, you have two choices:

• Recommended: Check if this is available in ESLint + typescript-eslint ✅
• Not Recommended: Fork TSLint locally 🤷‍♂️

👋 It was a pleasure open sourcing with you!

If you believe this message was posted here in error, please comment so we can re-open the issue!

[JoshuaKGoldberg]

🤖 Beep boop! 👉 TSLint is deprecated 👈 (#4534) and you should switch to typescript-eslint! 🤖

🔒 This issue is being locked to prevent further unnecessary discussions. Thank you! 👋