Deprecate unnecessary rules

[ChrisMBarr]

Based on discussion in #164, there seem to be several rules in this project that duplicate existing functionality.

• use-isnan ➡️ now covered by the TSLint rule use-isnan, but the docs currently state this, yet the rule is still distributed anyway. Why?
• valid-typeof ➡️ now covered by the TSLint rule typeof-compare
• no-extra-semi ➡️ not entirely sure, but I think the TSLint rule semicolon might cover this now.

[jmlopez-rod]

for the use-is-nan rule I changed the docs since tslint won't let us use the one provided here and I did not want to delete the rule just yet. It didn't make sense to let users believe that they were using the rule from this project.

valid-typeof is probably also safe to deprecate.

I would keep no-extra-semi since the implementation is more simple that the one provided by tslint.

https://github.com/buzinas/tslint-eslint-rules/blob/master/src/rules/noExtraSemiRule.ts

https://github.com/palantir/tslint/blob/master/src/rules/semicolonRule.ts

Also, in some cases I think we should consider keeping a rule if it has a different implementation. We should try to see which one is more efficient and document the pros and cons of using the version provided here. Anyway, let's keep this issue open and see if we find other rules that we might consider deprecating for the next major version.

[ChrisMBarr]

So, TSlint 5 has been released, and this project has released version 4. Both major version number updates and the use-isnan rule is still being distributed, yet it's still not usable since the rule in base tslint will always override this. Is there a reason to keep distributing duplicate code that can never be consumed?

[WiseBird]

Also no-sparse-arrays is natively supported by TSlint 5.

[roman-petrov]

Also, no-irregular-whitespace is introduced and natively supported by TSLint 5.2.0

[ikokostya]

no-duplicate-switch-case rule is supported in tslint 5.8.0.

[karfau]

Also, in some cases I think we should consider keeping a rule if it has a different implementation. We should try to see which one is more efficient and document the pros and cons of using the version provided here. This would be so awesome. It is really difficult to be able to distinguish which one to use/keep from looking at the code. Maybe the tests could be a good source for comparison...

We created a configuration, that uses both https://github.com/Microsoft/tslint-microsoft-contrib and tslint-eslint-rules and there are the following "name clashes" (in our case tslint-eslint-rules win because they are extended first):

• no-constant-condition
• no-control-regex
• no-duplicate-case
• no-invalid-regexp
• no-regex-spaces

it would be nice to be able to reason about which one to use.