Node.js 26.12.0、WebAssembly 欠如で throw、http に websocketMask()
Node.js 26.12.0 の SEMVER-MINOR 2件と permission フラグの子プロセス伝播を確認。WebAssembly 無効構成や permission model 利用時の更新前チェックを整理する。
Node.js 26.12.0、
Node.js 26.12.0（Current、2026年10月14日公開）の Notable Changes に載っているのは SEMVER-MINOR の2件だけだ。WebAssembly または RX サポートが欠けている場合に throw する変更（#66533）と、http モジュールへの websocketMask() と websocketUnmask() の追加（#66335）である。WebAssembly を無効にした環境で起動が止まるかについて、リリースノートから言えるのは「欠けていれば throw する」までだ。起動時に投げるのか、どこかの API を呼んだ時点で投げるのかは、コミットの題名に書かれていない。
一つ前の 26.11.1（2026年10月7日）は、ドキュメントビルドまわりの revert 3件だけのリリースだった。26.11 系から上げる場合、ランタイムの差分は実質 26.12.0 の commit 一覧に集まっている。26.11.0 の sqlite の改名は Node.js 26.11.0 の記事 で扱った。
WebAssembly を外したビルドで先に試すこと
#66533 のスコープは doc,lib,src で、ドキュメント、JavaScript 側のライブラリ、C++ 側のソースの3か所に手が入っている。挙動の変化を伴う変更なので SEMVER-MINOR に分類されたと読めるが、題名の「RX」が何を指すかはリリースノートで説明されていない。
自前ビルドで WebAssembly を外している、あるいは実行環境の制約で WebAssembly が使えない構成を持つチームは、本番に入れる前にその構成のまま node を起動し、実際にコードを走らせて throw が出ないかを見ておくのが確実だ。どの条件で投げるかが分からない以上、起動するだけで終わらせず、普段のテストまで流したい。
同じ日に出た LTS の 24.22.0 では、Notable Changes にこの throw の変更は載っていない。24.22.0 の commit 一覧には build,src : gate jspi flag on V8_ENABLE_WEBASSEMBLY（#66082）がある。WebAssembly を外したビルドの扱いは LTS 側でも別の形で調整されていることになる。24.22.0 の主な追加は 24.22.0 の記事 にある。
websocketMask() と websocketUnmask() で分かっていること
http に追加された2つの関数は、名前からは WebSocket フレームのマスク処理を担うものと読める。ただし、これは名前からの推測だ。引数、戻り値、どのオブジェクトから呼ぶのかはリリースノートに載っていないので、ここでは呼び出し例を示さない。使うなら v26.12.0 の API ドキュメントで署名を確かめてからになる。
Notable に載らない変更で、動作に効きそうなもの
commit 一覧には、Notable Changes に挙がっていないが既存コードの動きに触れうる変更が混ざっている。題名から読める範囲を表にした。
| 領域 | コミット | 題名から読める変化 |
|---|---|---|
| child_process | #66559 | config file の permission フラグを子プロセスへ伝播 |
| src | #66431 | config file を stable に、config file の扱いを修正 |
| lib / permission | #66554, #66556 | --allow-fs-vfs を利用可能フラグに追加。上位ディレクトリの許可を外しても明示的な fs 許可は残す |
| crypto | #66413, #66411, #66312 | キーの export・検証・KEM・RSA-OAEP まわりのロック削除、root cert store を Environment ごとに保持、一部の Web Crypto 警告を削除 |
| module | #62530 | ほとんどの ES modules を同期的にロード |
| sqlite | #66521, #66404 | 長すぎる文字列で abort せず throw、enableDefensive() が reopen 後も持続。同梱 sqlite は 3.54.0 |
| watch | #66365 | watch フラグのアンダースコア形の別名を除去 |
| node:bench | #66534, #66536 | run() 失敗時に exit code を設定、warmup の既定を10回に |
出典：Node.js 26.12.0 (Current) リリースノートの Commits 一覧
いちばん運用に響きそうなのは #66559 だ。題名が「伝播させる」なので、これまで config file に書いた permission フラグは子プロセスに伝わっていなかったと読める。そうだとすると、permission model を config file で有効にしたまま child_process で子を起こしているアプリでは、子プロセスが今回から同じ制限の下で動き、以前は通っていたファイルアクセスで止まる可能性がある。これは題名からの推測で、伝播の範囲はリリースノートに書かれていない。
watch の変更も小さいが壊れ方がはっきりしている。どのフラグが対象かは題名に出てこないが、アンダースコアを含む別名で --watch 系のフラグを書いている npm scripts があれば、正式名に直しておくのが安全だ。crypto のロック削除はどれも内部実装の題名で、公開 API が変わるとは書かれていない。
26.12.0 に上げる前の確認順
- WebAssembly を外したビルドや、それに近い制約のある環境があるか洗い出し、その構成で起動とテストを流す
- config file で permission フラグを指定し、かつ子プロセスを起こしているコードがあれば、子プロセス側の権限エラーを確認する
package.jsonの scripts や CI で、watch フラグをアンダースコア形で書いていないか探す- ES modules の読み込み順に依存する初期化コードや、sqlite で長大な文字列を扱う処理があれば、テストを一通り流す
4の module の同期ロードは、題名に「most」とあり対象範囲が限られている。影響が出るかは手元のテストで見るしかない。