5 ms·
I’m curious about the value of eslint for TypeScript. I’ve not really found myself wanting from the coverage provided by tsc.
by meheleventyone 6y ago
I’m curious about the value of eslint for TypeScript. I’ve not really found myself wanting from the coverage provided by tsc.
- halfmatthalfcat 6y agoTo 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.
- WorldMaker 6y agoA lot of the most common TSLint "boxed" configurations have direct ESLint relatives at this point. For one opinionated example there is eslint-config-standard-with-typescript [1]. Using a prepared config like that is just as easy as using one built for TSLint. (It's an "extends" field that does most of the work.) Though I admit I've kind of moved more towards even more opinionated Prettier than ESLint lately. [1] https://www.npmjs.com/package/eslint-config-standard-with-typescript https://www.npmjs.com/package/eslint-config-standard-with-ty...
- city41 6y agoI use eslint for things like catching left behind debugger and console statements.
- andrew_ 6y agoThe 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.
- maga 6y agoprettier?
- madeofpalk 6y agoe.g. ban `any`, which you cannot do with tsc.
- metachris 6y agoIDE integration is one benefit, as in VS Code showing the linting issues without compiling.
- meheleventyone 6y agoI’m all for IDE integration but feel duty bound to point out tsc does this as well.
- thealfreds 6y agoIt'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.
- dtech 6y agoLinting 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/ https://eslint.org/docs/rules/
- meheleventyone 6y agoI’m aware of the difference just wondering what benefits people have found. Catching == versus === is a good one.
- GORRILA 6y agoTwo common rules I like to enforce are no nested ternaries and no unused variables.
- striking 6y agoHave you tried some of the type info based rules in typescript-eslint? They're fantastic. No floating promises, no bad templating, etc.
- meheleventyone 6y agoNo but the replies here make me think I should definitely give it a go. So thanks for the info everybody!
- twistedpair 6y agoTo 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.