Linting with eslint

Keeping the last developments in regard to our simple mono repository, here I am going to setup our linting process with eslint.

ESLint highly consensual on javascript ecosystem. I have been using it in all javascript project I have been on, in the last 3 years. ESLint prevents some human error, doing a static analysis of our code alerting to us in regard to some bad practices.

Linting Setup #

We will start by installing eslint and needed plugins for typescript. ESLint architecture works around plugins.

yarn add -WD eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser

In the root of our project we have to create an .eslintrc file with eslint configs for our project. We will follow the same technique of creating a general one config file, and then each package extending it and adapting it as needed. That way it is easier to maintain, when we want update our eslint rules:

{
  "env": {
    "es2021": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:@typescript-eslint/recommended-requiring-type-checking"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": 12
  },
  "plugins": ["@typescript-eslint"],
  "rules": {
    "prefer-const": "error",
    "@typescript-eslint/no-unsafe-member-access": "off",
    "@typescript-eslint/no-unsafe-call": "off",
    "@typescript-eslint/no-unsafe-assignment": "off"
  }
}

Here we are using a standard configs with recommended rules from:

For each of our packages we need to create a .eslintrc as well, extending the general one we have just created:

{
  "extends": "../../.eslintrc",
  "parserOptions": {
    "project": "tsconfig.json"
  }
}

Replicate it for packages/types and packages/utils.

Finally, lets add a script on each package.json to execute eslint on our files:

"lint": "eslint src --ext js,ts"

Add this line to scripts at package.json files for packages/types and packages/utils.

Go to each package folder an execute:

yarn lint

It should give no errors. However, it is important to have the IDE also alerting you for errors. I am using VSCode and while going to packages/types/src/Book.ts I have found the following error on VSCode in the first line in regard to export:

Parsing error: Cannot read file '…/tsconfig.json'.eslint

This does not make sense. It seems that VSCode needs to have a tsconfig.json at the root of the repository. I have tried to copy a tsconfig.json file to the root and it solves the problem, but I do not like it. It is hard to maintain and error prone.

After digging a while I found I would need to configure my workspace settings on VSCode with the correct directories for eslint plugin on VSCode. Added this to settings of workspace file in VSCode:

  "eslint.workingDirectories": [
    { "directory": "packages/types", "changeProcessCWD": true },
    { "directory": "packages/utils", "changeProcessCWD": true }
  ]

It has the downside of needed to add new entry everytime we have new package. However, I prefer this approach.

More information about it here and here

Now, everything should be ok, but I want to confirm eslint is really checking the rules configured. I am going to packages/utils/src/math.js and do the following change on sum function:

export function sum(one: number, two: number): number {
  let result = one + two;
  return one + two;
}

The VScode should be alerting to an error 'result' is never reassigned. Use 'const' instead

That is because we have configured the following eslint rule

"prefer-const": "error",

If we execute

yarn lint

Besides the error we also get a warning 'result' is assigned a value but never used

Ok, first things first. Lets change the let to const:

export function sum(one: number, two: number): number {
  let result = one + two;
  return one + two;
}

We now only have the warning on VSCode and while executing yarn lint, alerting us we are not using result var. Lets fix it:

export function sum(one: number, two: number): number {
  const result = one + two;
  return result;
}

We have solved the linting errors.

Next I am going to experiment with Lerna to make it easier to manage our packages in a mono repository.

Published