The biggest pain point of working with ESLint is that while it encourages uniformity, some organizations are unaware of the tools available to make their own style guides. While a project-level configuration may work for a small organization with one code repository, it scales poorly. As your company starts working on many different JS projects, new rules can crop up leading to different rules for different projects.
While some projects do require specific rules, you want a good starting point for all of your projects. You want a shared ESLint configuration for your organization. Let me show you how to make one.
Of course, after I go through the song and dance of setting this up for VideoAmp, I stumble upon this article about shared configs from ESLint’s documentation. Creating a shareable config is as simple as starting with a naming convention. From the docs:
Shareable configs are simply npm packages that export a configuration object. To start, create a Node.js module like you normally would. Make sure the module name begins with
eslint-config-, such as
After setting up your module, you can easily add an
index.js entry point. Here’s an example:
Once you have this set up, add this to your project’s
Building on top of existing styleguides
Some teams are very opinionated on code style, while some are just looking for a place to start. At VideoAmp, we wanted to combine our opinions with style consensus in the JS community. To that end, we ended up extending Airbnb’s base styleguide in our custom config.
If you want to use an existing styleguide in your organization’s config, simply add the styleguide to your
peerDependencies in your
package.json, and extend it in your
One Code Style, Multiple Dialects
So you now have a way to carry across your ESLint configuration, perhaps with even some rules extended from other styleguides. However, say there’s a scenario with a pre-ES6 codebase and you need specific rule subsets (one for ES5, one for ES6). Since some of our codebases at VideoAmp are in ES5, we still wanted a way to enforce best practices and rules.
ESLint allows you to share multiple configs by adding another file to your organization styleguide and referencing it in your
.eslintrc it would look something like this:
In your organization’s config package, you could structure your files like so:
- base.js - File where you keep rules for both ES5/ES6
- es5.js - File where you keep your specific ES5 rules
- index.js - Base entry point with default rules
As an example, you can extend your
index.js file from
base.js like so:
As a note,
require.resolveallows you to look up and return the location of a module without loading it.
If you wanted ES5 rules, you may specify that in your
One Config to Rule them All
So what’s the real benefit to your organization here? All of your styles and rules are consolidated in one place. This means you only have to change your organization config module in order to update your styles across your many repos, microservices, and projects.