Setting up fool-proof linter rules

Viral Tagdiwala
3 min readJun 25, 2022

It doesn’t take too long for a newly setup typescript repository to be riddled with wild any ‘s and a bunch of copy-pasted files from developers in the team who didn’t bother to get rid of the imports they didn't use or the variables they never cared to plug in at the right places.

Some of these mistakes can be caught during the PR review process, however things like unused imports and a sneaky any might just slip by, increasing the entropy of changes over time & defeating the purpose of using typescript to being with.

In this article, I’ll be walking you through how does one go about setting up strict lint rules that make it fairly difficult if not impossible to have such issues slip in.

We’ll start off by installing the typescript-eslint plugin

npm i @typescript-eslint/eslint-plugin

This will later allow us to use strong pre-sets when we set up eslint

Once installed, head over to your .eslintrc.json (if you don't have the file in place, install eslint to your repository and generate this file)

Your default setup might look something like this

{ "root": true, "extends": ["next/core-web-vitals", "prettier"], "plugins": ["testing-library"], "overrides": [  // Only uses Testing Library lint rules in test files  {   "files": ["**/__tests__/**/*.[jt]s?(x)", "**/?(*.)+(spec|test).    [jt]s?(x)"],   "extends": ["plugin:testing-library/react"]  } ], "rules": {  "react-hooks/rules-of-hooks": "error", // Checks rules of Hooks  "react-hooks/exhaustive-deps": "warn", // Checks effect dependencies  "react/react-in-jsx-scope": "off",  "padding-line-between-statements": [   "error",   { "blankLine": "always", "prev": ["const", "let", "var", "if", "function"], "next": "*" },   { "blankLine": "any", "prev": ["const", "let", "var"], "next": ["const", "let", "var"] }  ] }
}

We’ll modify the extends first, adding in our defaults of typescript-eslint by

"extends": [  "next/core-web-vitals",  "eslint:recommended",  "plugin:@typescript-eslint/recommended",  "plugin:jest/recommended"],

Next, in order to avoid conflicts with the built-in functionality, we need to edit a few things, mainly to switch off the defaults and ensure eslint knows that it needs to use the typescript-eslint plugin’s defaults instead

"rules": {... "@typescript-eslint/no-unused-vars": "warn", "no-unused-vars": "off"}

We do this by switching off the default and making the ts-eslint defaults on.

There’s still one problem, developers can commit code with these warnings, and we need to stop that from happening, for that we need to head over to our package.json and modify the eslint declaration

Here I have a check-lint that runs as a pre-commit hook, notice the addition of — max-warnings:0

“check:lint”: “eslint . — ext ts — ext tsx — ext js — max-warnings 0”,

This ensures that the number of allowed warnings is 0, making the pre-commit hook fail when someone tries to check in such code.

And that’s pretty much it, this will ensure that

  1. No unused variables or declarations are allowed
  2. No any gets used + it also gives remediations for juniors as the error message instead of just saying any isn’t allowed
  3. If an any gets used, one needs to add a huge comment line above it, making it obvious to the reviewer

--

--