Adding ESLint to existing react project

Adding ESLint to an existing project is complicated and disrupting for the git history as well the developers. We have to try to make the disruption as minimal as possible, so it is better to follow an incremental approach. I'll be laying out the approaches regardless of the ESLint config you will use.

Prerequisites

• package.json and ESLint config
• git pre-commit hooks or husky

Deciding on the ESLint config

Make the editor ready with a config and the red/yellow underlines visible. Also run lint in the console and share the results with the team. Then discuss with the team and list out the rules that needs to be disabled, added or converted into warning.

"rules": {
    "no-unused-vars": "warn",
    "react/jsx-indent": "off",
  }

Make sure to edit the deployment workflow config to ignore warnings.

 

The strategies

• Disable ESLint for all files at the top
• Disable ESLint using the env variable
• Fix the most and disable the rest
• Convert all errors to warnings

 

👉🏽 Disable ESLint for all files at the top

In this case we just all the comment to the top of all the files, using sed.

find . -name "*.js" -exec sed -i '' '1i\
/* eslint-disable */
' {} + 

Once this is implemented, make sure the comment is removed by the developer when they submit a pull request. This way the app will compile without issues and minimal git changes.

 

👉🏽 Disable ESLint using the env variable

In this case we will disable ESLint for a certain period of time but still have linting enabled in a pre-commit hook.

To disable ESLint

If you are using CRA

In the .env file

DISABLE_ESLINT_PLUGIN=true

For ejected CRA or others using webpack

In the webpack config, inside the rules you can comment out the part where the ESLint rule is enforced or add the env check.

The ESLint resolver in webpack will look like the below code.

const disableESLintPlugin = process.env.DISABLE_ESLINT_PLUGIN === 'true';

!disableESLintPlugin &&
        new ESLintPlugin({
          // Plugin options
          // ....
        }

 

👉🏽 Fix the most and disable the rest

I won't recommend this method on a large code-base with many devs currently developing features on the same. It would suit in case you are doing a complete refactor of the code base, on an entirely new git repository.

First if you are using a style formatter(i.e. like prettify), run it first. In case you have prettier cli, you can run it directly

prettier --write

or you can configure in package.json

"scripts": {
    "format": "prettier --write \"**/*.{js,jsx,json,md}\""
}

Then proceed with the ESLint fix command.

"scripts": {
    "lint:fix": "eslint --fix src/**/*.{js,jsx}"
}

Then you might still end with lot of errors

Using auto suppressor

https://github.com/amanda-mitchell/suppress-eslint-errors

This tool will disable every error line by line, i.e. it will add the

// eslint-disable-line

for every single error. This might be a lot of change, but you can choose the rules to disable. The suppress-eslint-errors project is a small and easy to understand code, you can just clone and modify for your purpose.

 

👉🏽 Convert all errors to warnings

https://github.com/bfanger/eslint-plugin-only-warn

Install eslint-plugin-only-warn

$ npm install eslint-plugin-only-warn --save-dev

Add only-warn to the plugins section of your .eslintrc configuration file:

{
  "plugins": ["only-warn"]
}

This ESLint plugin will convert all the errors to warnings. You can slowly remove all the warnings. But make sure to add conditions in pre-commit hook to remove the warnings.

"scripts": {
  "lint": "eslint src/**/*.{js,jsx} --max-warnings=0",
},

 

Conclusion

You can pick any one of the strategies or a combination of them. The best strategy would be to add ESLint config at the start of the project itself.

Which ever strategy you pick, have a pre-commit solution like Husky and have the lint check in CI pipeline too.