upwindNext.js のデプロイ用アダプターと、それが作ったものを配信するランタイム。
アダプターはあなたの next build の中で動き、デプロイ用のバンドルを書き出します。すべてのルート、プリレンダー、静的ファイルを内容で識別し、アプリのコードを実行する Function まで含めて。ビルドはどこにも通信せず、認証情報も要りません。出てくるのは 1 つのディレクトリーで、それをアップロードするのはホスト側の仕事です。
アプリを作る
pnpm create upwindTailwind 4 入りの Next.js 16 アプリを upwind に配線した状態で書き出し、そのままインストールします。
ビルドが書き出すもの
Next.js は自身の Adapter API を通じてアダプターを呼びます。ビルド前に modifyConfig、ビルド後に onBuildComplete。デプロイに必要なものはすべて 1 つのディレクトリー .arkor/ の下に書き出されます。
bundle.json- エントリーポイント、プリレンダー、ルーティング表、ヘッダー規則、キャッシュ寿命のプロファイル。何を配信するか、そして何を Function ではなくストレージから配信できるか。
- 内容で識別される blob
- プリレンダー済みのシェルと静的ファイルを、その中身のハッシュで識別します。1 ページだけ変わったデプロイが運ぶのは 1 つの blob です。
appFunction- アプリ自身のコードを、ページ、Route Handler、キャッシュとともにバンドルしたもの。
middlewareFunction- プロジェクトの
proxy.tsを別に組み立てたもの。rewrite だけで済むリクエストがアプリを起こすことはありません。
アダプターは外部サービスと一切通信しません。バンドルを作るだけなら、どのアカウントも必要ありません。
開発中も、玄関がある
デプロイされたアプリの前にはエッジがいて、プラットフォーム自身のパスはエッジが答えます。next dev にはそのエッジがいません。upwind dev がローカルでの玄関です。ポートを持ち、自分のパスには自分で答え、それ以外のすべてをプロジェクト自身の Next.js に渡します。開発バンドラー、HMR、エラーオーバーレイは Next.js のものそのままです。
/__upwind- この実行が何であるか。各バージョン、アドレス、プロジェクトのディレクトリー、名指したアダプター。
/__upwind/health- Next.js の準備ができたら
200、起動中は503。
答えるのはアプリではなく玄関です。だからアプリがまだコンパイル中でも、そのコンパイルが失敗している最中でも答えます。
配信できるもの
アプリが何で出来ていても、1 回のビルドから 1 つのバンドル。
- App Router
- Server Components とストリーミング。プリレンダー済みのシェルをストレージから配信し、その続きを Function が再開します。
- Pages Router
- クライアントのルーターが名前で要求する
_next/dataの出力も、ビルド ID の下でそのまま。 - 画像
/_next/imageをエッジで最適化。形式とサイズはアプリの設定どおりに。proxy.ts- プロジェクトの proxy はそれ自体が 1 つの Function になり、リクエストがアプリに届く前に動きます。
- 定期実行
next.configの隣で宣言した cron をビルド時に検査し、通ったものをバンドルに載せます。- 静的エクスポート
output: exportでも同じバンドルを、サーバー側を空にして書き出します。どの文書もストレージから。- WebAssembly
- コンパイル済みモジュールは、それを読むコードの Function と一緒に運ばれます。
next/og- Open Graph 画像は、静的なルートならビルドが、そうでなければ Function が描きます。このページが共有するカードもその 1 つです。
Next.js >=16.2.0 <17
アダプターによる Next.js 自身の出力の書き換えが、この範囲のすべてのリリースと canary に対して検査されています。
1 つのリリース、1 つの世代
ここにあるパッケージのバージョンは互いに足並みを揃えて動き、1 つの署名付きタグから公開されます。プロジェクトを作るものと、それを動かすものが、つねに同じ世代です。
CLI。
upwind devはプロジェクト自身の Next.js を upwind の玄関の後ろで動かし、upwind buildはプロジェクト自身のnext buildにアダプターを名指して渡します。next buildの中で動き、バンドルを書き出し、書き出したものを配信する Function を組み立てます。デプロイされたFunctionの中身。アプリを配信するためのルーティング表、middleware、プリレンダー、キャッシュ。
他のパッケージが話す語彙。バンドルの形、キャッシュの用語、エッジと Function のあいだのプロトコル。
アプリ自身の D1、KV、R2。ローカルでもデプロイ先でも同じ書き方で読め、設定はいりません。
設定のいらない Better Auth。アプリの隣に置いた設定がそのままマウントされ、プロジェクト自身のデータベースが渡されます。開発時で、OAuth の資格情報も署名鍵もまだ設定していないあいだは、upwind 自身がプロバイダーとして応答し、リクエストは外に出ません。
pnpm create upwindと、それが書き出すアプリ。
1.0 の前
初期のソフトウェアです。使ってから気づくのではなく、先に書いておきます。
- デプロイ用バンドルは自身のバージョンを持ち、形が落ち着くまでは変わる前提です。
- 1 つ前のマイナーのための互換用の層を、どのリリースも持ちません。
- ここで誰も見たことのないビルドが、いちばん役に立つ報告です。あなたのアプリがしていて、これがまだ配信できていないこと。
ライセンス: MIT または Apache-2.0（受け取る側が選べます）