Linting
editLinting
editA 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:
Editor | Plugin |
---|---|
Sublime |
|
Atom |
|
VSCode |
|
IntelliJ |
Settings » Languages & Frameworks » JavaScript » Code Quality Tools » ESLint |
|
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 Users
editNote 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.