Shared ESLint configs for Node, Web, React Native, and Expo projects.
Switch branches/tags
Nothing to show
Clone or download
ide and expbot Update dependencies and get tests passing again
Upgrades to ESLint 5 and the latest Babel plugins. Needed to update some tests too that were broken because of a dependency upgrade.

Closes #12

fbshipit-source-id: cf8537f
Latest commit c3a8c2c Aug 28, 2018

eslint-config-universe CircleCI

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


yarn add --dev eslint-config-universe

You will also need to install eslint and prettier:

yarn add --dev eslint prettier


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


  "eslintConfig": {
    // Choose from universe/native, universe/node, universe/web
    "extends": "universe"


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"]


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.