Static code analysis can be used to detect common errors in your code and keep the style consistent across your team. In this article I want to share some of the tools that I can recommend.
Prettier formats your code by a very opinionated rule set. It avoids unnecessary changes caused by different formatting in your git commits. This is especially useful in code reviews, as you don't get distracted by bloated diffs.
"extends": "eslint:recommended" in the configuration and enable/disable individual rules as needed.
If you want to use Eslint with Typescript, you should install and configure the Typescript Eslint Parser.
The following plugins might be useful to you:
- eslint-config-prettier disables all the eslint rules, that might conflict with the prettier formatting.
- eslint-plugin-import provides a set of rules to manage the imports in your project. I especially recommend the order rule, which automatically sorts your imports. This also avoids unnecessary diffs in your pull requests.
- eslint-plugin-unused-imports. Unused imports can increase your application size and reduce readability. With this plugin you can automatically remove imports with no reference in your code.
- The default eslint rules are great, but eslint-plugin-unicorn adds a lot more. For example with the prevent-abbreviations rule, you can ban abbreviations that might reduce clarity of you code. I suggest that you use the recommended configuration of this plugin.
- eslint-plugin-node extends ESLint with some Node.js specific rules. For example, it can enforce the use of the new promise based fs module with the node/prefer-promises/fs rules.
- eslint-plugin-json includes JSON specific rules. This is especially useful, to prevent malformatted json configurations.
- Last but not least, the eslint-plugin-eslint-comments detects the abuse of eslint escape comments like
/* eslint-disable */. For example it warns you, if the exception is to general or redundant.
Start with the recommended settings of each plugin and enable or disable individual rules based on your project needs. An exception is the eslint-plugin-import. As the individual rules are relatively slow, I would just pick the rules that are worth the performance impact. You can measure the performance impact of each rule by setting the environment variable
TIMING=1 (source). I would also recommend setting
--cache flag of eslint to improve performance.