第06章:ホットリロードの選択肢マップ🗺️🔥
この章は「ホットリロード、結局どれを選べばいいの?🤔」を最短で解決する回だよ✨ ここで“地図🗺️”を持っておくと、第7章以降(実装編)が一気にラクになる👍
1) そもそも「ホットリロード」って何?🧠💡
Node系の開発で言うホットリロードは、だいたい次の2種類に分かれるよ👇
-
A:プロセス再起動型(保存したらサーバーを再起動🔁) 例:Nodeの
--watch、nodemon、tsx watchなど → APIサーバー開発ではこれが主流✨ (Node.js) -
B:HMR型(ブラウザ側が差分更新🧩) 例:Vite/webpack等(フロント寄り) → 今回の章は “コンテナ内のNode/TSが即反映される仕組み” が主役だよ😊 (Docker Compose Watchの例にもHMRが出てくる) (Docker Documentation)
2) 方式A/B/C:ホットリロード3兄弟👪🔥
この教材アウトラインの第6章で出てきた3つを、まずは“違いが一瞬で分かる形”にするよ👇
方式A:マウント + アプリ側watch 📂👀(王道)
イメージ:ソースはPC側で編集 → コンテナにそのまま見せる(マウント)→ Node側が監視して再起動🔁
- 👍 最初に試すならだいたいコレ
- 👍 Composeの設定がシンプルになりがち
- ⚠️ Windowsだと置き場所次第で「遅い/監視が不安定」になりやすい(後で対策するやつ)💣
方式B:Compose Watch(同期/再ビルド) 🔄🧰(“Windowsでも気持ちいい”寄り)
イメージ:ファイルを“マウントで共有”じゃなくて、ルールに従ってコンテナへ同期する📦✨ 変更内容に応じて sync / sync+restart / rebuild を使い分けるのが強い💪
- 👍 node_modulesを同期しないとか、粒度を細かくできる(速い&事故りにくい) (Docker Documentation)
- 👍
package.json変更時だけrebuild、普段はsync…みたいに賢くできる🧠 (Docker Documentation) - ⚠️ Docker Compose 2.22.0以降が必要だよ(古いと使えない) (Docker Documentation)
方式C:そもそもビルド不要(軽い構成) 🪶⚡
イメージ:TypeScriptの“開発中だけ”は、TSをそのまま実行してwatchして回転数を上げる🚀
代表が tsx watch(人気者)✨
- 👍
tsx watchは依存ファイルも追いかけて再実行してくれる(便利) (tsx) - 👍 設定少なめで気持ちよく回りやすい😊
- ⚠️ 本番は別(開発専用の走り方、と割り切るのがコツ)🧊
3) じゃあどれを選ぶ? “3分で決める”選択チャート⏱️🗺️
迷ったらこの順でOK👇(まずは勝ち筋から入る✨)
✅ まずは方式Aを試す(最短で体験)🏁
- 「保存→反映」をすぐ体験したい😊
- 設定を増やしたくない🙅♂️ → 方式A
✅ Windowsでファイルが多い/重い/監視が怪しいなら方式Bへ🛠️
- 反映が遅い🐢
- 監視がたまに効かない😇
- node_modulesが絡むと地獄を見る予感しかしない🔥 → 方式B(Compose Watch) が刺さりやすい (Docker Documentation)
✅ TypeScriptの待ち時間がイヤなら方式Cを検討⚡
tsc→nodeの二段構えで待ちたくない😵- 開発中はとにかく回転数を上げたい🚀 → 方式C(tsx watch) が超ラク (tsx)
4) “方式ごとの最小サンプル”を先に見て安心する👀✨
ここでは「こんな感じになるんだ〜」を掴めればOK!(第7章以降でガッツリやるよ💪)
方式A:マウント + watch(例)
- Compose:
.:/appみたいにソースをマウント📂 - 実行:Nodeの
--watch、またはnodemon/tsx watchを使う
Nodeの--watchは「監視して変更があったら再起動」っていう公式の挙動だよ🔁 (Node.js)
services:
api:
build: .
volumes:
- .:/app
working_dir: /app
command: npm run dev
{
"scripts": {
"dev": "node --watch dist/index.js"
}
}
--watchの説明はNode公式CLIに載ってるよ(変更でプロセス再起動) (Node.js)
⚠️ ちなみに
--watch-pathは macOS/Windows限定 って注意点がある(コンテナ内Linuxだと使えない)ので、ここはハマりやすいポイント! (Node.js)
方式B:Compose Watch(例)
「普段はsync、依存関係が変わったらrebuild」みたいに賢く動かせる🧠✨ (Docker Documentation)
services:
api:
build: .
command: npm run dev
develop:
watch:
- action: sync
path: .
target: /app
ignore:
- node_modules/
- action: rebuild
path: package.json
起動はこんな感じ👇
docker compose up --watch
Docker公式にも「Watchはbind mountの代替じゃなくて“開発用の相棒”」って立ち位置で説明されてるよ🧩 (Docker Documentation)
方式C:tsx watch(例)
tsx watch は「依存が変わったら自動で再実行」っていうノリで使える✨ (tsx)
{
"scripts": {
"dev": "tsx watch src/index.ts"
}
}
tsx側のwatchは --include / --exclude も用意されてて、育てやすいよ🌱 (tsx)
5) Windowsあるある詰まりポイント(先に知って勝つ)🏆🧯
① 「コンテナで変更検知しない」😇
マウント越し(特に“ネットワークっぽい扱い”になる環境)だと監視が効きづらいことがある💥
その場合は、nodemon の --legacy-watch(-L) が“最後の手段”として公式に案内されてるよ🛟
(ただしポーリングなので重くなりがち⚠️) (GitHub)
② 「node_modulesを共有して爆発」💣
Docker公式も、Nodeプロジェクトで node_modulesのsyncは非推奨 寄りの説明をしてるよ(ネイティブ依存やマルチOS問題)🧨 (Docker Documentation)
→ だから方式B(Compose Watch)で ignore: node_modules/ が強い🔥
③ Docker Desktop/WSL周りの基本だけ押さえる🐳🪟
Docker DesktopのWSL2バックエンドは公式に“開発体験が良くなる”方向で整理されてる(起動や共有、リソース面など) (Docker Documentation)
そして wsl.exe -l -v でWSLの状態を確認する導線も書かれてるよ🔎 (Docker Documentation)
6) ミニ課題(第7章へ繋ぐ準備)📝✨
やることは“選ぶだけ”でOK!🥳(実装は次章で一気にやる)
-
自分のプロジェクトに対して、方式A/B/Cをそれぞれ 「採用する/しない」 で丸を付ける✅
-
採用候補を 1つに絞る(迷ったらA → ダメならB → TS待ちがつらいならC)🗺️
-
「ハマりそうポイント」を1個だけメモ🗒️
- 例:監視が効かないかも →
nodemon -Lを覚えとく、みたいに🛟 (GitHub)
- 例:監視が効かないかも →
7) AIで時短するプロンプト例🤖✨(コピペOK)
✅ 方式A(マウント + watch)を作らせる
「Composeとscriptsを最小にして」って頼むのがコツ💡
Docker ComposeでNode/TypeScriptの開発用環境を作りたいです。
- ソースはマウント
- コンテナ内でホットリロード(プロセス再起動)
- node_modulesはホストと共有しない方針
compose.yamlとpackage.jsonのscripts案を出して。差分が少ない案で。
✅ 方式B(Compose Watch)を作らせる
watchルール(sync/rebuild)まで言語化すると強い🧠
Docker Compose Watchを使って開発体験を良くしたいです。
- 通常は sync
- package.json が変わったら rebuild
- node_modules は同期しない
compose.yamlのdevelop.watch設定を提案して。理由も短く。
✅ 方式C(tsx watch)を作らせる
tsx watchで回すscriptsを出させる🚀
TypeScriptを開発中だけは tsx watch で動かしたい。
package.json scriptsの dev/test/lint に馴染む形でdevだけ提案して。
次の章でやること(予告)🎬✨
第7章では、ここで選んだ方式を**“ちゃんと動く形”に固定**していくよ🔥 「保存→反映」が気持ちよく回り始めるのはここからだね😆💪