Move some rules of tslint-consistent-codestyle to tslint core

[ajafff]

This is about moving some of my custom rules developed in https://github.com/ajafff/tslint-consistent-codestyle to tslint core

@adidahiya suggested that first in #1802
@andy-hanson reminded me in #2037 (comment)

I'd like to get your feedback first which rule you'd like me to contribute:

Rule	Comment	Completed?
no-as-type-assertion	The opposite of your no-angle-bracket-type-assertion. This one is just my own preference. Do you want to provide two conflicting rules? Maybe they could be merged into one rule with a config option.
no-collapsible-if	I'd totally recommend that one for tslint core
no-else-after-return	Like the name suggests, no else after return. Supports nested if and switch statements. I'd rather recommend no-unnecessary-else
no-static-this	Disallow the use of this in static methods
no-unnecessary-else	Basically no-else-after-return with added support for throw, break and continue. Parts of that rule could be used to fix no-switch-case-fallthrough #950, #1033 and #1538
no-var-before-return	tracked by #1802, will try to catch up on that one
object-shorthand-properties-first	Could conflict with object-literal-sort-key, but could be introduced as a new option for that rule	✅
prefer-const-enum	will be PR'ed once I find the time to make it scope aware. Ref #1798
prefer-static-method	is in progress in #2037 right now	✅
prefer-while	Disallows for(;;) and for(;foo===bar;)

This is kind of blocked by #1900 (comment) to avoid being penalized by the performance of SyntaxWalker

Another question is how to handle the utility functions in https://github.com/ajafff/tslint-consistent-codestyle/blob/master/src/utils.ts and https://github.com/ajafff/tslint-consistent-codestyle/blob/master/src/typeguard.ts
Should they all be copied to src/language/utils.ts or do we want to start splitting utils.ts into several files?

[JoshuaKGoldberg]

Re #3442 - should naming-convention be added to this? Are there other blockers? I'd love to have these in core. :)

[ajafff]

Re blockers: Since all utilities are now moved to tsutils the rules are pretty self-contained. They could simply be ported.
There's probably the need to adjust the code style and add the metadata for the docs generator.

naming-convention would need new docs. The existing docs are almost a year old and barely understandable if you don't know the code.

[rafaelss95]

Any news? :)

[aervin]

Anything I can do to help with the porting of these? I'd also love to see these rules in core soon.

[brunolemos]

This was fixed by #3607:

Rule	Comment
object-shorthand-properties-first	Could conflict with object-literal-sort-key, but could be introduced as a new option for that rule

🙌

[adidahiya]

no-as-type-assertion

Sure, I could see this as a single rule which enforces either only as type assertions or only angle bracket type assertions. IIRC the TS team introduced as assertions to avoid conflicts with JSX, and since many projects mix .ts and .tsx files, it is the generally recommended syntax for the community. But I wouldn't mind adding this as a configurable option to a TSLint core rule.

no-collapsible-if

👍

no-static-this

👍

no-unnecessary-else

👍

prefer-const-enum

👍

prefer-while

👍

[rwaskiewicz]

#3750 Addresses prefer-while rule

[VincentLanglet]

@ajafff Any news ?

I would love to have the no-else-return / no-unnecessary-else rule in the tslint core

[ajafff]

@VincentLanglet I'm no longer involved in maintaining TSLint. In fact I don't want to invest any time in contributing to this mess. Therefore I'm closing this issue.

Anyone who is interested in porting the rules can do so. Keep in mind that copied code without substantial changes needs to retain the original license.