%E3%82%BF%E3%82%B0:%20#nextjs%E3%82%92%E4%BB%98%E4%B8%8E%E3%81%95%E3%82%8C%E3%81%9F%E8%A8%98%E4%BA%8B%E3%81%AE%E4%B8%80%E8%A6%A7

タグ: #nextjsの記事



ブログを自作した。欲しかったのは以下だ：



外部サービスに書くということは自らを明示的に見世物にするということにほかならない。どうせインターネットに上げれば同じ、というのは誤りで、Note やはてブの投稿はピックアップされ、サジェストされ、誰かの画面に躍り出る。これら閲覧を支援する機構（舞台装置だ！）は書き手を舞台の上に連れ出し、スポットライトの存在を嫌でも意識させる。そして本来なら触れるはずもなかった観客と向かい合わせる。

一方、個人ブログに辿り着くのはあえて勧められてもいないリンクを踏んだ人間だけだ。なんでこんなの読んでるんですか？　検索エンジンもサイトと読者を引き合わせる役割を持つが、そこには偶然性の占める割合が大きく、結果として外部サービスに書かれたものより明らかに到達コストは高くなる。

重要なのはここだ。到達コストのかかる場所に置かれるものは、公衆の目に触れるか否か不確かになる。買い物メモレベルの俗さから始まって、ただ書いておくという事実のためだけに言語化された感情、果ては延々と専門事項が書き連ねられた SSL 未対応のサイトまで、あえて演者としての露出を偶然性に委ねながら書かれたテクストには、それ自体独特の風味がある。広告資本主義のおこがましさがないのはもちろん、ある意味では読まれるために書かれたもの以上の真正性すら感じさせる。そしてこの性質は、明確な書き手として場に固定されれば消えてしまう種類のものだ。

ここで私は書き手が視線に晒されること自体を糾弾しているのではない。書き手と読み手という一方性が定式化されて提供され、{舞台装置}^(プラットフォーム)によって増幅されることで失われるものを考えている。書くことは広く伝えること、という刷り込みは極めて強力だが、必ずしも表現を拡張するものではない。読み手からしても、なげやりに打ち出された吐露、あるいは限られた対象にのみ向けられた事実をほとんど窃視のような形で目にするほうがより愉快であることも当然ある。そしてこういうものは、書き手が各人の自由なシマを持っていなければ難しいことだ。「公開されているが公開されているわけではない」このゆるやかな断絶を実現できるのは、個人ブログくらいしかないのではないかとすら思う。



われわれには先人の記憶というものがあり、すなわちこの手のサイトは記事管理が億劫になった時点でエタる。放置された「〇〇の部屋」、消えて還らない借りドメイン、むなしく刻む入室カウンターたちを眺めるたびに、せめて記事くらいは慣れたファイル形式で楽に扱いたいと思うようになった。そういうわけで Markdown（内容管理） + tsx（テンプレートエンジン）。Markdown ならそう簡単には廃れないだろうし、いつか別サービスにも投げ込める安心感がある。

Markdown の処理系には remark / rehype を選択した。unifiedの API が使えて、後述の豊富なプラグイン群が揃っているのが理由だ。その反面、同じことを実装するのにも選択肢が複数ある。たとえば今回のように Markdown から Next.js の ページを生成するだけでも、以下の五種類（以上）から選ぶことになる。



自分は柔軟にプラグインを組み合わせ、React コンポーネントとも融和させたかったため、このうち上から二番目を採った（後述するが、rehype-reactがかなり魅力的だ）。



テストとプレビューを GitHub Actions、ライブラリ更新を renovate で自動化している。これが全部無料で回るのだから本当に頭が上がらない。ホスティングは素直に Vercel に投げたが、とくに拘りはないので Cloudflare Pages あたりに変えても良いかもしれない。ちなみに Vercel 側のビルド回数を抑えるため、デフォルトのレポジトリ連携は切り、CI で念入りにテストしてから Vercel CLI 経由でのデプロイを行うようにしてある（vercel-action）。せめてもの配慮（？）だ。



パフォーマンスが良いらしいと聞いて Next.js の SSG を選択した。SSG とはいいながら、ページ遷移のたびに JS が走るので動きはなめらかだ（言い方を変えれば、ピュアではない）。画像最適化やルーティングの抽象化も向こうでやってくれる。かといって Gatsby みたいにプラグインでガチガチに固める感じでもないので、引っ張ってきたライブラリや自作の処理も素直に持ち込めるのが良いと思った。



この記事からわかるように、広告の遍在に対して個人的な憎悪を燃やしているため、このサイトには一切置いていない。あるのは Vercel が（おそらく）行っているアナリティクスだけだ。



以下では具体的に実装できた機能と、使ったライブラリを書く。



Markdown 冒頭に記事のメタデータを記載し、grey-matterで取り出している（これは unified の処理ではない）。

https://github.com/jonschlinkert/gray-matter



remark-gfmで対応。

https://github.com/remarkjs/remark-gfm



| 表を     | 作る       |
| -------- | ---------- |
| たとえば | このように |
| 要素を   | 増やす     |

https://www.haxibami.net

みたいな生のリンクも置けるし



remark-gemojiで変換。

https://github.com/remarkjs/remark-gemoji

:v:が :v: になる。



remark-mathとrehype-katexを噛ませる。

