はじめまして、新卒でリンクアンドモチベーションに入社し、未経験からエンジニアをして4年目になります小宮です。入社して以来、一貫してモチベーションクラウドの開発業務に従事しております。
今回、そんな僕が3ヶ月ほどソロプロジェクトとして取り組んでいたESLintの整備PJTについて、まとめていきたいと思います。
整備前の状態
元々試験運用的に一度導入したことがあったのか、エラー解消に至っていない、対応が必要なルールを暫定的にOFFにするというコメントが設定ファイルに記載されており、ほぼESLintがワークしていませんでした。そのため、人によってコーディングの差異が発生しており、
フロント横断組織*1に所属しているメンバーが各々のチームでそれをコードレビューで解消している状態でした（つらい）
この状態を解消すべく、以下に示す3つの手順で今回ESLintの整備を行いました。
Phase1 - 既存ルールを適用
Offになっているルールを1つずつ修正していって、リリースを3-5つぐらいの粒度で行っていきました。基本的には --fix オプションを付ければ自動で修正してくれますが、一部自動修正が効かないルールがあるので、そちらに関しては手で解消していきました。
これぐらいの粒度で改修を行うメリットとしては以下の内容が挙げられます
他チームとのコンフリクトを避けられる
影響範囲が把握しやすいので、特に手で解消したルールに関しては動作確認の上、安心してリリースできる
Phase2 - パッケージ群のアップデート
パッケージ群も古くなっていたので、アップデートも一緒にやりました。
よくESLintのスタイルとしてAirbnb vs Standard どちらを適用するか？ *2というのも議論に上がると思うのですが、モチベーションクラウドはそこまでフォーマットをガチガチにする文化でもなく、よほど強く縛りたいルールは設定ファイルで対応することも可能なので、Standardを継続して利用しました。
ちなみに今回アップデートして活用しているパッケージ群は以下になります
"eslint": "^7.23.0", "eslint-config-prettier": "^8.3.0", "eslint-config-standard": "^16.0.2", "eslint-plugin-import": "^2.22.1", "eslint-plugin-node": "^11.1.0", "eslint-plugin-promise": "^4.3.1", "eslint-plugin-vue": "^7.8.0",
Phase3 - huskyとlint-stagedの導入
さて、これで無事に既存コードを綺麗にすることが出来ました！
しかしもう1つ問題が残っています。開発者はcommit / pushする前に常にLinterを手で打たなきゃいけません。これを忘れるとCIに怒られるまでLinter忘れに気づかないということで開発生産性を落としてしまいかねません。
ここでhuskyとlint-stagedの導入を検討しました。ここでjsファイルもしくはvueファイルに変更が加えられていた場合のみ、そのファイルに対してだけLinterを通すようにしたいので、以下のように設定しました。
.husky/pre-commit : コミット時に読み込まれ、yarn lint-stagedを実行する
package.json : 以下のように修正を加え(一部省略)、Linterを実行する
"scripts": { "lint:commit": "git --no-pager diff --staged --name-only | read v; eslint --fix $v", "lint-staged": "lint-staged --allow-empty" }, "lint-staged": { "*.{js,vue}": [ "yarn lint:commit" ] },
これにより、無事ESLintの整備が完了です
最後に
最近エンジニアはもちろん、社内全体でDX(Developer Experience)に対する感度が上がってきており、このような既存コードに対する改善活動が以前よりもかなり頻繁に行われているように感じています。
とはいえ、まだまだやりたいことも山積みの状態なので、弊社では絶賛一緒に働く仲間を募集中ですので、興味のある方は採用ページをご覧いただけると幸いです！
