To be honest, I was really happy with TSLint. The amount of configuration and scaffolding around ESLint is a big turnoff from me compared to how easy it was to get TSLint going.

It's useful if you have a custom eslint ruleset you want to apply to your ts projects. Some of those rules aren't always available on tslint.

Mostly helpful to keep a shared ruleset across projects.

The larger the pool of engineers on a project (or the larger a team size) the more important consistent formatting becomes. It may not be relevant for individual projects (though I'd disagree with that as well), but it makes maintenance of projects under larger teams, including distributed teams, a heck of a lot easier.

To us, the biggest value is auto-refactoring the code to comply w/ styleguides and rules. There are many great rules in eslint that cover most known anti-patterns. For a start, just grab the .eslintrc.json from the microsoft/typescript repo.

We've hooked up "eslint --fix" and "prettier --write" to "npm run fix".

One command before committing and you comply with all our coding rules. Easy, peasy. We tie the combined checks into "npm run check", and run this in CI/CD, so we know only compliant code is merge. Check!

Most other lang tools _won't_ do this. Take PMD or Checkstyle for Java. They'll just fail your build, but won't make your code compliant.

Finally, if you decide you want to add a new code convention to your repos, it's just a one liner: "npm run fix". It doesn't get much easier.

IDE integration is one benefit, as in VS Code showing the linting issues without compiling.

Have you tried some of the type info based rules in typescript-eslint? They're fantastic.

No floating promises, no bad templating, etc.

Linting is not the same as typechecking. Take a look at the default available rules [1]. For example number == NaN is valid Javascript, but 99.9% of the time an error. Or you might want to require always using === over ==.

Generally, linting is things that are valid in the language, but still better to do otherwise.

[1] https://eslint.org/docs/rules/

I use eslint for things like catching left behind debugger and console statements.

e.g. ban `any`, which you cannot do with tsc.