Skip to content

Latest commit

 

History

History
91 lines (59 loc) · 3.18 KB

README.md

File metadata and controls

91 lines (59 loc) · 3.18 KB
Raw

Moneytree ESLint shared configuration

ESLint configuration that covers both safety and code-style rules, as used by Moneytree.

How to setup

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:

  • nodejs: Recommended base Node.js configuration.
  • nodejs-bin: Extends nodejs to specialize for Node.js CLI scripts.
  • nodejs-test: Extends nodejs 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.

Fine-tuning

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.

Plugins

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.

Supported ESLint version

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.

Contributing

Versioning

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 file variations are introduced (like nodejs-bin in the example above).

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.

License

MIT