Zenn
🔧

保守運用にNext.js App Routerは耐えられるのか疑念がある(個人的メモに近い)

2025/02/09に公開

はじめに

筆者はNext.js App Routerを用いたアプリケーション開発・継続リリースを行っている。しかし、疑念がある。
筆者がいなくなったときにNext.js App Routerの面倒を見ることは可能なのだろうか? できれば可能であって欲しい。内部向けドキュメントも多く書いてきた。しかし、不安である。そこで問題点をここに書いてみる。

壁その1 フレームワークが提供する機能の豊富さ(≒機能の隠匿)

Next.js App Routerは大体のことが初期設定されている。そのため、Reactでアプリケーション開発を行うときに通るWebpackの設定などを一目ではわからない。Next.jsで提供している機能が何で内部としては何が行われているのかを把握する必要がある。

まずは、アプリケーションで利用しているNext.jsの機能を表にするのが良さそうだ。
SuspenseやErrorboundaryについてのリンクを貼っておこう。

たとえば

Next.jsでの機能 内部実装 リンク
next.config.js Webpack https://webpack.js.org/concepts/ https://nextjs.org/docs/app/api-reference/config/next-config-js/webpack
loading.tsx Suspense https://nextjs.org/docs/app/api-reference/file-conventions/loading https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming
error.tsx Errorboundary https://nextjs.org/docs/pages/building-your-application/configuring/error-handling https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary

のような形か。

壁その2 日本語文献が少ない(原文を読めないと大変)

筆者はかろうじて英語が読める。苦手意識はないつもりだ。しかし、英語を見るやいなやGoogle翻訳でページごと翻訳してしまうのであれば、大変だろう。最近の翻訳は優秀なのでそこまでの誤訳はないが、ニュアンスを間違えると後が怖い。
GithubのIssuesやDiscussion、Stack Overflowは基本英語だし、巨人の肩に乗るには英語が必要なのだ。あいにく私は小人なので、肩に乗るスペースはない。日本語の巨人はもっと他にいらっしゃる。
情報を確認するフローをまとめておこう。

公式ドキュメントを見て機能の名前と概略を把握する⇒GithubのIssuesを検索して挙がっている問題点を確認する⇒Stack Overflowで類似の投稿がないか確認する⇒Discussionで検討されていないか確認する⇒記事サイトや個人サイトを確認する

日本語の巨人は以下。
https://zenn.dev/akfm/books/nextjs-basic-principle

壁その3 フレームワークの更新頻度、更新範囲が大きい場合がある

Next.jsは機能改善を積極的に行っている。
Next.js 15ではCacheがデフォルトでno-storeとなった。ありがたいことだ。
React 19対応も入った。しかしまだ、npmパッケージの多くはReact 19へ対応していない。アプリケーションとしてNext.jsのメジャーバージョンを上げるには制約がある。
つまり、バージョンを上げるには、文脈を知らなければならない。何が問題としてあり、この機能が追加されたのかを知ったうえで、現在のアプリケーションへの適用可否、メリット、デメリットを知る必要がある。ツラい。
パッケージの詳細を見て、現在のNext.jsバージョンでの動作、ビルドが問題ないことを確認し、バージョンアップをする。(npm auditでエイヤとすると稀に問題がある。稀なので許容しても良い)

パッケージの提供する機能と、アプリケーションでの実装内容を知らなければテストは
できない。自動化テストを作ろう。ともかく、確認ドキュメントを作ろう。しかしそのドキュメントを盲目に信用されても困る。確認・調査のやり方をまとめよう。

現在のパッケージバージョンを確認する⇒脆弱性を確認する(npm audit)⇒上げるべきバージョンを確認する⇒破壊的変更があるのか、あればアプリケーションで利用しているのか確認する⇒バージョンを上げることによる影響範囲が定まったら、バージョンを上げる⇒影響範囲の動作を確認する⇒ビルドが通るのか確認する

パッケージバージョンの上手い管理方法については今後調査したい。一括で管理するパッケージがあるそうなので。

https://zenn.dev/shichi18/articles/20230611-01-89aa40b51e2f0f

最大の壁 本当にデバッグしたいのならば、Next.jsの内部実装に踏み込む必要がある

これはどのフレームワークでも変わらないと思う。
少なくとも、処理の流れが追えれば良いのだ。きっと。おそらく。Maybe。

Next.jsのリポジトリをクローンして、あれこれと調べる。楽しいね。

https://github.com/vercel/next.js

終わりに

結局、ふんわりとしたまとめになってしまった。
結論としては、フレームワークが耐えられるか、ではなく、アプリケーションが耐えられるように開発者がドキュメントを整備しなくてはならないと考える。
もうv0で良くないか? とは思う。

Discussion

ログインするとコメントできます