memorandum

複数のプロジェクトを頻繁に行き来して作業する場合。
VSCode であれば vscode-ghq を使って切り替えるだけで事足りるのだが、terminal の作業が必要な場合に VSCode の terminal ではなく iTerm2 などの terminal で作業したいと思う。
VSCode と似たことをやりたいのだが、VSCode での場合と違って以下のような操作をしていた。

1. (記憶で)既存のwindowに該当リポジトリがないか探す
2. すでに開いていればそこに移動
3. なければ prefix + c で window 作成し ghq で移動

これを以下のように 1 コマンドでできるようにする方法を説明する。

1. 任意の window から ghq でリポジトリの一覧を表示する
2. 選択したリポジトリにいる window を探す
3. すでに開いている window があればその window に移動する
4. すでに開いている window がなければ新しく window を作成して移動し、そのリポジトリに移動する

Lighthouse の監査項目に Image elements have explicit width and height というものがある。
Images without dimensions で詳しく説明されているが、<img> タグに width、height 属性を設定するようにすることで CLS (Cumulative Layout Shift) を改善することができる。

ところが nuxt/content においては、画像を ![](URL) で埋め込んだ場合にこれらが自動的には設定されないようだったため、rehype の plugin として rehype-img-size を作って自動的に画像サイズを読み取り設定してくれるようにした。

nuxt/content でブログを作ってきたが、 Lighthouse (あるいは PageSpeed Insight) での計測において Performance が 80 点前後から向上させられていなかった。
TTB (Total Blocking Time) の項目が悪く、 JavaScript のロードに時間がかかっているらしいことはわかったのだが、これに対処することで Performance 100 点まで上げることができた。

GitHub Actionsを使って、pull request を中心とした開発におけるちょっとした自動化ができないかと探っている。
人の出入りが多い、あるいはたまにしか触らない人が多いようなリポジトリにおいては、開発ワークフローのようなものを丁寧にドキュメント化したとしても、読み込んで守ってもらうのは難しいと思っている。
自然に開発を進めていくだけで次のアクションを示してくれる、もしくは強制させられる、という方が効果があるだろう。

そのような考えのもと、pull request が approve されてマージできる状態になったというタイミングで GitHub Actions を使ってコメントをすることを試してみた。
このコメントで、マージする前もしくはマージした後にやってほしいことを知らせることができる。
以下のように、approve されると bot がコメントを返すイメージ。

ブログをnuxt/contentに移行 - 2. descriptionの自動生成 の続き。
やっと過去の投稿を移行して Blogger のような一覧表示ができたので PageSpeed Insight でパフォーマンスをチェックしたところ、なんと33点。
トップページでの各記事の一覧/前半のHTMLを v-html + ClientOnly でレンダリングしているせいか、DCL (DOMContentLoaded) や LCP (Largest Contentful Paint) がすごく遅くなっている模様。
CLS (Cumulative Layout Shift) も大きく、後からコンテンツを表示しているせいでずれが起きていそうだ。

VuePress に関連する話題はないだろうかと探したが、解決策は見つからない。
上記のようなケースを含めていわゆる SSG ができるものでないと厳しそう。

その中で nuxt/content を使っている例をいくつか見かけ、ちょっと試してみたらすごく良かったので、主要な機能を検証した上で切り替えていった。

ブログをnuxt/contentに移行 - 1. 旧記事の移行 の続き。

この状態では description の frontmatter がないため、一覧上に記事の概要を表示できない。

ブログの移行と VuePress による実装で Blogger からの移行をしていた。
新しい記事をそちらで書くのには問題がなかったものの、過去の記事を移行してみると問題が出てきて、結果として VuePress から nuxt/content に変更した。
特別に frontend 周りを研究したいわけでもないのにいつまでブログを弄っているのかと自分でも思ってしまうが、ようやく移行できたので振り返ってみたい。
最終的に nuxt/content にしたものの、一覧表示の仕方にこだわらなければ Blogger から VuePress に移行するのも問題はないと思うので、VuePress へ移行した過程も含めて書いておく。

VuePress 以外に移行することを考えたとき、末尾が .html なのは微妙かなと思い、変更できるオプションがないか探してみた。

末尾の .html を削除できるか

markdown.pageSuffix というのがそれかと思ったが、これは Markdown の中に埋め込まれた URL に対しての指定のようで、ページ一覧を作る Component の中で page.path のようにパスを参照すると普通に .html という末尾になっていた。
SEO friendly URLs · Issue #78 · vuejs/vuepress という issue もあるが、進捗がない。
path.md → path.html のかわりに path/README.md → path/index.html と変換するというのがワークアラウンドのようなので、その構成に変更してみることにした。

ローカルでビルドしている限りは問題なかったのだが、 GitHub Actions でビルドして Firebase Hosting にデプロイするように変更したところ、最終更新日が現在日時になってしまったので対処した。

何が起きたか？

デプロイしたブログを確認してみると、日付がおかしいことに気づいた。
トップページにすべて同じ日付が表示されている。
ページ一覧にも手を入れていたのでそれを疑ったが、各ページを表示してみてもすべて同じ日付になっている。

ローカルでは正しく表示されているので、ビルド周りがおかしいと考えた。

プロジェクトの直下というのは、ソースコードの置かれるディレクトリがあるのはもちろんだが、. で始まるような設定ファイルなど、全体に影響するような重要なファイルが置かれることが多い。
そのため CODEOWNERS ファイルを使ってプロジェクト直下だけでもレビューを必須にできないかと考えた。

マシンユーザを使った検証

検証するには複数人のユーザが必要になるが、手動の操作では一人で検証することができない...。
GitHub では CI で使用するようなマシンユーザを作成することは許可されている。
そこで、GitHub Actions でマシンユーザが自動的に pull request を作成するようなパターンを想定して、その場合に期待するファイルが code owner の approve 必須となるかどうかを確認してみた。