Sane ESLint rules

ESLint, short for ECMAScript Lint, is a popular open-source tool widely used in the JavaScript community for static code analysis and enforcing coding conventions. It provides developers with a set of rules that help identify and fix potential errors, maintain code quality and promote best practices within JavaScript/Typescript projects.

It’s important to acknowledge that not all rules are universally helpful. Some rules may be considered overly strict or even counterproductive in certain contexts. Some rules can be overly restrictive or pedantic, leading to an excessive number of warnings or errors. These rules may hinder productivity, cause frustration, or even discourage developers from using ESLint altogether. Examples of such rules might include those that enforce a specific code style or formatting preference. This is further exarcebated by popular rule configs (looking at you airbnb-config).

As a strongly-typed afficionado, I’ve found that there are ESLint rules which may help in certain situations where Typescript is lacking. I have few conditions for deciding if a rule is useful:

  • It provides meaningful value that can’t be automated by prettier or some other tool;
  • It should be correct and useful in 99% of the cases.

So, with these criterias in mind, I’ve found the following rules to be useful in my everyday code wrangling:

  • strict-boolean-expressions - I’ve been bitten really bad by this bug in production so I always try to use this rule. Typescript won’t protect you from this bug:

    1
    2
    3
    const selectedIndex: number | null = 0;
    if (selectedIndex) {
    ...

    This rule basically forces the condition operand to always have a boolean type. This is the standard in Rust and Haskell.

  • no-return-await - this seems like a no-brainer, except it might make debugging harder. More info here;

  • require-await - this rule forbids marking functions as async if they’re not doing anything async.

  • no-extraneous-dependencies - a must for all published libraries. Due to an assumption made by npm about node_modules and folder structure, a library can use a transitive dependency (dependency of a dependency) without issues. The same library will breaks apart when installing with pnpm or yarn v2+. This bug is known as phantom dependency and you can read about it more here;

  • no-floating-promises - floating (or dangling) promises are an issue unique to Javascript async model. If promises are not handled, they’ll bubble up as unhandled promises and may crash the process.

dark
sans