Editorconfig, Prettier, ESLint(TSLint)でコード規約を守らせます!絶対に!
種別
Editorconfig, Prettier, ESLint(TSLint)とコーディング規約に関するものが三種類もあります。利用する場面によって使い分けを行います。
EditorConfig
エディタの整形に利用します。
.editorconfigファイルを利用して コードを書いているとき に整形します。
主にインデントの整形を行います。
Prettier
コード修正を行います。
Gitのコミット前にPrettierを掛けることでコードの表記の揺らぎを修正します。
ESLint
構文エラーを解析します。
TravisCIやCircleCI系のCIサービスと連携することで、PRがコード規約を守っていることを担保します。
3つもあるけどどれも使うの?
コーディング規約を適用するフェーズ、目的、規約の強さに応じて使い分けを行います。
Editorconfig
主にPrettierで設定した indent_size
や indent_style
を設定してインデントはコードを書いてる時点で揃えれるようにします。
Prettier
Prettierでチームで決めたコーディング規約を適用しましょう。
エディタのプラグイン等で保存時にフォーマットが効く設定にしている人がいると思いますが、念には念を入れてcommit時にフォーマットがかかるようにしておきます。
ESLint
フォーマットはPrettierに任せるのでESLintでは主に構文チェックを行います。
CIでESLintが通っているかを確認して、それが失敗していたPRはRejectするといったフローにすることができます。
導入
Editorconfig
今どきのエディタには大体対応しています。
それぞれのエディタでの詳しい導入方法は公式サイトにあります。
設定ファイルの書き方はEditorConfigにあります。
設定名 | 内容 |
---|---|
root | 基本的にtrue |
end_of_line | 改行コード。lfで統一させたい。 |
indent_style | ハードタブ(tab) or ソフトタブ(space) |
indent_size | インデントのサイズ。2か4。(昔は8もありました…!) |
charset | 文字コード。utf-8
|
tab_width | タブの幅。基本的に指定不要。省略するとindent_size。 |
trim_trailing_whitespace | 行末の空白を削除するかどうか。trueで。 |
insert_final_newline | 最終行に空行を入れるかどうか。trueで。 |
editorconfigの例です。
# .editorconfigが設置されている階層以下にルールを適用
root = true
# すべてのファイルに適用
[*]
# 改行コード指定: LF
end_of_line = lf
# 行末スペースを削除: 有
trim_trailing_whitespace = true
# ファイル末尾の改行: 有
insert_final_newline = true
# インデントスタイル: Tab
indent_style = tab
# インデント幅: 4
indent_size = 4
下記の記事がすごくよかったです。
どんなエディタでもEditorConfigを使ってコードの統一性を高める - Qiita
Prettier
Prettierにコードを整形させます。
整形するタイミングはGitでコミットする前が良いので、そこに引っ掛ける形にします。
prettier本体、lint-staged、huskyをインストールします。
$ npm install -D prettier lint-staged husky
husky
をインストールすると.git/hooks/
に各種フックを作成してくれます。
これらhuskyで登録されたフックがgit
コマンドに反応して呼び出され、package.json
に書かれた内容を実行します。
ESLint導入環境にprettierを追加して運用する - Kenta Katoh's Blog
husky
の設定はpackage.json
に"husky"
という項目を作って設定します。
そこからコミットの直前に"lint-staged"
を呼び出すようにします。
"lint-staged": {
"*.{js, ts, json, css, md}": [
"prettier --write",
"git add"
]
},
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
}
lint-staged
の中に"*.{js, ts, json, css, md}"
と指定することで、Prettierを反応させるファイルの拡張子を列挙できます。
過去のhusky
husky
系の記事を見ているとprecommit
を利用しているケースが多いです。
"scripts": {
"precommit": "lint-staged"
},
"lint-staged": {
"*.js": [
"prettier --write",
"git add"
]
}
ですが最近のhusky
では上記の書き方がdeprecatedになったようで、husky
か.huskyrc
、husky.config.js
に書くことが推奨されているようです。
Prettier自体の設定はESLintで適応させるconfigを参考にしてください。
ESLint
ESLintとその他必要なパッケージをインストールします。
$ npm install -D eslint eslint-config-prettier eslint-plugin-prettier
- eslint-config-prettier
- eslint-plugin-prettier
を導入するとEslintとPrettierが共存できるようになります。
.eslintrcは以下のような感じです。
{
"env": {
"node": true
},
"extends": ["prettier"],
"rules": {
"prettier/prettier": ["error"]
},
"plugins": ["prettier"]
}
あとはお好みでaribnbのconfigやjestのプラグインなどを入れましょう。
まとめ
この3つを導入することで
- コードを書く
- コードをコミットする
- コードをPRする
という3フェーズでコーディング規約をチームメンバに守らせることができます。
サンプル
コマンド
$ yarn init -y
$ yarn add -D prettier lint-staged husky
# gitignoreの導入
$ gibo dump Node >> .gitignore
Sider
Lint系を簡単に導入できるCIサービス、Siderを導入します。
参考サイト
Editorconfig, Linter, Prettier についてざっくり理解する - Qiita
Prettier 入門 ~ESLintとの違いを理解して併用する~ - Qiita
TypeScriptのリンター(TSLint)の設置 - Qiita
コミット前に Lint を強制するなら lint-staged が便利 - Qiita