読者です 読者をやめる 読者になる 読者になる

Connehito開発者ブログ

Connehito Engineer's Blog

ESLintを途中で導入したときの.eslintrcの設定と運用方法について考えた

javascript eslint tool

f:id:dachi023:20160401044514j:plain

こんにちは。花粉症に悩まされているエンジニアの安達(@ry0_adachi)です。

前回は運用中のサービスへのwebpackの導入についてお話しさせていただきましたが、今回はESLintの導入と運用方法について話していきたいと思います。

Linterを途中から導入したときの課題

複数人の開発メンバーがいる状況下でLinterがあるとコードの書き方が統一できたり、定義忘れなどでの不要なエラーを未然に防ぐことができます。
便利なツールなのでプロジェクトの途中からでも入れたい!と思う方は少なくないかと思いますが、その際に高確率で発生する問題があります。

既存のコードでエラーが出る

全く出ないということはほぼ無いかな、と。行末にスペースが紛れてしまったりとか気をつけていてもたまにやってしまったりします。
そんなわけでLinterを途中から導入した際に発生したエラーとどう向き合って、今後エラーを無くしていくためにどう運用していくかを考えることにしました。

ESLintとは

今回導入したのはESLintというJavaScriptのコードの書き方をチェックするためのLinterです。
主にインデントのズレ、未定義 or 未使用の変数がある、セミコロンが無い、などを検知して警告やエラーを出してくれます。

どんなプロジェクトにも合わせられる

大げさかもしれませんが、割と本当です。それくらいESLintは柔軟です。

  • ルールはそれぞれ独立しているので個別に設定することが可能
    • on/offが選択できる
    • 警告 or エラーを選択できる
  • 独自ルールを定義できる
  • 標準で多くのルールがある
    • 標準のルールだけでも十分にLinterとしての威力を発揮してくれます
  • プラグインが豊富
    • 各種フレームワークにも対応できる

JSHintなどの他のLinterとの大きな違いとしては独自にルールを作成でき、プラグインとして追加できることです。
これによって柔軟性が大幅に高まり、独自ルールがあるような場合にも合わせることが可能になっています。

運用方法を考えて実践する

1. とりあえずrecommendedだけ

ESLintには推奨の設定が用意してあります。.eslintrcに下記のように定義します。

envは該当の環境で定義される変数を自動で定義済みである状態にしてくれます。browserならdocumentとかですね。それによって未定義の変数でエラー、とならなくなります。
browserifywebpackを使用している場合はcommonjsもtrueにしておきます。

まずはrecommendedで怒られるエラーだけを直していくのが良いと思います。
その後ルールを後追いで追加して、という形にした方がエラーの修正にかかる時間を分散できるから。という理由です。

2. 見つけたら直してもらう

プロダクトコードの修正などで実装する箇所でエラーが出ていたらついでに直してもらうようメンバーにお願いします。そうすることでプロダクトの開発をしながらでもエラーの数も減っていき、少しずつコードも綺麗になっていきます。

機能やコンポーネントごとにファイルが綺麗に分割されているのであれば触ったファイルの全てのエラーを直す、というやり方が可能です(きっと1ファイル数十行、とかなので)。
もしそういったやり方が少し難しいな、と感じたら関数ごとに直していく、など一度で直す範囲を狭めるのがライトでいいんじゃないかなと思います。

コネヒトでは事前にファイルを分割するというリファクタリングを行っており、短いコードが多いので、もしエラーがあればファイルごとに直すようにしています。

3. 足りなければルールを追加する

もし必要なルールが増えた場合は追加します。
例としてセミコロンがないとエラーになるようにしてみましょう。

これでセミコロンを忘れた場合に怒られるようになりました。そしてこれを「ここまでやれば十分!!」となるまで繰り返します。
一度追加したルールはその後も怒られる対象なのでせっかく直したのにまたエラー...ということはないでしょう。

4. 綺麗なコードを目指して

後は2と3を繰り返していくだけです。
最後まで頑張るのが何よりも大事ですので根気よく続けていきましょう。

まとめ

  • Linterをプロジェクトの途中から導入すると既存のコードでエラーが発生しやすい
  • ESLintは柔軟性が高く様々なプロジェクト、プロダクトに対応するための設定が可能
  • まずはrecommendedのエラーを消すところから始めて、直し終わったらルールを足す→エラーを消す、を繰り返す

余談ですが、最初から導入できるのであればそちらの方がいいですよ!!

最後に

いかがでしたでしょうか?ドキュメントだけではなかなか運用が難しいコーディング規約もツールで自動チェックができるようになります。簡単に導入できるのでまだ入れていない方はぜひこれを機にチャレンジしてみてください。