🐳【学習ログ】なぜDocker環境があるのに「npm run build」をホストで実行するのか
問題意識
最近のプロジェクトにおいて、Dockerベースの開発環境が整備されているにもかかわらず、フロントエンドのビルド処理をホストマシン上で直接実行しているケースにたびたび直面した。具体的には、CursorやClaudeといったAIコーディングアシスタントの提案をそのまま受け入れた結果として、npm run build をホスト側で実行するという流れが自然に定着している場面がある。
フロントエンドエンジニアではない自分にとって、この選択がなぜ合理的なのか、また、そもそも「npm run build」がどのような意味を持つのかを明確に理解する必要があると感じ、今回調査を行った。
npm run buildとは？
「npm run build」というコマンドは、Node.jsやnpm自体が標準で提供するビルド機能を呼び出すものではない。正確には、プロジェクトのルートに配置されている package.json ファイル内の scripts セクションに定義された "build" の内容を実行する、という仕組みである。
したがって、このコマンドが何をするのかはプロジェクトごとに異なり、一義的に定まるものではない。
たとえばReactやVue、Next.jsといったフレームワークでは、開発用に書かれたTypeScriptやJSX、SCSSといったコードを本番環境向けに変換・圧縮する処理が定義されていることが多い。この処理を通じて、dist/ や .next/ といったディレクトリに成果物が生成される。これらは、静的サーバーやNode.jsベースのアプリケーションでそのまま配信されることを前提としており、ビルド済みのファイル群こそが最終的なプロダクトとなる。
結論
ホストマシンでビルドを実行するという選択は、AIアシスタントとの連携やホットリロードとの相性、ローカルのファイルシステムに対するアクセス効率など、実用的な観点から合理性を持っている。
Docker環境内でのビルドは本番デプロイの整合性を保つために重要である一方、日常の開発においてはホスト側での柔軟な実行がむしろ効率的であるというのが実態のようだ。
今回の調査を通じて、「npm run build」はあくまでプロジェクトが定義した処理の呼び出しにすぎず、その内容を把握するには package.json を直接確認することが不可欠であるという、基本的かつ重要な理解を得ることができた。
Discussion