@goodhello/eslint-config

@goodhello/eslint-config

This package provides shareable ESLint configurations for JavaScript projects that conform with Good Hello's coding style.

Installation

To make use of this config, install ESLint (>= 4.0) and this package as a development dependency of your project:

npm install eslint @goodhello/eslint-config --save-dev

Next, add an eslintConfig member to your project's package.json. At a minimum, this config file must include an extends member:

{
  "eslintConfig": {
    "extends": "@goodhello"
  }
}

See the ESLint configuration guide for details on additional configuration options. Any rules configured in your package.json file will override those provided by the @goodhello/eslint-config package.

Use

You should run the linter as part of (or before) your tests. Assuming tests are run before any proposed changes are merged, this will ensure coding standards are maintained in your default branch. Using npm scripts is the preferred way to run the linter without requiring it to be a global dependency. Assuming you want to lint all JavaScript files in your project, add the following entry to your package.json:

{
  "scripts": {
    "pretest": "eslint src"
  }
}

With this pretest entry in your package.json, ESLint will run on all JavaScript files in the src directory of your project using your .eslintrc config when tests are run:

npm test

See the ESLint CLI guide for additional options when running ESLint.

In addition to running the linter when your tests are run, you should configure your editor to run the linter as well. See the ESLint integration page to find details on configuring your editor to warn you of ESLint errors.

See the examples directory for more usage examples.

Development

After modifying the config or an example, run npm test to test your changes and publish a new version of the package. Adding a new "error" level rule constitutes a major release. A new profile or non-breaking modification to an existing profile (e.g. a "warning" level rule) can be a minor release.

Publishing a new minor release would look like this:

# commit and push any changes first
npm version minor # this bumps the package.json version number and tags
git push --tags origin master
npm publish