https://github.com/remarkjs/remark-math

https://github.com/remarkjs/remark-math/tree/main/packages/rehype-katex



$e^{i\pi} + 1 = 0$ のようなインライン数式もいける。

フォントの設置は必要なく、スタイルシートを読ませればよい。



remark-rubyというパッケージがルビを実装しているが、依存関係と API が古くなっていたため、ほぼフォークのような形で別パッケージ（remark-jaruby）を実装した。

https://github.com/haxibami/remark-jaruby

パーサ部分（micromark-extension-jaruby）、構文木操作部分（mdast-util-jaruby）の拡張機能に分割し、これらをremark-jarubyから参照している。



rehype-slug、rehype-autolink-headings、remark-tocで実現。

https://github.com/rehypejs/rehype-slug

https://github.com/rehypejs/rehype-autolink-headings

https://github.com/remarkjs/remark-toc

heading に slug を振ってくれるそうな。



トップの記事一覧には内容のプレビューを表示している。このために生の Markdown を流し込むのも気が引けたので、なんとかして plaintext 形式に変換できないかと考えていたら、strip-markdownというのがあった。これで\<h1>, \<blockquote>等を除去し、冒頭 200 字を抽出している。

https://github.com/remarkjs/strip-markdown



remark-mermaidは古く、remark-mermaidjsは API が unified のものではなかったため、後者をベースにしつつ手元で実装した。裏でヘッドレス Chromium を立ち上げて SVG を生成しているとは思えないほど高速だ。



最初はprism.jsを使っていたが、使えるカラースキームがあまりに少なかったためshikiに変更した。公式サイトにある通り、こちらは VSCode のカラースキームファイルが流用できる。せっかくなので自作のurara-vscodeを使用してみた。

https://github.com/shikijs/shiki



外部リンクをカードに変換するやつ。

https://zenn.dev/tomi/articles/2021-03-22-blog-card

https://zenn.dev/januswel/articles/745787422d425b01e0c1

:point\_up\_2: を参考にしつつ、unified の Transformer プラグインとして実装した。文書中のリンク（Paragraphノードかつ、子要素が単一のLinkノードであるもの）を取得し、適当な独自要素（\<extlink>）に置き換えたのち、リンク先にアクセスして得たメタ情報（title、description、OGP 画像 URL 等）を挿入している。これをrehype-reactのcomponentsオプションを使ってカスタムコンポーネントに変換することで、任意のスタイルでカードが表示できる。



メタ情報の取得には、metadata-scraperという便利なライブラリを使った。

https://github.com/BetaHuhn/metadata-scraper#readme

なお、内部でfetchを行っている都合上、作成したプラグインは非同期プラグインとなることに留意。具体的には unified でprocessSyncが使えなくなる。



Markdown で挿入した画像は通常の\<img>タグに変換されるため、そのままでは Next.js の画像最適化の対象にはならない。が、これもrehype-reactのcomponentsオプションで独自のコンポーネントに置換することで解決できる。たとえば以下のような関数コンポーネントを作れば、画像にリンクを付加し、altテキストをキャプションとして追記できる。同様のことがリンク（\<a>タグ →\<Link>）についても可能。



以上を合わせたremark-parse / remark-rehypeまわりのメソッドチェーンが下の通り。\[^2]

\[^2]: 変なファイル処理が入っているのは、shiki がテーマファイルを読み込むにあたって自分のインストールされた位置（メインプロジェクトのnode\_modules以下）からの相対パスか、ファイルシステムの絶対パスかのいずれかしか受け付けないため。



また、rehype-react関連の処理は以下のようになる。



以上で、はてブや Qiita、Zenn あたりと似た書き心地になった。



外部ライブラリを使用。

https://github.com/pacocoursey/next-themes



Vercel のサーバレス関数機能を使い、



する API を設置して実現した。表示する内容を手元で書けるぶん、他の手法と比べてデザインの自由度が高い。

Chromium バイナリにはplaywright-aws-lambdaを使った。chrome-aws-lambdaより容量が小さくバージョンも新しいため、こちらを使わない手はない。





以上でこんな :point\_up\_2: 感じのものがつくれる。



レスポンス改善を期待してフォントはローカル（/public/fonts以下）に設置した。ログを見た感じかなり容量がギリギリだが、普通に動いている。なお、ローカルフォントを読み込む際には base64 エンコードしたものを CSS に渡す必要があるため注意。Vercel 公式のog-imageあたりの実装が参考になるだろう。



next-sitemapを使ったところ、\<lastmod>がすべて最終ビルド時を示していて発狂しかけた。この挙動はある意味正しく、なぜなら自分が触れていないページでもビルドするたびに静的アセットの slug 名が変わってしまうためである。仕方がないのでこのへんを参考にしつつ書いた。npm scripts を活用し、



するようにしてある。



Feedというライブラリを使った。上と同じ要領で、ビルド時に/public/rss以下に RSS、Atom、JSON Feed 用のファイル三種を吐かせている。

https://github.com/jpmonette/feed



いい感じ〜 :sunglasses:

Next.js の抽象化と、unified はじめ充実した外部処理系に助けられてかなり簡単に動いた。デベロッパーに五体投地しつつ、改修・保守をやっていく。



なまあたたかくておいしい

なま
あたたかくて
おいしい

#nextjs

Next.jsでブログをつくった