eslint-config-invision

Release History

Overview

The lint rules defined here are shared via a public NPM module named eslint-config-invision. This allows us to have a common set of rules across multiple code repositories, without having to copy/paste those rules everywhere. See "ESLint's Sharable Configs article" for more details.

Basics

There are quite a few rules in our ESLint config. To help summarize, the major code guidelines are:

• Use semicolons at the end of each statement.
• Use double quotes.
• Use tabs for indention.
• Use multiple var declarations.

Discussion

For discussion of rules or any other lint topic, check out the InVision #eslint Slack channel.

Installation and Usage

Detailed information with an example folder/file setup is available in the examples\repo folder.

Testing

Detailed overview of how testing works for this repo.

Lint Variations

By default, the environment is set to node. However, in some code repositories, both browser and Node.js code co-exist.

To help keep linting more specific to the environment, additional files (browser.js, react.js) are available that have specific definitions.

To use one of these files, change the extends property value in your .eslintrc file to be "eslint-config-invision/name-of-file-here" (e.g. "eslint-config-invision/browser").

If you have a specific folder for these assets, you can also create a second .eslintrc file for that directory that includes this change.

Right now, there are three lint variations:

• Node: eslint-config-invision
• Browser: eslint-config-invision/browser
• React: eslint-config-invision/react (extends Node)

Rule Development

When modifying the rules, it's helpful to test them locally against an existing project. Using npm link can allow for this type of local development.

In this repo's folder, run npm link. In the folder of the project you want to run lint on, run npm link eslint-config-invision.

Commits

To help generate meaningful changelogs, this repo follows git commit message conventions.

Releases

Releases are handled through our standard NPM versioning process.

The majority of changes will be patch or minor. There may be many minor changes in a row, as the nature of the changes will likely be breaking.