ESLint configuration that covers both safety and code-style rules, as used by Moneytree.
In your project, install this configuration:
npm install --save-dev @moneytree/eslint-config
Choose a configuration to use in your project (or a folder somewhere inside your project). Available options:
javascript
: Base JavaScript configuration.nodejs
: Recommended base Node.js configuration.nodejs-bin
: Extendsnodejs
to specialize for Node.js CLI scripts.nodejs-test
: Extendsnodejs
to specialize for Node.js unit test scripts.
Now refer to that configuration in your own ESLint configuration file, by extending from it:
YAML:
extends: "@moneytree/eslint-config/nodejs"
JSON:
{
"extends": "@moneytree/eslint-config/nodejs"
}
Replace "nodejs" by the configuration of your choice.
If you find that your project needs slightly different rules, or if you introduce this configuration into an existing project that may break too many rules, you can override the configuration. Especially in the latter case, we would suggest leaving the rule in place, but turning it into a warning instead, so that you can gradually update your code base and in the future turn that rule into an error again.
All rules are defined as a number or an array of which the first value is a number. That special first number is the level at which you want to apply the rule:
- 0: do not enforce rule
- 1: warning (only prints, does not make the lint check fail)
- 2: error (the lint check will fail)
To change a rule, simply rewrite the rule in your own configuration file, and adjust the level as you wish.
Depending on additional libraries you use, like testing frameworks, there may be some very interesting ESLint plugins for your project that you may want to add to your configuration. Check them out over at Awesome ESLint.
We attempt to keep the rules compatible and complete with regards to the latest version of ESLint. Sometimes we will inevitably fall behind a little. If you want to know which versions of ESLint we cover, please refer to the version of the ESLint peer-dependency in package.json.
We try to be semver-ish in how we version this project. To create a version-bump commit, simply
run npm version patch
, npm version minor
or npm version major
.
patch should get bumped when:
- New configuration files are introduced.
minor should get bumped when:
- Rules are changed.
- Rules are added.
- The
eslint
peer-dependency's minimal version is raised (which is usually when rules are added).
major should get bumped when:
- A major version bump of ESLint occurs that has significant impact on the users of this configuration.
- A massive overhaul of the project happens, implying changes to installation and/or integration.
- New peer-dependencies are required.
MIT