Node.js 26 が LTS に：アップグレードの予定をプラットフォームに決めさせない

NodeSource の 10 月 6 日の週報が Node.js 26 の LTS 入りを伝え、翌 10 月 7 日に 26.11.0 が公開、26.11.1 も続いて利用可能になりました。同じ週報にもっと重要な一文があります。Node.js 20 のサポートは Vercel や GitHub Actions を含む各プラットフォームで消え続けているというものです。

LTS という約束は過大評価されている

LTS を「ずっと動かさなくてよい」と読む人が多くいます。そういう意味ではありません。

LTS の意味は、その系列が一定期間セキュリティ修正と重要なバグ修正を受け取るということです。保証するのはここに留まる限り取り残されないことで、ここに留まるのに何もしなくてよいことではありません。

実際の締め切りは Node 公式から来るとは限りません。プラットフォームから来ます。

• ホスティングが特定ランタイムの提供を止める
• CI イメージが旧版を落とす
• 依存ライブラリが engines の下限を上げる

これらが起きるとき、リポジトリの package.json は 1 文字も変わっていないのに、ビルドはすでに壊れています。

実際に使っている順序

おおむね次のとおりです。

1. CI に新バージョンのビルドを追加し、現行版と並行して走らせる。依存は一切変えず、赤くなるかだけを見ます。
2. 赤ければ直してからマージする。この時点で本番は旧版のままなので、リスクはゼロです。
3. 緑を確認してから engines と CI の主バージョンを切り替える。
4. 最後にローカルの開発環境を触る。

要点は 1 と 4 の順序です。CI を先に新バージョンへ動かし、自分のマシンは最後にする。逆にすると、ローカルで問題の山に当たり、どれが本物の問題でどれが環境差なのか分からなくなります。

N|Solid について

同じ週報は N|Solid Runtime 6.3.8 が最新の Node.js 22 と 24 をサポートすると述べています。この種の監視付きランタイムを使っているなら、サポート表は Node 本体より一歩遅れがちです。更新前にバージョン表を確認しないと「Node は上がったが監視が追いつかない」で詰まります。

なお NodeConf EU の振り返りが公開され、JSConf México は 10 月 28 日から 30 日に予定されています。

私の判断

原則は単純です。LTS に従うが、プラットフォームに通知されるまで待たない。

具体的には、ランタイムのバージョンを有効期限付きの依存として扱います。npm パッケージと同じように期限が来て、同じようにビルド失敗という形で知らせてくれます。違いは、依存の期限切れは普通 1 日しか猶予がないのに対し、ランタイムのバージョンは 1 年あることです。

その 1 年を更新に使わなければ、最後は消火に使うことになります。