pw build

pw build [--debug] [--backend nethttp|fasthttp]
         [--target lambda|azure-functions|google-cloud-run-functions|vercel-go]

現在のプロジェクト状態をリリース成果物にします。target を省略すると通常のバイナリを生成します。--backend は HTTP 実装を選び、既定値は nethttp です。--target は provider packaging を選びます。

実行内容

テンプレート、SQL、ページツリー、カタログ、バインディングの呼び出し箇所をソースの隣の _pw_gen.go にコンパイルする
Tailwind が有効なら、スタイルシートを minify してビルドする。これは assets.tailwind.minify を上書きするので、リリースが誤って非 minify になることはない
アセットツリーを dist/public に構築する。プロジェクトが指定した変換を行い、*.br, *.zstd, *.gz サイドカーを書き、キャッシュヘッダを決めるマニフェストを出力する
project.main が開発専用パッケージに依存していればビルドを拒否する
popcornweb.toml の project.main に対して go build を実行する

手順 1 から 4 はそのまま pw generate です。このコマンドは「それ＋コンパイラ」として定義されているので、内容も順序もずれることがありません。

バイナリは main パッケージ名でプロジェクトルートに置かれます。スキャフォールドされた .gitignore はこれと、dist/ 配下すべてを除外済みです。ビルド済みツリーも変換キャッシュもマニフェストも、すべてビルド成果物です。

--target を指定した場合は .pw/build/<target>/<backend>/ に生成します。Lambda と Azure Functions は Linux binary と provider metadata、Google Cloud Run functions と Vercel Go はローカル compile 済みの vendored source tree です。各成果物の契約はサーバーレスホスティングを参照してください。

現時点で開発専用パッケージは contrib/devidp だけです。これは pw dev が使う認証プロバイダで、パスワードを検証せずにユーザーをログインさせます。この動作が配布用バイナリにリンクされるのは本番設定ではなくビルドの欠陥なので、pw build は import しているパッケージ名を示して停止します。

デバッグ用の成果物

pw build --debug

--debug は、配布用の成果物が本来落とすデバッグ情報を残します。スクリプトビルドが出すソースマップと、-ldflags=-s -w が削る DWARF・シンボルテーブルです。それ以外は変わりません。

使いどころは、複数人でデバッグする共有テスト環境や CD 環境です。staging には使わないでください。staging は本番のリハーサルのために存在するので、本番と違う成果物では何のリハーサルにもなりません。

付けない場合、マップは出力されず、バンドルの sourceMappingURL コメントも書かれません。ツリーに無いマップを名指すバンドルは、devtools を開くたびに存在しないファイルへのリクエストを生むからです。ハッシュ付きのバンドル名は両者で同じなので、ページが読み込む URL はどちらで作ったかに依存しません。panic のスタックが関数名と行番号を保つのも両方同じです。pw build は pclntab をどちらでも残します。

--debug は pw dev のものを何も戻しません。エラーオーバーレイ、ランチャー、開発用認証プロバイダは、どちらの形の pw build 成果物にも入っていませんし、上の手順 4 はそれらを import したビルドを拒否し続けます。

実行する

APP_ENV=prod ./myapp

APP_ENV がどのプロジェクトローカル設定ファイルを読むかを選びます。アプリケーション設定を参照。

クロスコンパイルと TinyGo

pw build は go build を呼び出すだけなので、通常の環境変数がそのまま使えます。

GOOS=linux GOARCH=amd64 pw build

生成コードの経路は実行時リフレクションを使わないため、同じソースで TinyGo もターゲットにできます。pw build は必ずホストの go でリンクするので、TinyGo のビルドは生成を走らせてからそのコンパイラを自分で呼びます。

pw generate
tinygo build -scheduler=threads -o myapp ./cmd/myapp

pw generate はこのコマンドから最後の手順を引いたものです。コンパイラが必要とするツリーを一式残し、public.go が go:embed で名指ししている dist/public もそこに含まれます。ここで --code-only を付けて狭めないでください。そのフラグが書くのは生成 Go だけで、一度も作られなかったディレクトリでコンパイラが失敗します。

-scheduler=threads はネットワークプロトコルを話すエンジンには必須です。協調型スケジューラの下ではブロッキングなソケット呼び出しがランタイム全体を掴み、ドライバのキャンセル監視が動かないため、クエリはコンテキストのデッドラインを越えても何も報告しません。database/postgres と database/mysql は、実行時にそうなるかわりに、このフラグが無ければコンパイルを拒否します。

pw init が書く 2 つの Dockerfile は、この両方のコマンドを使います。コンテナイメージを参照してください。

TinyGo の net パッケージは独自のネットワーク実装を持たず、すべてのソケットがプログラムの登録した Netdever を経由します。TinyGo サポートを有効にして作成したプロジェクトには、その登録を行う tinygohelper.go がルートに置かれます。

//go:build tinygo

package publicassets

import _ "github.com/shibukawa/tinygodriver/netdev"

//go:build tinygo により、ホストの Go ビルドではこのファイルは無視されます。これがないと TinyGo のビルド自体は成功しますが、起動直後に終了します。

2026/01/01 00:00:00 Netdev not set

このファイルが付くのは --tinygo、またはウィザードで TinyGo を選んで作成したプロジェクトだけで、既定では付きません。TinyGo に切り替えるときは手動で追加してください。

CI での使い方

ビルド前に、生成コードが最新であることを検証します。

pw check
pw build