eslint-plugin-typescript vs tslint vs prettier

[guaizi149]

i use eslint , prettier and husty to format and check code. But now i want to use typescript, so there are two questions:

1. eslint-plugin-typescript vs prettier.
   'member-delimiter-style', 'indent', 'type-annotation-spacing' rules may conflict with the prettier, whether it can only let the prettier do the formatting work and eslint-plugin-typescript do the grammatical check. Or the default setting of those rule does not conflict with the prettier.

2. plan1: eslint + eslint-plugin-typescript VS plan2: eslint + tslint?
   plan1 works perfectly. But I wonder if there are some typescript rules that can't be checked.
   plan2 need to maintain two configurations, eslint and tslint will have some rules repeated, and it is said that tslint quality is not that high.
   what plan do you prefer and why?

[bradzacher]

I can type out a longer response tomorrow morning, but a quick answer is to use prettier-eslint.
It runs prettier, then runs your eslint fixers.
It's amazing (and supports typescript).

[j-f1]

Alternatively, you can disable any formatting-related rules in ESLint.

[guaizi149]

can't imagine you haven't slept yet.
Here is my thought：
I just want the prettier to be responsible for formatting, so I disable eslint and tslint rules about code formatting, and this can be done via eslint-config-prettier and tslint-config-prettier.
I use Prettier with a pre-commit toolhusky :

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "src/**/*.{jsx,tsx,ts,js,json,css}": [
      "prettier --write",
      "eslint --fix",
      "git add"
    ]
  },

so although prettier-eslint is a great tool, but not what I need.

Let's talk about the two plans above.

plan2: eslint + tslint

1. I have to maintain two configurations. eslintrc.js and tslint.json
2. Eslint and tslint have some repetitive rules. If I want to change these repeated rules, I have to change two configurations. I only want tslint to check typescript rules, not to check js rules.

plan1: eslint + eslint-plugin-typescript:

it works perfectly. Compared with tslint (I only care about TypeScript-specific rules in tslint), The following rules are missing:

• ban-ts-ignore
• no-import-side-effect
• no-magic-numbers
• no-parameter-reassignment
• no-unnecessary-type-assertion
• no-var-requires
• only-arrow-functions
• prefer-for-of
• promise-function-async
• typedef
• unified-signatures

I want to know what the above rules can't be added, which ones you don't think are necessary to add, and which ones will be added later.

Because there is already a project that doesn't use typescript, which uses eslint, so I don't plan to use tslint + tslint-eslint-rules for the time being.

Thank you very much for taking the time to answer my question.

[armano2]

@langlong149 i started adding rules witch require type information, but they have to wait till eslint/typescript-eslint-parser#568 is going to be merged

some of rules listed by you are goign to be present in v1.0.0 like: no-var-requires

[j-f1]

@langlong149 You can also check out our roadmap, which includes every built-in TSLint rule and its equivalent in the ESLint ecosystem, if one is available.

[bradzacher]

So ultimately it depends on what you want your code to look like.
Prettier is a great start, but it having few options means that you mightn't like some of its styles.

Which is where eslint comes in - the formatting with eslint has more configurability because there are many rules, and each rule has its own options.

This is where prettier-eslint[-cli] comes in - you can use prettier as the basis for your formatting for some solid defaults, and then use eslint rules to tweak the style.

If instead you like everything that prettier provides, then it makes sense to disable the "formatting" class of eslint rules, and using eslint-plugin-prettier is a good option to make sure you get warnings in your editor of formatting problems.

---

In terms of linting - there is generally little need to use both tslint and eslint. Some people like to have it, but as you have mentioned you have to sync and maintain two configs. As @j-f1 mentioned, we're working hard to reach feature parity, and our roadmap will help show you how you can fill the gaps.

Whilst I like tslint - they do some amazing work and inspire us to do more; I personally prefer eslint. Having access to the huge ecosystem of plugins for your code is invaluable.
I mean, there's no reason you can't use both, and disable all of the eslint rules that are supported by tslint, giving you a "best of both worlds" setup. Just means you have to integrate two tools into your pipeline.

[j-f1]

(currently working on adding tslint-microsoft-contrib rules to the roadmap)

[aboyton]

Adding rules from tslint-microsoft-contrib would be great. The other big set of TSLint rules commonly used that I'm aware of is @mgechev's codelyzer for Angular.

The other TSLint rules that I personally use (other than the 9 we've written internally) are @cartant's rxjs-tslint-rules and @jonaskello's tslint-immutable. I'm guessing either of these could port their rules over themselves if they saw the benefits of doing so.

[j-f1]

#251

[guaizi149]

@bradzacher @j-f1 @armano2 Thank you very much for your answers. I already decided to use plan 1 and very grateful for your amazing efforts. Looking forward to the 1.0 version！

[bradzacher]

@aboyton We haven't talked about it at a maintainer level - but just at a quick glance, my gut says that I don't think we'd go into implementing codelyzer rules.

The rules look very much angular-centric, and I think this plugin would be best as a framework/library-agnostic plugin. (similarly for rxjs-tslint-rules).

tslint-immutable is an interesting package. it's library agnostic and exists to implement a set of best practices for typescript, so it could potentially be a candidate to include in here in future.

[aboyton]

I wasn't suggesting everything should be put into this repo, more pointing out a few other sets of rules that use TSLint and suggesting that these projects might want to consider having an ESLint version if this really starts taking off :)