Política de Lançamento e LTS do Node.js

O Node.js é lançado em uma cadência previsível - os serviços de produção devem executar lançamentos Active ou Maintenance LTS, nunca os de curta duração Current de números ímpares.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

Quando usar isso:

• Ao escolher uma imagem base para um novo microsserviço
• Ao escrever um ADR para uma atualização LTS
• Ao auditar se alguma parte da frota ainda executa Node End-of-Life
• Ao explicar à segurança por que os lançamentos Current são bloqueados em produção

Exemplo de Trabalho

// src/health.ts - expõe o conhecimento de LTS em verificações de saúde
import { readFileSync } from 'node:fs';
 
const pkg = JSON.parse(readFileSync('package.json', 'utf8')) as {
  engines?: { node?: string };
};
 
export function healthPayload() {
  const major = Number(process.versions.node.split('.')[0]);
  const allowedMajors = [22, 24]; // Maintenance + Active LTS
 
  return {
    status: allowedMajors.includes(major) ? 'ok' : 'degraded',
    node: process.version,
    enginesPolicy: pkg.engines?.node ?? 'not set',
    ltsPolicy: major === 24 ? 'active-lts' : major === 22 ? 'maintenance-lts' : 'unsupported',
  };
}

// package.json
{
  "engines": {
    "node": ">=24.18.0 <25 || >=22.23.1 <23"
  }
}

O que isso demonstra:

• Endpoints de saúde podem sinalizar runtimes não-LTS antes dos scanners de segurança
• engines pode expressar uma janela de migração intencional (22 e 24 simultaneamente)
• A versão principal é derivada de process.versions.node, não apenas da análise da string process.version

Mergulho Profundo

Como Funciona

• Novos lançamentos principais ocorrem aproximadamente em abril e outubro. Números pares (22, 24, 26) entram em LTS; números ímpares (23, 25) não.
• Active LTS recebe recursos, correções de bugs e patches de segurança por ~18 meses após a promoção.
• Maintenance LTS recebe apenas correções críticas por mais ~12 meses, depois End-of-Life.
• Current (números ímpares) é para adotantes iniciais e autores de bibliotecas testando compatibilidade.

Linha do Tempo do Ciclo de Vida (simplificado)

Notas de TypeScript

// Matriz de CI durante a migração LTS - teste ambas as linhas suportadas
const SUPPORTED_NODE_MAJORS = [22, 24] as const;
type SupportedMajor = (typeof SUPPORTED_NODE_MAJORS)[number];
 
function assertSupportedMajor(): SupportedMajor {
  const major = Number(process.versions.node.split('.')[0]) as SupportedMajor;
  if (!SUPPORTED_NODE_MAJORS.includes(major)) {
    throw new Error(`Unsupported Node major: ${major}`);
  }
  return major;
}

Armadilhas

• Implantar node:latest ou node:current - você pode acabar em um número ímpar sem SLAs de segurança. Correção: fixe node:24.18.0-bookworm-slim.
• Permanecer em Maintenance LTS após o EOL - o EOL do Node 20 significa que não há patches de CVE. Correção: lembretes no calendário 6 meses antes do EOL.
• Pular versões LTS (20 → 24 sem testar em 22) - alterações incompatíveis se acumulam. Correção: atualize para Active LTS pelo menos um ciclo antes que sua linha atual atinja o EOL.
• Tratar semver-minor como livre de riscos - minors LTS podem depreciar APIs. Correção: execute CI em cada lançamento de patch LTS.
• Ignorar compatibilidade npm - cada LTS do Node agrupa um npm major específico. Correção: use o npm agrupado ou documente os pins do Corepack.

Alternativas

FAQs

Relacionado

• Instalação e Gerenciamento de Versão - fnm, nvm e fixação de engines
• Node.js vs Bun vs Deno - contexto ADR de runtime
• Boas Práticas Fundamentais do Node.js - checklist de aplicação de LTS
• Antes/Depois da Atualização LTS Node 20-24 - estudo de caso de migração

Versões da Stack: Esta página foi escrita para Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 e NestJS 11.