Syndicating ESLint: Configure Once, Extend Everywhere

In code, as in ice skating, style counts. Legibility, consistency, and team harmony are all benefits of embracing the pedantic pursuit of rules. More than any of these benefits, however, a well defined style guide can help us avoid common pitfalls and keep our code reviews far far away from the bikeshed and focussed on actual software design.

But as nice as any set of well defined rules might be, it’s nothing without the mercenary enforcement of a cold and unfeeling machine. Enter ESLint, with its seemingly exhaustive set of configurable rules and its truly exhaustive family of rules plugins.

Whether you start with the eslint --init questionnaire automation or by manually extending eslint:recommended (it’s in the box!) or airbnb with a few custom nits, it can take some fiddling to get things how you want them. Sure would be swell if you could just fiddle once and share the results across your entire organization or project family.

Truth told it’s pretty easy. Start by configuring your rules in whichever way you prefer. I like to use multiple files divided by domain.

Maybe not quite as granular as the example above, but you get the idea.

Next you’ll want to pull it all together with an entry point. Let’s call it index.js. Remember, we’re publishing this config as a JS module, so an .eslintrc alone won’t do.

A couple quick points. This file can be as simple or complex as you want. It can contain all of the rules and globals and whatnot or extend them from external files (as below) and modules. In the case of extending, it’s worth noting that rule priority is ascending with the highest array index taking the captain seat.

module.exports = {
  "extends": [
    // Least Important
    "./rules/quotes.js",
    "./rules/quotes-override.js"
    // Most Important
  ]
}

The name of the file is unimportant so long as it’s pointed to by the main prop in your package.json.

Speaking of package.json. If you happened to use any outside packages or extend any third party configs, this is also where you’d declare those peer dependencies. eslint is, for obvious reasons, not optional.

{
  "name": "eslint-config-your-name-here",
  "version": "0.0.1",
  "author": {
    "name": "Chomper Missisippiensis"
  },
  "private": false,
  "license": "MIT",
  "main": "index.js",
  "peerDependencies": {
    "eslint": ">= 3"
  }
}

That’s it. Commit your changes. Push them. And, assuming you’ve got an npm user account, publish your shiny new configuration package with this intuitive command:

npm publish

The name of the package is derived from the name key in your package.json. The conventional naming pattern eslint-config-your-name-here is the way to go for two reasons: 1) it makes it very clear what your package is for and 2) when using the module you can leave off the eslint-config part and just extend your-name-here.

But how do I use it?

Couldn’t be easier. Hop into any project you’d like to conform to your style and install eslint and your config a la:

npm i eslint eslint-config-your-name-here

Now make yourself an .eslintrc and import your config.

{
  "extends": "your-name-here"
}

And that’s that. It’s kind of crazy how easy it is to publish a module on npm, right?

👉 The biggest gain with this sort of syndication is the ability to make changes in one place and see them propagate out to everywhere the rules are consumed. Pretty cool, no?