Next.js を用いる際、
npx next
コマンドを用いると、ソースファイルの編集が開いているページに自動で反映されるサーバーを起動できる。
一見便利そうなこのコマンドだが、以下のような罠があるため、筆者は使わないことをオススメする。
npx next の問題点
ビルドエラーが検出されない
npx next build コマンドによるビルドを行うと、(デフォルトでは) 以下のエラーがチェックされ、エラーがあればビルドが中止される。
- ESLint が検出するエラー
- TypeScript が検出するエラー
Suspenseの外でuseSearchParamsを使っているエラー
しかし、npx next で動かす場合は、これらのエラーが検出されず、不適切だったり不適切とみなされたりするコードでも動いてしまう。
そのため、エラーに気付けずに不適切なコードを書き進めてしまい、後でビルドを行って初めて大量のエラーに直面し、修正に一気に長時間取られる、という可能性がある。(あった)
自動更新時おかしくなることがある
npx next の長所である自動更新だが、それによりおかしな動作が発生することがある。
具体的には、以下の事象が発生することがある。(あった)
- 設定しているはずのスタイルシートが利かなくなる
- React の依存配列の修正時、要素数が変わったとして怒られる
スタイルシートはリロードすると直るので自動更新の問題だろうことがわかるし、余計な怒られが発生するのは気分がいいものではない。
最初のページ遷移が遅い
npx next では、サーバーの起動時ではなく各ページを最初に開いたときにコンパイルが走るため、新しいページを開くたびに数秒～十数秒程度待たされ、快適な動作確認の支障となる。
プログラムを書いている途中でも自動更新される
npx next ではソースコードを更新するたびに自動更新が走るため、プログラムを書いている途中でとりあえず保存したときや、(読み込まれるコードと読み込むコードなど) 複数のファイルにまたがる変更をする際に最初のファイルを保存したときなど、書いている途中の中途半端なプログラムを読み込まれ、無駄なエラーが発生することがある。
動作確認することを全く意図しておらず、エラーになることがわかりきっている書いている途中のプログラムを勝手に無駄に処理され、無駄にエラーを出されるのは、不快である。
ではどうするべきか
明示的にビルドを行って実行する
npx next には、これまで述べてきたような様々な問題がある。
そこで、筆者は
npx next build && npx next start
コマンドでサーバーを実行することをオススメする。
これはまず npx next build コマンドでビルドを行い、npx next start コマンドでビルドしたプログラムを実行するコマンドである。
このコマンドを用いることには、以下のような利点がある。
- 1個のコマンドで実行できるので、シェルの補完を活用し、少ない手間で実行できる
- ソースコードのチェックを行い、エラーや警告があれば出力してくれる
- サーバーが起動したら、快適にページ遷移を行うことができる
- コマンドの実行時にしかビルドしないので、中途半端なソースコードを勝手に処理されない
ブラウザの開発者ツールを使う
スタイルシートや文言などのデザインの微調整を行うには、npx next の自動更新は一見便利そうかもしれない。
しかし、スタイルシートなどの調整はブラウザの開発者ツールでもできる。
開発者ツールで調整を行い、いい感じになったら調整をソースコードに反映して再実行すればよい。
npx next では調整をしてから画面に反映されるまでに数秒かかる一方、開発者ツールであればすぐに反映されるのも利点である。
エラーを溜め込んでしまったら
npx next のみで開発を進め、不適切なコードを溜め込んでしまった際は、回復のため以下のテクニックが役に立つことがある。
TypeScript が検出するエラーを一気に出してもらう
npx next build を実行した際、ESLint が検出するエラーや警告は出せるだけ出してくれる一方、TypeScript が検出するエラーはなぜか一回の実行で1個しか出してくれない。
そのため、出たエラーを修正して npx next build を再実行し、また1個だけ出してくれたエラーを修正し……としていくと、短くない時間がかかる npx next build を何度も実行する羽目になり、大量の時間を取られてしまう。
npx tsc --noEmit
コマンドを用いることで、エラーを1個ずつではなく出せるだけ出してもらうことができ、修正の効率を上げることができる。
これにより、エラーの一覧性が上がるために修正の効率が上がるだけでなく、エラーの総量がわかるため精神の負担も軽減される。
ビルドエラーを一時しのぎする
ビルドエラーが発生した場合は、内容を考えてコードを適切に修正するべきである。
しかし、溜め込んだ大量のビルドエラーを抱え、短時間でとにかく一旦動かしたい場合などには、エラーをとりあえず回避してビルドを進めるという選択肢もある。
ここで紹介する方法はあくまで短時間でとにかく一旦エラーを回避して動かしたい場合用のものであり、後で適切な方法でエラーの修正を行うべきである。
ESLint が検出するエラーをしのぐ
next.config.js ファイルで以下の設定をすることで、ビルド時の ESLint によるチェックをスキップすることができる。
eslint: {
ignoreDuringBuilds: true,
},
next.config.js: eslint | Next.js
TypeScript が検出するエラーをしのぐ
next.config.js ファイルで以下の設定をすることで、ビルド時の TypeScript によるチェックをスキップすることができる。
typescript: {
ignoreBuildErrors: true,
},
next.config.js: typescript | Next.js
useSearchParams のエラーをしのぐ
Next.js 14 ではチェックを無視する設定があるが、Next.js 15 では設定での回避はできなそうである。
Missing Suspense boundary with useSearchParams | Next.js
useSearchParams() を使っているコンポーネントを <Suspense> で囲むことで、このエラーを回避できる。
本来は <Suspense> の役割
今後の React ではどの範囲を Suspense で囲むかという設計が重要になってくる
を考え、適切な場所に配置するべきだろう。
しかし、一時しのぎのためには、トップレベルの layout.tsx で body の中身全体を <Suspense> で囲んでしまえばよい。
<Suspense> は、'use client'; を書いていなくても使用できるようなので、import を合わせて3行足すだけである。
まとめ
npx next
コマンドを用いると、ビルドエラーが検出されないため不適切なコードを溜め込む原因となり、その他の問題点もあるため、使わないほうがよい。
npx next build && npx next start
コマンドでビルドを行い、サーバーを起動するのがよい。
不適切なコードを溜め込んでしまった際、
npx tsc --noEmit
コマンドを用いると、npx next ではなぜか1個ずつしか出してくれない TypeScript が検出するエラーを一気に出してもらい、修正の効率を上げることができる。