こんにちは、フロントエンドチームです。
今週のフロントエンド定例の内容を記載します。
フロントエンド定例について、以前の記事（ランサーズのフロントエンドチームが取り組んでいること）でお伝えしたのですが、毎週金曜日に開催しており、実際の業務で取り組んでいることや気になった技術情報等をシェアしあう会になっています。
以下、今週の内容です。
@syo_igarashi
ランサーIssueとしてNodeJS 10 -> 16 対応を進め始めた
NodeJSのバージョン変更後のビルドファイルに差分がないことを検証済みだったのでIssue化し、ランサーに対応していただくようにしました。
ビルドファイルの差分検証方法が気になると思うのでここに差分検証方法を箇条書きで記載します
①NodeJSバージョンを10でビルドを実行する
②ビルド先のファイルをbeforeディレクトに移動させる
③nodenvでNodeJSバージョンを16に変更する
④NodeJSバージョンを16でビルドを実行する
⑤ビルド先のファイルをafterディレクトに移動させる
⑥Pythonライブラリとしてbeautifyをインストール（npmでもあるがNodeJSのバージョンも変更するのでPython版を選択した）
pip install jsbeautifier==1.14.0
pip install cssbeautifier==1.14.0⑦beautifyコマンド実行し、コード整形させる
js-beautify -r ./[before|after]/**/*.js
css-beautify -r ./[before|after]/**/*.css⑧diffコマンドで整形済みのファイルの差分ファイルを生成する
diff -rc before after > versions-10-16.diff上記の手順でビルドファイルの差分確認して元々テストコードがないようなフロントエンドのプロジェクトもNodeJSのバージョン更新しちゃいます。
JxckさんのCache 解体新書
https://zenn.dev/jxck/articles/cache-anatomia-release-note
先日のアプリケーションコンテナしてた際に、CDNキャッシュとは別にブラウザのキャッシュとは？と疑問に思っていたところに出てきたzennの本
Service WorkerのCache APIはクセが強い印象があって
閲覧しているサイトのServiceWorkerの登録削除とCache APIのキャッシュを全て削除するJSコード
書いてたときも以降もSNSで地味にLGTMされる記事の1つになった
現状のリビジョンハッシュつけて静的ファイルのキャッシュを意図的に変えるとかの方法もあるが、サーバ側で埋め込む必要もありそこまで対応自体にいい気がしない。
いい気がしない理由として一部の変更でしかないのに複数あるフロントエンドのリビジョンハッシュも変わるからデプロイが頻発するときとかその都度また静的ファイルを読み込むのかと思うと速度的に問題がありそうとみている。
ビルドファイルごとに異なるリビジョンハッシュを持たせるかというと既に色々なフロントエンドのリソースがあるのでそこまで対応する気にもなれないというのが正直なとこ。
リビジョンハッシュではなくファイル名ごとハッシュにするのもあるがサーバ側でハッシュのファイル名を指定しにくいのも困りものだったりする。
index.html起点にCSS, JSを固めてハッシュのファイル名を生成してctp側でビルドで生成されたindex.htmlを読み込むような形式にすればいいのかなというのは若干思ってたりしているもの。
ctpでHTML、JSを扱わないようにするというのが大事かも。
@high_g_engineer
デベロッパーツールのカバレッジ機能について
ページが読み込まれた時点で使用されていないCSS, JSを知りたい時、
以下の手順で利用可能です。
デベロッパーツール
↓
その他のツール
↓
カバレッジ
実際に、https://www.lancers.jp/mypage でカバレッジを確認しました。
↓行数が赤くなっている箇所が利用されていない箇所で、利用率等が下のエリアに表示されます。
メインとなるCSSファイル内で使用されていないCSSが98.1率（バイト数換算）
飽くまで読み込まれた時点なので、マウスオーバーの際に読み込まれたりするものは計算から外されていますが、使用している率が1.9%・・・。
oh・・・。これは改善せなばならない。。
ということが、数値として見れる訳です。非常に便利ですね。
参考
カバレッジ ツールを使用して、使用されていない JavaScript コードと CSS コードを検索する
本当に余談：Firefoxも-webkit-を解釈している
今まで、-webkit-というベンダープレフィックスは、firefoxでは一切無視されているという理解だったのですが、
現状可能なline-clampの実装を行った場合、Firefoxが明らかに-webkit-を解釈していました。
少しだけ、他の方が記載されたQiitaの記事を載せておくので、良かったら御覧ください。
次回の更新予定は、6/17（金）になります！
前回の定例内容はこちらから確認可能ですのでご興味いただければ下記のリンクから閲覧いただければと思います。