Share Configurations (Deprecated)

To share your ESLint configuration, create a shareable config. You can publish your shareable config on npm so that others can download and use it in their ESLint projects.

This page explains how to create and publish a shareable config.

Creating a Shareable Config

Shareable configs are simply npm packages that export a configuration object. To start, create a Node.js module like you normally would.

The module name must take one of the following forms:

Begin with eslint-config-, such as eslint-config-myconfig.
Be an npm scoped module. To create a scoped module, name or prefix the module with @scope/eslint-config, such as @scope/eslint-config or @scope/eslint-config-myconfig.

In your module, export the shareable config from the module’s main entry point file. The default main entry point is index.js. For example:

// index.js
module.exports = {

    globals: {
        MyGlobal: true
    },

    rules: {
        semi: [2, "always"]
    }

};
1
2
3
4
5
6
7
8
9
10
11
12

Since the index.js file is just JavaScript, you can read these settings from a file or generate them dynamically.

Publishing a Shareable Config

Once your shareable config is ready, you can publish it to npm to share it with others. We recommend using the eslint and eslintconfig keywords in the package.json file so others can easily find your module.

You should declare your dependency on ESLint in the package.json using the peerDependencies field. The recommended way to declare a dependency for future-proof compatibility is with the “>=” range syntax, using the lowest required ESLint version. For example:

{
    "peerDependencies": {
        "eslint": ">= 3"
    }
}
1
2
3
4
5

If your shareable config depends on a plugin, you should also specify it as a peerDependency (plugins will be loaded relative to the end user’s project, so the end user is required to install the plugins they need). However, if your shareable config depends on a custom parser or another shareable config, you can specify these packages as dependencies in the package.json.

You can also test your shareable config on your computer before publishing by linking your module globally. Type:

npm link
1

Then, in your project that wants to use your shareable config, type:

npm link eslint-config-myconfig
1

Be sure to replace eslint-config-myconfig with the actual name of your module.

Using a Shareable Config

To use a shareable config, include the config name in the extends field of a configuration file. For the value, use your module name. For example:

{
    "extends": "eslint-config-myconfig"
}
1
2
3

You can also omit the eslint-config- and it is automatically assumed by ESLint:

{
    "extends": "myconfig"
}
1
2
3

You cannot use shareable configs with the ESLint CLI --config flag.

npm Scoped Modules

npm scoped modules are also supported in a number of ways.

You can use the module name:

{
    "extends": "@scope/eslint-config"
}
1
2
3

You can also omit the eslint-config and it is automatically assumed by ESLint:

{
    "extends": "@scope"
}
1
2
3

The module name can also be customized. For example, if you have a package named @scope/eslint-config-myconfig, the configuration can be specified as:

{
    "extends": "@scope/eslint-config-myconfig"
}
1
2
3

You could also omit eslint-config to specify the configuration as:

{
    "extends": "@scope/myconfig"
}
1
2
3

Overriding Settings from Shareable Configs

You can override settings from the shareable config by adding them directly into your .eslintrc file.

You can share multiple configs in the same npm package. Specify a default config for the package by following the directions in the Creating a Shareable Config section. You can specify additional shareable configs by adding a new file to your npm package and then referencing it from your ESLint config.

As an example, you can create a file called my-special-config.js in the root of your npm package and export a config, such as:

// my-special-config.js
module.exports = {
    rules: {
        quotes: [2, "double"]
    }
};
1
2
3
4
5
6

Then, assuming you’re using the package name eslint-config-myconfig, you can access the additional config via:

{
    "extends": "myconfig/my-special-config"
}
1
2
3

When using scoped modules it is not possible to omit the eslint-config namespace. Doing so would result in resolution errors as explained above. Assuming the package name is @scope/eslint-config, the additional config can be accessed as:

{
    "extends": "@scope/eslint-config/my-special-config"
}
1
2
3

Note that you can leave off the .js from the filename.

Important: We strongly recommend always including a default config for your plugin to avoid errors.

Local Config File Resolution

If you need to make multiple configs that can extend each other and live in different directories, you can create a single shareable config that handles this scenario.

As an example, let’s assume you’re using the package name eslint-config-myconfig and your package looks something like this:

myconfig
├── index.js
└─┬ lib
  ├── defaults.js
  ├── dev.js
  ├── ci.js
  └─┬ ci
    ├── frontend.js
    ├── backend.js
    └── common.js
1
2
3
4
5
6
7
8
9
10

In the index.js file, you can do something like this:

module.exports = require('./lib/ci.js');
1

Now inside the package you have /lib/defaults.js, which contains:

module.exports = {
    rules: {
        'no-console': 1
    }
};
1
2
3
4
5

Inside /lib/ci.js you have:

module.exports = require('./ci/backend');
1

Inside /lib/ci/common.js:

module.exports = {
    rules: {
        'no-alert': 2
    },
    extends: 'myconfig/lib/defaults'
};
1
2
3
4
5
6

Despite being in an entirely different directory, you’ll see that all extends must use the full package path to the config file you wish to extend.

Now inside /lib/ci/backend.js:

module.exports = {
    rules: {
        'no-console': 1
    },
    extends: 'myconfig/lib/ci/common'
};
1
2
3
4
5
6

In the last file, once again see that to properly resolve your config, you need to include the full package path.