eslint-config-isaacscript
Introduction
This is a sharable configuration for ESLint that is intended to be used in TypeScript projects.
The config is environment-agnostic, meaning that it will work in client-side projects (e.g. React), server-side projects (e.g. Node.js), and so on.
Installation
This package is part of the isaacscript-lint
meta-linting package. It is recommended that instead of consuming this package directly, you instead list isaacscript-lint
as a dependency, as that will install both this config and all of the rule plugins that it depends on.
For installation instructions, see the isaacscript-lint
page.
Why Do I Need To Use ESLint?
Presumably, you are a TypeScript user who has used the language for a while. At this point, you have already realized that TypeScript saves you an enormous amount of time. The hours spent troubleshooting run-time errors from typos have become a thing of the past. Good riddance!
But there are many other code problems that do not have to do with types. In the same way that you want to use TypeScript to catch as many bugs as possible, you also want to use ESLint with a config that enables as many good linting rules as possible.
ESLint rules can help catch bugs, but they can also help to make your codebase more consistent and adhere to best-practices within the TypeScript ecosystem. Remember that code is read more often than it is written. If you care about your code being the best that it can possibly be, then using ESLint is a no-brainer!
Why Do I Need eslint-config-isaacscript
?
Your codebase deserves to be safe as possible and eslint-config-isaacscript
is the most comprehensive ESLint config out there.
Building an ESLint config from scratch takes many, many hours. ESLint has over 250 rules. typescript-eslint
has over 125 rules. And that's just the beginning.
Don't bother creating and maintaining a huge ESLint config yourself. We've done the work to:
- Enable every ESLint rule that we can find from trusted sources that provides value.
- Weed out the rules that don't apply to TypeScript codebases (because many ESLint rules were written before TypeScript existed).
- Weed out the rules covered by Prettier (because many ESLint rules were written before Prettier existed).
- Weed out the rules that are too noisy to provide value (and document them below).
Our Config Philosophy
We want to enable as many lint rules as possible, so that we can catch as many bugs as possible. Of course, this is a tradeoff: with more lint rules, we get more false positives. But in general, a few false positives are worth the time saved from investigating and squashing bugs. (More on false positives later.)
In line with this philosophy, our linting config enables nearly all of the recommended rules from both the core ESLint team and the TypeScript ESLint team, as well as some additional rules that catch even more bugs.
This config also assumes that you are using Prettier to format your TypeScript code, which is considered to be best-practice in the ecosystem. Subsequently, all formatting-related rules that conflict with Prettier are disabled. (However, we use a few formatting-related rules that are not handled by Prettier.)
Auto-Fixing
Deploying this ESLint config on an existing codebase can generate a ton of warnings. Fixing them all might seem overwhelming. While some warnings need to be fixed manually, a ton of ESLint rules have "auto-fixers". This means that the code will fix itself if you run ESLint with the --fix
flag. So, by running npx eslint --fix .
in the root of your project, you can take care of a lot of the warnings automatically.
Additionally, we recommend that you configure your IDE (i.e. VSCode) to automatically run --fix
whenever you save a file.
Dealing with False Positives
Your first reaction to having a bunch of yellow squiggly lines might be to disable any rule that gets in your way. However, even if you think an ESLint warning is superfluous, it is often a sign that your codebase is structured in a bug-prone or non-idiomatic way. Before simply disabling a rule, sometimes it is good to do some research and think carefully if your code can be refactored in some way to be cleaner.
Additionally, some ESLint rules are not about catching bugs, but are about code style and code consistency. If you find the new style to be foreign and weird, it can be tempting to ignore or disable the rule. But before you do that, consider the cost: your codebase will be deviating from others in the TypeScript ecosystem. It is really nice for everyone's code to adhere to the same look and the same standards!
With that said, with so many ESLint rules turned on, you will undoubtedly come across some false positives. You can quickly take care of these by adding a // eslint-disable-next-line insert-rule-name-here
comment. And you can automatically add the comment by selecting "Quick Fix" in VSCode, which is mapped to Ctrl + .
by default.
If you find yourself adding a lot of disable comments for a specific rule, then turn the rule off for the entire project by adding an entry for it in your .eslintrc.cjs
file. Some rules won't make sense for every project and that's okay!
Rule List
Below, we provide documentation for every rule that is disabled. (We take a blacklist approach rather than a whitelist approach.)