トラストバンクのフロントエンドを支える（予定の）ESlint

こんにちは。フロントエンドエンジニアの片柳です。

先日、トラストバンク内での開発における共通ルールeslint-config-trustbankをリリースしました。

www.npmjs.com

もともと、トラストバンクのフロントエンドではリンター兼コードフォーマッターとしてESLintが導入していました。
しかし、細かな管理やメンテナンスを行なっていなかったため形骸化し、多くの問題を抱えながらの運用でした。

新たなルールを作成するにあたり、悩み、解決したいと考えた点を、簡単にではありますが紹介させていただきます。
今更かつ、決してモダンな内容ではありませんが、どうぞお付き合いください。

何のためのルールか

eslint-config-trustbankを作成するにあたり、2つの目標を設けました。
①ルールを見なくても、ルール通りの開発ができること。そして、②ルール変更に伴う修正をなるべくしなくても良いようにすることです。

1つ目は文字通り、コーディングを始める前のインプットをなるべく減らした上で、開発に携わるエンジニア全員が一貫したコードをかけるようにすることです。
たとえルールに沿わない書き方をしてしまったとしても、ESLintを利用することで自動的にフォーマットされ、必要なエラーが発生するような状態をイメージしています。。

2つ目は、端的にいうのであれば「既存のコードに変更を加えない」という目標です。
今回のルール作成は、煩雑になっていたコーディングルールを整えるためのものであり、既存のコードを綺麗に書き換えるためではないと考えたためです。
既存のメンバーが「今日からルールが変わったらしい」と意識することなく、また新しく参画したメンバーも「ルールを覚えなくては」と身構えることがない、双方がストレスのない開発を行えるようなルール作りを目指しました。

コーディング規約との共存

そもそも、トラストバンクのフロントエンドには、ドキュメントとしてまとめられたコーディング規約が存在します。
ES5*1の時代から少しずつ継ぎ足され、改良を重ねてきたそのドキュメントには、個々のエンジニアの癖を正す決まりごとから、コードレビュー時に見ておきたい指標、更にはインシデント防止のための施策まで、ありとあらゆるルールがひとまとめに管理されていました。
項目が多いが故に、「この修正は規約に沿っていない」などといった機能に全く関係のないレビューが乱立し、肝心のロジックや仕様に対しての指摘が漏れてしまうことが多々ありました。

eslint-config-trustbankの作成は、eslint --fixをかけた時、この規約通りのフォーマットに整えることができる状態を作ることから始まりました。
265種類*2あるルールを一度全て有効にし、ESLintを実行することで発生するエラーを見ます。
頻出しているエラーを抽出し、どのオプションを指定すればエラーを減らすことができるかを何度も繰り返し検討しました。

既存のコードとの共存

各ルールのオプションは、既存の規約に添いつつも、なるべく汎用性の高いルールを採用しました。

例えば、三項演算子の改行位置を指定するmultiline-ternaryでは、always-multilineを採用しています。
これを実際のJavaScriptに落とし込むと

foo > bar ? value1 : value2;

foo > bar ?
  value1 :
  value2;

この双方が規約上OKということになります。
ただし、

foo > bar ? value1 :
  value2;

上記のように、明らかに規則性のない改行を挟む書き方はNGとなります。
必要なのは一貫性のみであり、複数通りある書き方のどれを選ぶかは、機能のクオリティには関係ないという考え方からです。
「ルールが変わったから、今までの書き方を変えなくてはいけない」のようなストレスを軽減させる目的もあります。

一方で、どうしてもESLintに集約できないルールもありました。
既存のコーディング規約では、ifやforなどのスコープの指定方法として、

if (foo) foo++;

while (bar) {
    baz();
}

while (true)
  if(foo)
      baz();
  else
      foo++;

は、NGです。

ESLintのcurlyには、これを叶えるようなルールは存在しませんでした。このような場合には、あえてコーディング規約に記載を残し、ユースケースも含めて推奨されるフォーマットやルールを細かく説明するように加筆を行いました

今後の課題

最初に掲げた2つの目標を達成するための、今後の課題はあと3つです。

まず、現時点では制定したルールを自動で実行するようなプロセスがないということ。
どんなに丁寧にルールを整えても、実際に使われなければ意味がありません。
Jenkinsやpre-commit-hookの導入を行い、作業時に自動でチェックが行われるような環境づくりを対応中です。

ルール変更に伴う修正をなるべくしないように作成したeslint-config-trustbankですが、やはり、反映することで発生するエラーや差分がゼロではありません。
エラーの出っぱなしはエラーの放置へとつながり、せっかくの新ルールが活用される妨げとなりますので、現在ひとつひとつを確認しつつメンテナンスを継続しています。

ES6以降の書き方を前提に設定されたこのルールに、全くマッチしない古いプロジェクトもありました。
ルールを拡張しつつ、それぞれのプロジェクトに合った形で適応していくことも大きな課題であり、そのためにはまだまだ人の手が必要です。