虎の穴開発室ブログ

虎の穴ラボ株式会社所属のエンジニアが書く技術ブログです

MENU

HTML-ESLintを試験導入しました

技術エントリ

本記事は虎の穴ラボ Advent Calendar 2022 - Qiita 8日目の記事です。
前日はrhさんの「国産ヘッドレスCMS「Newt」を使ってみた」でした。

こんにちは。最近引っ越しを考えている虎の穴ラボの大場です。

先日、とらのあな通販開発チームの開発環境にHTML用のLinterとして HTML-ESLintを試験導入しました。

当記事では、その導入理由やツールの選定に際して考慮したことについて紹介いたします。

導入理由

ECチームでは以下の3つの状況と課題を踏まえてLinterの導入を行いました。

  1. HTMLのLinterが未導入だった
  2. フロントエンド実装のレビュー負担増加
  3. レビュー指摘にばらつきがある

1.HTMLのLinterが未導入だった

とらのあな通販開発チームではJavaに対してSpotbugs、JavaScriptに対してESLint、CSSに対してstyleLintといった具合でLinterを導入していましたが、HTMLについては未導入の状態でした。

2.フロントエンド実装のレビュー負担増加

とらのあな通販の開発案件の進め方としては、 一つの案件に対して一人のエンジニアが一気通貫で専任するような体制をとっています。

担当するエンジニアによってSEOやCWVといった非機能要件への意識に差があり、 後回しにされてしまうケースが見受けられました。

そこで、SEOやCWVのノウハウを持ったエンジニアがコードオーナーとして、 レビューを必須化しSEOやCWVの視点でコードをチェックできる体制にしました。

しかし、その分コードオーナーとなったエンジニアのレビュー負担が増えてしまったので、 ある程度品質を維持しながらも負担を軽減したいと考えました。

3.レビュー指摘にばらつきがある

非推奨の書き方を注意する、バグの温床になりかねない記述にも気付けるなど、 エンジニアによって指摘の範囲やレビューの内容は全く異なると感じています。

同じ人がレビューする場合でもその日の体調がすぐれてなかったり、抱えている案件の期限がギリギリになったりすると、 急いでレビューをしてしまい、いつもなら指摘できる部分をスルーしてしまうこともあるかと思います。

前回指摘されなかったのに、同じ書き方をして今回は指摘されたりなんて事があれば、 レビューイにとって混乱を招いてしまうため特に防止したいケースです。

Linterは銀の弾丸ではない

ただし、これら問題はLinterを入れたからといって万事解決できるわけではありません。

あくまでもLinterが機械的にチェックしてくれるルールの視点に限り任せられるようになるだけで、 決してレビューで手を抜いて良いわけでも無いですし、レビュワーの負担が0になるわけではありません。

レビュー指摘のばらつきに関しても平準化の手助けになるくらいの考えですので、 ことコード品質の向上に関しては内部で勉強会を開いたりチーム内で認識合わせを行う場が別途必要と考えています。

Linterの選定について

HTMLのLinterを調べるといくつかツールが見つかったので、以下の2つの指標のもとに選定を行いました。 1. 現在も開発が継続している 2. npmjsでのダウンロード数が多い

結果としては、タイトルの通り HTML-ESLint を導入しています。

1.現在も開発が継続している

昨今、HTMLの仕様がHTML5からHTML Living Standardに変わり継続的に日々更新されるようになりました。

移り変わっていく仕様に順応できるツールでなければ、非推奨になった記述を検知することができなかったり、 問題が無い記述にも関わらず、最新の仕様にツールが対応してないがためにエラーとして誤検知されてしまったりといった問題が発生します。 html.spec.whatwg.org

2.npmjsでのダウンロード数が多い

この選定基準はNode.js限定にはなりますが、

利用者数が多ければその分Googleで検索した際の情報がより多く見つかる可能性が高いです。 www.npmjs.com

情報が多い分、困った際も同様の事例を見つけやすく、トラブルシュートしやすいかと思います。

最悪ツール自体の開発が止まり、別のツールへの移行を余儀無くされることも起こり得るため、 そういったリスクは低いに越したことはありません。

HTML-ESLintについて

HTML-ESLintはES-Lint(JavaScript用のLinter)のPluginです。

既にES-Lintを導入されている場合は新たにツールをインストールするわけでは無いため、 管理コストが膨らまないのがメリットと言えます。 yeonjuan.github.io

インストール

$ npm install --save-dev eslint @html-eslint/parser @html-eslint/eslint-plugin

VSCodeでの拡張機能

もし読者の方がIDEとしてVSCodeを採用しているのであれば拡張機能(vscode-eslint)で、 ルールに反した記述をリアルタイムで検知することができます。

{
  "eslint.enable": true,
  "eslint.validate": [
    "javascript", // ...
    "html", // Add "html" to enable linting `.html` files.
  ],
}

引用元

yeonjuan.github.io

有効化ルールの選定について

HTML-ESLint には、レコメンドのルールセットが備わっています。 ※レコメンドのルールセットは下記リンクのリスト内で内で⭐️マークがついているものが対象です。 github.com

試しに既存のソースに対してレコメンドのルールでLintをかけてみると、 大量にルール違反が検知されてしまいました。 そのため、レコメンドルールは使わずに既存ソースを踏まえて独自のルールを設定することにしました。

選定したルールはマークダウンでまとめて、メンバー内に展開しています。

有効化ルール一部抜粋

今回のように実際に動いている開発プロジェクトに対して途中からLintを導入する場合は、 既存のソースやコーディングルールを踏まえてルール設定を行う必要があります。

とらのあな通販にはConcrete5というCMSで作成されたHTMLがベースにあり、そのルールに多少引っ張られてしまった部分がありました。

有効化ルール選定後

HTML-ESLintには、一部のルールに反した記述を自動で修正してくれる機能が備わっています。

有効化するルールを選定した後は、既存ソースに対して一括で自動FIXを実施しプルリクエストを作成しました。

ある程度既存のコーディングルールを踏襲したこともあり、 Diffは改行や空白の調整、シングルクォートやダブルクォートでの変更差分が9割以上を占めた結果となりました。

試験導入ということもあり、有効化したルールは全てWARNレベルで出力しています。

今後は、メンバーからのフィードバックを踏まえて、本格導入に向けて有効化ルール調整やGitHooksへの対応を進めていく予定です。

まとめ

今回はHTML用のLinterとしてHTML-ESLintを導入してみた事例について紹介しました。

類似したプラグインにeslint-plugin-htmlというものがあるのですが、 こちらはHTML内のScriptタグ内を解析するプラグインなのでご注意ください。

Linterの選定の仕方に関しては、私が事前調査を行った際は別のツールを仮選定していたのですが、 チーム内の有識者やデザイナーに相談しながら進めた結果、HTML-ESLintに落ち着きました。

今回のように稼働中のプロジェクトでLinterを入れてみたいという場合、この記事が参考になれば幸いです。

既存のコーディングルールや開発環境を踏まえて、周りと相談しながら導入を進めてみるときっとうまくいくかと思います！

P.S.

採用

虎の穴では一緒に働く仲間を募集中です！
この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧下さい。
yumenosora.co.jp

LINEスタンプ

エンジニア専用のメイドちゃんスタンプが完成しました！
「あの場面」で思わず使いたくなるようなスタンプから、日常で役立つスタンプを合計40個用意しました。
エンジニアの皆さん、エンジニアでない方もぜひスタンプを確認してみてください。 store.line.me