Eslint-config-heimdall NPM

eslint-config-heimdall

npm Branches Functions Lines Statements Jest coverage

Shared ESLint configs for Node, React, and universal Expo projects.

Installation

yarn add --dev eslint-config-heimdall

You will also need to install eslint and prettier:

yarn add --dev eslint prettier

Usage

Import this config into your own ESLint configuration using the extends option. ESLint checks both package.json and .eslintrc.* files for its configuration:

package.json

{
  "eslintConfig": {
    // Choose from heimdall/native, heimdall/node, heimdall/react
    "extends": "heimdall"
  }
}

.eslintrc.js

module.exports = {
  extends: 'heimdall',
};

Customizing Prettier

If you would like to customize the Prettier settings, create a file named .prettierrc in your project directory. An example of Prettier configuration file:

{
  "bracketSpacing": true,
  "singleQuote": true,
  "trailingComma": "all",
  "semi": true,
  "tabWidth": 2,
  "printWidth": 120,
  "jsxBracketSameLine": false,
  "arrowParens": "always"
}

Read more about configuring prettier and all of the available options.

Support for Different Platforms

There are several configs for different platforms. They are:

heimdall: the basic config for JavaScript projects for which there isn't a more specific config,
heimdall/native: the config for React Native projects, including Expo projects, with support for React and JSX,
heimdall/react: the config for code that runs in web browsers, with support for React and JSX,
heimdall/node: the config for code that runs in Node.

For an Expo project, your configuration might look like this:

"eslintConfig": {
  "extends": "heimdall/native"
}

You also can extend multiple configs, which is useful for projects that span several platforms:

"eslintConfig": {
  "extends": ["heimdall/node", "heimdall/react"]
}

Philosophy

This config is designed to mark severe problems (ex: syntax errors) as errors and stylistic issues as warnings. This lets your team apply policies like, "make sure a commit has no errors but ignore warnings if the commit didn't introduce them."

It's also designed to be a more lenient config for teams who are stronger at decision-making and have a culture of osmotically learning coding guidelines and benefit more from flexibility than rigid rules.