An ESLint Shareable Config to find errors, typos and potentially dangerous code.
Table of Contents
You'll first need to install ESLint:
$ npm install eslint --save-dev
Note: You may install ESLint globally using the
$ npm install eslint-config-pedant --save-dev
Note: If you installed ESLint globally (using the
-g flag) then you must also install
A globally-installed instance of ESLint can only use globally-installed ESLint plugins. A locally-installed ESLint can make use of both locally- and globally- installed ESLint plugins.
Shareable configs are designed to work with the
extends feature of
.eslintrc files. You can learn more about Shareable Config on the official ESLint website.
Add this to your
Note: We omitted the
eslint-config- prefix since it is automatically assumed by ESLint.
You can override settings from the shareable config by adding them directly into your
By default rules are suitable for
ECMAScript 2015 or higher.
ECMAScript 2015 or higher, your config file should look like this:
If you are not using
ECMAScript 2015, you can choose the config for
Or config for
Whether this config is suitable for me?
Most likely this config will suite you, because it contains only those rules which are necessary to find errors, typos and potentially dangerous code.
To make sure that this config is right for you:
- Look at the examples of incorrect code.
- Look at the rules from this config. The detailed information about each rule you can find on the eslint website.
- Try this config in your project. If you agree with those errors then this config is for you.
Why this config does not contain stylistic rules?
This config intentionally does not limit your choice of code style.
If you want to check code style of your code you can add stylistic rules to your config in your project.
Also, you can create your own Shareable Config or use one of the existing.
Semantic Versioning Policy
However, due to the nature of ESLint, it's not always clear when a minor or major version bump occurs. To help clarify this for everyone, ESLint defined the following semantic versioning policy:
- Patch release (intended to not break your lint build)
- A bug fix in a rule options that results in ESLint reporting fewer errors.
- Improvements to documentation.
- Non-user-facing changes such as refactoring code, modifying tests, and increasing examples coverage.
- Re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone).
- An existing rule is replaced (if rule is deprecated) that results in ESLint reporting fewer errors.
- Minor release (might break your lint build)
- A bug fix in a rule options that results in ESLint reporting more errors.
- An existing rule is replaced (if rule is deprecated) that results in ESLint reporting more errors.
- A new rule is added that does not result in ESLint reporting more errors by default.
- A new option to an existing rule is added that does not result in ESLint reporting more errors by default.
- New capabilities to the public API are added (new presets, etc.).
- Major release (likely to break your lint build)
- A new rule is added that results in ESLint reporting more errors by default.
- A new option to an existing rule is added that results in ESLint reporting more errors by default.
- An existing rule is removed (if rule is not deprecated).
- Part of the public API is removed or changed in an incompatible way (removed presets, etc.).
According to our policy, any minor update may report more errors than the previous release (ex: from a bug fix). As such, we recommend using the tilde (
"eslint-config-pedant": "~1.0.0" to guarantee the results of your builds.
MIT © Andrew Abramov