目次
27の最初のAlphaは、公式リリースの記録では2026年10月29日18時36分、日本時間の10月30日3時36分に公開されました。Node.js 27からは、毎年一つのメジャー系列がCurrentへ進み、奇数・偶数にかかわらずLTSへ移行する計画です。ライブラリーを配布するチームやNode.jsでサービスを運用するチームは、既存のLTSを使う本番経路を保ちながら、次の系列との互換性を早い段階で確かめられます。この記事は11月6日時点で確認した公式資料を基にした導入判断の解説です。 Node.js公式リポジトリの27 Alphaリリースノート
スポンサーリンク
Node.js 27を評価する時期と採用する時期を分ける
Release Working Groupの表では、27.xはAlphaで、Currentへの移行は2027年4月22日、LTSへの移行は同年10月20日の予定です。表にあるAlpha開始日と、個別の配布物が公開された時刻は別の情報です。今後の予定は更新され得るため、チームの更新計画には参照日を添え、実際に移行する前に改めて公式表を確認します。 Node.js Release Working Groupのスケジュール表
旧方式では、偶数系列をLTSとして選び、奇数系列を早期評価に使う判断ができました。27以降は系列の数字だけでサポート段階を判断できません。新方式では10月に次の系列を分岐してAlphaを配布し、翌年4月に最初の正式なメジャー版をCurrentとして出す流れです。その約半年後にLTSへ進みます。Node.js 26以前の系列には従来の方針が適用されるため、移行表に旧方式と新方式の行が同時に現れます。 Node.js公式のリリース方針変更案内
公式表では、26.xは2026年10月28日にActive LTSへ移行し、2027年10月にMaintenanceへ入る予定です。27以降の系列はLTSの30か月をActive LTSとして扱う計画で、26以前のような独立したMaintenance段階がありません。いずれも系列の予定であり、特定のコンテナーイメージ、の、依存が同じ日に対応することまでは示しません。自社の更新判断ではそれぞれの提供状況を別に確認します。
本番の検証とAlphaの試験に別々の役割を持たせる
公式の説明では、Alphaは署名・タグ付けされ、主要なパッケージを使うCITGMの検査を経ます。メインから自動生成されるNightlyとは配布工程が異なります。Alpha間ではやABIが変わり得るため、同じ27系列の次のAlphaでも前回の結果をそのまま引き継げません。ライブラリー作者が変更を早期に見つけ、再現を報告する用途が中心です。 Node.js公式のリリース方針変更案内
は、現在サポートしている系列の必須ジョブと、Alphaを使う別ジョブに分けます。例えば26.xで運用するWeb APIなら、26.x側で型検査、ユニットテスト、起動確認を必須にし、27側で依存の導入と既存テストを試します。公開パッケージの場合は、現在サポートを表明している他の系列も必須側で維持します。Alphaジョブが通ったことだけを根拠に、対応版の表記や公開する成果物の生成環境を切り替える必要はありません。
Alphaの失敗をの必須条件から外す場合も、失敗の記録と調査の担当は残します。例えば定期ジョブの結果を確認する担当を決め、再現を確認したら、アプリのコード、依存パッケージ、実行環境のどこで起きたかを分類します。逆に本番用ジョブの失敗まで許容すると、通常のリリースに必要な検査が弱くなります。二つの結果を同じ成功表示へまとめず、どの版でどの検査が通ったか読めるようにします。
スポンサーリンク
取得した実行ファイルの版をCIの入口で確かめる
試験用の実行環境には、公式の配布物から対象のOSとCPUに合うものを選びます。配布ページの検証情報に従い、取得したファイルを確認してから使います。以下は、確認済みの実行ファイルをPATHの先頭に置いた後に実行する未実行例です。ここではとを使い、テスト用コマンドをpackage.jsonに定義しているを想定しています。配布物の導入方法は実行基盤に合わせて用意します。
set -eu
expected='v27.0.0-alpha.0.0.0'
actual="$(node --version)"
if [ "$actual" != "$expected" ]; then
printf 'Expected %s, got %s\n' "$expected" "$actual" >&2
exit 1
fi
node -p 'JSON.stringify({
node: process.version,
v8: process.versions.v8,
modules: process.versions.modules,
platform: process.platform,
arch: process.arch
})'
npm --version
npm ci
npm testこの確認を先に置くと、設定上はAlphaを選んでいるのに、シェルが既存のLTSを見つけて検査が成功する状況を見つけられます。版の確認に失敗したジョブは、アプリの互換性が不明な環境構築エラーとして扱います。ランタイムの版、OS、CPU、、ロックファイルを記録すると、同じ条件で再現できます。別のパッケージマネージャーを使う場合は、そのプロジェクトの固定済みの導入手順へ置き換えます。
最初に比較する二つのジョブでは、アプリのコミットとロックファイルをそろえます。Alphaで依存の導入に失敗したからといって、その場で全パッケージを更新すると、何が解決したか分からなくなります。依存の導入だけで失敗するなら、パッケージマネージャー、エンジン要件、インストールスクリプトの段階を分けて調べます。導入は成功するが起動で落ちるなら、読み込みの入口と最初の例外を採取します。
ネイティブ依存と保存データは別に検査する
ネイティブアドオンを含むプロジェクトでは、JavaScriptのテストが始まる前に、バイナリーの入手やで止まる場合があります。Alphaでパッケージが導入できた場合でも、アプリが使う経路でその依存を実際に読み込む試験を入れます。画像変換ならサンプルの画像を一枚処理し、圧縮やDB接続のアドオンなら、テスト用の入力・接続先で最小の操作を通します。以前のジョブが作ったnode_modulesを流用すると、対象の版で導入できるかを確かめられません。
の切り分けでは、ダウンロード済みのパッケージと、インストール後のバイナリーや実行時の生成物を区別します。まずキャッシュの影響を外した導入で再現を確認し、必要なら、OS・CPU・ランタイムの版・ロックファイルが異なるジョブでインストール済みの成果物を共有しない構成にします。コンテナー運用なら、本番のに近い環境での試験も別に用意し、開発端末の成功をそのまま配備先の結果にしません。
最初の27 Alphaのリリースノートには、V8の更新に伴うシリアライズ形式の変更と、古いNode.jsから新しい形式を読み取れないことが記載されています。アプリがv8.serializeの出力をファイルやキャッシュに保存しているなら、検証用の保存先を本番から分離し、テストデータで旧版と新版の読み書きを双方向に試します。実行ファイルを戻した後も新しい形式のデータが残り得るため、復旧試験ではランタイムとデータの両方を対象にします。この変更は確認したAlphaの内容として扱い、将来のCurrentやLTSの挙動は配布時点で再確認します。 Node.js公式リポジトリの27 Alphaリリースノート
例えばキャッシュを空にして再生成できるなら、検証用のキーに系列を含め、切り戻し時は旧版の領域へ戻す案があります。永続データなら、読み書きの互換性を先に測り、必要な場合は移行前のスナップショットからの復元も試します。旧版で読めないデータを新版が書き始める時点を、配備計画の確認項目に入れます。
スポンサーリンク
失敗を修正できる単位で残す
既存テストでAlphaだけが失敗したら、まず同じ入力で再現するかを確かめます。ユニットテストの失敗、起動直後の例外、実行中のクラッシュは調査に必要な情報が異なります。例えば依存のロードで止まる場合は読み込むファイルを最小化し、業務ロジックを外しても再現するか調べます。保存データが関係する場合は、どの版で書き、どの版で読むと失敗したかを記録します。
互換性の報告には、再現コード、期待する結果、実際の結果、比較に使ったLTSとAlphaの版を添えます。依存ライブラリーを含む場合は、その依存を外すと再現しなくなるかも記録します。顧客データや本番のを添付する必要はありません。公開の報告には、同じ失敗を起こせる小さな入力を用意します。次のAlphaで結果が変わった場合も、どの配布物で変わったか分かるよう別の行で残します。
CurrentとLTSで採用判定をやり直す
Alphaで互換性の課題を拾えたら、Currentが出た段階で同じ試験を再実行します。そこで実行基盤やコンテナーの配布、依存パッケージの対応方針を確認し、LTSに進んだ段階で本番への切り替え条件を確認します。検査にはログ出力、環境変数、外部通信、異常終了からの再起動など、ユニットテストだけでは見えない経路も含めます。LTSの予定日と自社の配備日は別々に管理すれば、検証が終わっていない段階で予定に合わせて更新を急ぐ必要がなくなります。
判断表には、実行する場所、許容するランタイム、必須の試験、失敗時の担当、切り戻し時に戻すデータを記録します。例えば配備先が26.xでも、開発ツールだけ別の系列で動いていれば、どの処理がどちらを使うかを書き分けます。27のAlphaを追加する目的は、将来の変更を再現できる時期を早めることです。運用中のLTSを更新する判断は、公式の提供段階と、自分たちの配備先で確認した結果に基づいて行います。
関連記事
Node.js 26でAlpine x64を採用する条件では、Node.jsのサポート段階とコンテナーイメージの提供条件を分けて確認する方法を扱っています。
参考資料
Node.js公式リポジトリの27 Alphaリリースノート
Node.js Release Working Groupのスケジュール表
Node.js公式のリリース方針変更案内
