Static analysis is a type of testing that provides automated checking of your code without actually running it or having to write an automated test. You've likely already seen this kind of testing if you use an IDE like VSCode—the type checking performed by TypeScript is a kind of static analysis, and it can show up as squiggly lines under errors or warnings.
ESLint
ESLint is a tool that can provide feedback on possible problems in your codebase. These problems may be typesafe, but errors or nonstandard behavior in their own right. ESLint lets you apply a number of rules that are checked on your codebase, including many in its "recommended" set.
A good example of an ESLint rule is its
no-unsafe-finally
rule. This prevents you from writing statements which modify your program's
control flow inside a finally block. This is a great rule, because doing this
is an unusual way to write JavaScript that can be hard to follow. However, it's
also something that a healthy code review process should be able to detect.
try {
const result = await complexFetchFromNetwork();
if (!result.ok) {
throw new Error("failed to fetch");
}
} finally {
// warning - this will 'overrule' the previous exception!
return false;
}
As such, ESLint isn't a replacement for a healthy review process (and a style guide that defines what your codebase should look like), because it's not going to capture every unorthodox approach that a developer might try to introduce into your codebase. Google's Eng Practices guide has a short section on "keeping it simple".
ESLint lets you break a rule and annotate code as "allowed". For example, you can allow the previous logic by annotating it as follows:
finally {