Closed Zamiell closed 9 months ago
Hi! I don't really want to convince people to use TSSLint, I created this just to solve my own needs: I only need a few simple rules and prefer to use a lighter IDE Extension / CLI.
they should at least be pointed in the general direction of
typescript-eslint
typescript-eslint
is not the problem!
In fact, we can implement a method similar to parseESLintRules
in TSSLint to use typescript-eslint
rules, and it won't cause the issues mentioned in the readme. I just didn't have the motivation to do so because I have already solved what I needed so far.
But same, I don't want to try to convince people, so I don't plan to compare more in the readme, thanks!
I think the README should have a discussion regarding why someone would want to use this over
typescript-eslint
. The reasons are implicitly given (speed?), buttypescript-eslint
is not called out directly. I think that for people wanting to create type-aware rules, they should at least be pointed in the general direction oftypescript-eslint
, since it is the industry standard and has a huge ecosystem. Maybe we should add a comparison table that shows the pros and cons?