eslint-config-universe-error

Shared ESLint configs for Node, Web, React Native, and Expo projects.

Diff from eslint-config-universe

The original package eslint-config-universe is based on trust that everyone will fix their work and eslint warnings before commiting.

But as this is not always the case, this repo switches every rule from warning to error in order to prevent a CI from validating incorrectly styled code.

Installation

yarn add --dev eslint-config-universe

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 universe/native, universe/node, universe/web
    "extends": "universe"
  }
}

.eslintrc.js

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

Customizing Prettier

If you would like to customize the Prettier settings, create a file named .prettierrc in your project directory. This file must declare a Prettier configuration like this:

{
  "printWidth": 100,
  "tabWidth": 2,
  "singleQuote": true,
  "jsxBracketSameLine": true,
  "trailingComma": "es5"
}

Support for Different Platforms

There are several configs for different platforms. They are:

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

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

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

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

"eslintConfig": {
  "extends": ["universe/node", "universe/web"]
}

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.