Docker+Nuxt.js環境でnpm run devで重くなって再起動しなければ動かなくなったときの対策【備忘録】

今回はDocker+Nuxt.js環境でnpm run devでしばらく時間が経つと、ソースコードの変更を行っていないのに画面をリロードしなければ動かなくなってしまった場面がありました。

上記の場合について、私の場合、どのように解決したかについて備忘録として残しておきます。

MacのDocker Desktopを使っていて、Dockerのバージョンは4.29.0です。

また、Nuxt.jsのバージョンは2.18.1となります。



Docker+Nuxt.js環境でnpm run devで重くなって再起動しなければ動かなくなったときの対策【備忘録】

結論から言うと私の場合、次のようにnuxt.config.jsでparallelとhardSourceをfalseとして、webpackのpollを1000、ignoredに/node_modules/を設定するようにしました。

parallelとは

parallelは、ビルドプロセスでBabel(JavaScriptのトランスパイラ)を複数のスレッドで実行するかどうかを制御します。
デフォルトで、複数のCPUコアを利用することでビルドの速度を向上させることができますが、プロジェクトの規模や複雑さによっては安定性の問題が発生することがあります。

trueに設定すると、Babelの処理が複数スレッドで並列に実行され、ビルド速度が向上する可能性があります。
falseに設定すると、Babelの処理がシングルスレッドで実行されます。並列処理に関わる不具合や安定性の問題を回避できる場合があります。

使用場面: ビルドが不安定になっている場合や、リソースに制約のある環境(特にDockerやCI)で、問題の切り分けとして無効化を試すことがあります。

hardSourceとは

hardSourceは、ビルドのキャッシュを有効にするための設定です。HardSourceWebpackPlugin を使用して、以前のビルド結果をキャッシュに保存し、次回のビルド時にそのキャッシュを利用することでビルド時間を短縮します。

trueに設定すると、Webpackのキャッシュ機能が有効になり、ビルドが速くなることがあります。
falseに設定すると、このキャッシュ機能を無効にします。HardSourceWebpackPluginはキャッシュの整合性問題を引き起こすことがあり、特に長時間の開発セッションや複雑なビルド環境ではビルドエラーやパフォーマンスの低下を招くことがあります。

使用場面: キャッシュに起因する問題が疑われる場合、またはビルドの安定性を重視する場合に無効化することが推奨されます。

終わりに

今回はDocker+Nuxt.js環境でnpm run devでしばらく時間が経つと、ソースコードの変更を行っていないのに画面をリロードしなければ動かなくなってしまった場面を私がどのように解決したかについてご紹介いたしました。

最後までお読みいただきありがとうございます。
よろしければブログやTwitterでのシェアをお願いしております。
コメントもお待ちしております。
誤植や勘違いなどございましたらコメント欄にて教えていただけると幸いです。

直接契約ができるフリーランスエージェント「エンハンス」を立ち上げました。
詳しくは下記LPをご参照ください。
https://enhance.decryption.co.jp/

Youtubeチャンネル開設いたしました。
チャンネル登録者10,000人を目指しているので、良いと思った方はチャンネル登録をお願いしたいです。
https://www.youtube.com/channel/UC219XhmSRxmXltTy6COxSMw






Docker

Posted by ちこ