Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

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

Closed
ajafff opened this issue Jan 14, 2017 · 9 comments
Closed

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

ajafff opened this issue Jan 14, 2017 · 9 comments

Comments

@ajafff
Copy link
Contributor

ajafff commented Jan 14, 2017

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
Copy link
Contributor

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

@ajafff
Copy link
Contributor Author

ajafff commented Nov 6, 2017

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
Copy link
Contributor

Any news? :)

@aervin
Copy link
Contributor

aervin commented Dec 23, 2017

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

@brunolemos
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

#3750 Addresses prefer-while rule

@VincentLanglet
Copy link
Contributor

@ajafff Any news ?

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

@ajafff
Copy link
Contributor Author

ajafff commented Dec 29, 2018

@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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants