A note about linting: We use eslint to check that the styleguide is being followed. It runs in a pre-commit hook and as a part of the tests, but most contributors integrate it with their code editors for real-time feedback.

Here are some hints for getting eslint setup in your favorite editor:

Another tool we use for enforcing consistent coding style is EditorConfig, which can be set up by installing a plugin in your editor that dynamically updates its configuration. Take a look at the EditorConfig site to find a plugin for your editor, and browse our .editorconfig file to see what config rules we set up.

Setup Guide for VS Code Usersedit

Note that for VSCode, to enable "live" linting of TypeScript (and other) file types, you will need to modify your local settings, as shown below. The default for the ESLint extension is to only lint JavaScript file types.

"eslint.validate": [
  "javascript",
  "javascriptreact",
  "typescript",
  "typescriptreact",
]

Although, starting with ESLint v2.0.4, there is no need to use eslint.validate to parse typescript files as it works out of the box.

eslint can automatically fix trivial lint errors when you save a file by adding this line in your setting.

"editor.codeActionsOnSave": {
   "source.fixAll.eslint": true
}

Prettier extension/IDE plugin while maintaining the Kibana project. Formatting and styling roles are set in the multiple .eslintrc.js files across the project and some of them use the NPM version of Prettier. Using the IDE extension might cause conflicts, applying the formatting to too many files that shouldn’t be prettier-ized and/or highlighting errors that are actually OK.