Mstudio

技術ブログ

技術ブログ詳細

技術ブログ

Next.jsの「Expected clientReferenceManifest to be defined」は大体バグじゃない——.nextフォルダ削除で直った話

著者: マサシ読了時間: 6
Next.jsの「Expected clientReferenceManifest to be defined」は大体バグじゃない——.nextフォルダ削除で直った話

こんにちは、マサシです。

自分のサイトのブログ機能をいじっていたら、さっきまで普通に表示できていたページが突然真っ赤なエラー画面になりました。

コードは1文字も触っていないのに、です。

実際に出たエラー画面。「This is a bug in Next.js.」と表示されている

Invariant: Expected clientReferenceManifest to be defined. This is a bug in Next.js.

「This is a bug in Next.js.」——Next.jsのバグです、と本人が言っています。

で、これを真に受けてNext.jsのバージョンを疑い始めると、だいぶ遠回りになります。
僕の場合も、そして調べた限り世界中の報告例でも、原因の大半は自分のプロジェクトの .next フォルダの中身が壊れていることでした。

先に結論:.next を消して再起動する

急いでいる人向けに、直し方だけ先に書いておきます。

# 開発サーバーを止めてから
rm -rf .next
npm run dev

Windowsならエクスプローラーでプロジェクト直下の .next フォルダを削除してから、開発サーバーを起動し直せばOKです。

僕のケースはこれで一発で直りました。

.next削除と再起動のあと、同じページが正常に表示された状態

avatar

えっ、`.next` って消しちゃっていいんですか?なんか大事そうな名前ですけど……。
avatar

大丈夫。あそこに入っているのはビルドの中間生成物だけで、ソースコードは一切入っていないんだ。消しても次の起動時に全部作り直されるよ。

なぜ起きるのか、実際に壊して確かめてみた

「キャッシュが壊れると出る」と言われても、正直ふわっとしていますよね。

なので今回、手元の検証環境(Next.js 15.5.9・App Router)で .next の中身を意図的に壊して、どこが壊れるとこのエラーになるのか試してみました。

まず分かったのが、webpackのキャッシュ(.next/cache/webpack)が壊れただけでは、このエラーは出ないということ。

キャッシュファイルの中身をでたらめなデータに書き換えて起動してみたら、ターミナルにこんな警告が出るだけで、Next.jsは勝手にキャッシュを作り直して普通に動きました。

<w> [webpack.cache.PackFileCacheStrategy] Restoring pack failed
    from .next/cache/webpack/client-development.pack.gz:
    Error: incorrect header check

意外と丈夫なんですよね、ここは。

エラーが再現したのは、コンパイル済みページの実体ファイルと、管理表(マニフェスト)の食い違いを作ったときでした。

.next/server/app の中のコンパイル済みファイルだけを消して、管理表を残した状態でページにアクセスすると、ターミナルにはこう出ます。

⨯ Failed to generate static paths for /blog/[slug]:
[Error: Cannot find module '.../.next/server/app/blog/[slug]/page.js'
  code: 'MODULE_NOT_FOUND'

そしてブラウザには、あの「This is a bug in Next.js.」が出ました。

つまりこのエラーの正体は、「管理表にはあるはずのファイルが、実際には無い」という .next 内部の矛盾です。
Next.js本体のバグではなく、手元のビルド生成物が中途半端な状態になっているだけ。

だから丸ごと消して作り直せば直る、という理屈です。

どういうときに壊れるのか

自分の経験と報告例から、.next が中途半端な状態になりやすいのはこのあたりです。

  • コンパイルの途中で開発サーバーを強制終了した(Ctrl+C連打や、PCの強制シャットダウン)
  • ページ構成が違うブランチに git checkout で切り替えた直後
  • 同じプロジェクトで開発サーバーを2つ起動してしまった
  • Next.jsのバージョンを上げたのに、古い .next が残ったままだった
  • DropboxやOneDriveの同期対象にプロジェクトを置いていて、.next の中身を同期に触られた

最後のクラウド同期のやつは気づきにくいので、心当たりがある人はプロジェクトを同期フォルダの外に出すか、.next を同期除外にしておくのがおすすめです。

それでも直らないときの分岐

.next を消しても同じエラーが出続ける場合は、別の原因を疑います。

  • node_modules ごと入れ直す(rm -rf node_modules && npm install)。パッケージの取得が中途半端に壊れているケース
  • pages router と app router を併用しているプロジェクトは要注意。この組み合わせ特有の同系統バグがGitHubに報告されています
  • Next.jsのバージョンを確認する。ごく一部のバージョンには、この系統の実バグの報告もあります。その場合はパッチバージョンを上げると直ります
  • カスタムサーバーや特殊なmiddlewareを使っている場合は、その設定を一度外して切り分ける

ここまでやって直らなければ、そのときはじめて「本当にNext.jsのバグかも」を疑う順番でいいと思います。

まとめ

「This is a bug in Next.js.」という強い言葉に引っ張られないこと。

このエラーを見たら、まず疑うのは自分の .next フォルダです。

  • 開発サーバーを止める
  • .next を丸ごと削除する
  • 開発サーバーを起動し直す

ソースコードには一切触らないので、安心して消してください。

同じ画面の前で焦っている人の時間が、少しでも短くなればうれしいです。


※この記事はNext.js 15.5.9(App Router・webpack開発モード)で実際に再現・検証した内容です。バージョンによって挙動が変わる可能性があるので、直らない場合は公式のIssueもあわせて確認してくださいね。

今のサイトに「あと少し」を。
あなたの想いを、いっしょに形にします。

  • 💬 まずは気軽に相談から
  • 🗓 最短1週間で初稿お届け
  • 🤝 公開後もずっとサポート
Next.jsの「Expected clientReferenceManifest to be defined」は大体バグじゃない——.nextフォルダ削除で直った話 | Mstudio