Sharing ESLint Across Teams

ESLint has won us over, and any doubts we had about the need for “Yet Another Linter” have been answered.

Anyone can customize ESLint as they please, using both the built-in rules and creating their own. Then when you’re done with that, sharing your settings is amazingly simple.

You Get ESLint! And You Get ESLint!

One looming question we had when researching ESLint was how we’d manage our configuration across dozens of different code repos. While we could set up a template .eslintrc file for teams to use when they first initialize their codebase, keeping them all up to date was going to be a maintenance headache.

That’s why we did a little dance when we read about ESLint’s Sharable Configs functionality. There are already hundreds of shared ESLint configurations out there, including popular rulesets like Standard and Semistandard. Even companies like Airbnb are getting in on the fun.

Shareable configs seemed perfect for our needs; all we had to do was define our rules and publish them as an NPM module.

Setting up our NPM Module

The ESLint documentation covers setting up the NPM module very well, so read through their docs for more information on that.

The one thing to note is that we decided to publish our module on our private NPM instance (named eslint-config-invision to match the preferred ESLint naming scheme). We’re looking in to making this part of the public sphere, so keep an eye out on it for the future.

Project Settings

Now that we had our NPM module, projects could use it by simply running npm install eslint-config-invision, then adding a basic .eslintrc file to their project root:

{
    extends: "eslint-config-invision"
}

One of the great benefits of this setup is the ability for projects to have their own overrides to our default rules. While we encourage everyone to use the standard configuration, sometimes it’s necessary to break the rules.

Here’s an example of a project setting up a specific override to allow for console usage (as the code is a simple command line utility):

{
  extends: "eslint-config-invision",
  "rules": {
    "no-console": 0
  }
}

Multiple Configurations

Since our codebases represent both Browser and NodeJS code, we left out the browser specific settings from our base configuration.

To provide these browser configurations for UI projects, we created a couple more rulesets: one for our common UI code (browser.js, and another for our React code (react.js).

Here’s what our browser.js configuration looks like:

{
    "extends": "./index.js",

    "env": {
        "browser": true,
        "jquery": true
    },

    "globals": {
        "angular": false
    }
}

The browser.js and react.js files live right next to our main index.js file, so everything is neatly packaged together.

One specific point to make is that we’re extending a js file, which is different than our normal eslint-config-invision value for extends. This is due to the fact that we’re doing this from within our NPM module, which doesn’t have access to the eslint-config-invision namespace. Instead, we load the file directly.

The new settings file is saved as browser.js and it’s ready for use via our module. Using these specialized settings is only little different from the original setup:

{
    extends: "eslint-config-invision/browser"
}

We also have a React specific file, named react.js, that can be loaded via eslint-config-invision/react. In the future, we may add a tests file for our test files, or any other configuration we find the need to have.

There are many reasons why we love ESLint, and shareable configs is just one of them. Be sure to check out their homepage for more details on the project.