Habilidad de Actualización de Node

Pasos de migración LTS y matriz de cambios importantes: una Habilidad de Agente para actualizar flotas de backend de Node.js a 24.18.0 (LTS Activo).

Qué Hace Esta Habilidad

A partir de la versión LTS actual y la disposición del repositorio, produce:

• Matriz de cambios importantes por servicio
• Lista de verificación de PRs ordenados (herramientas → CI → Docker → tiempo de ejecución)
• Comandos de verificación por etapa
• Plan de reversión con etiquetas de imagen y cronograma

Cuándo Invocarla

• Node 20 LTS se acerca al fin de su vida útil y la plataforma exige 24
• Un nuevo empleado encontró que .nvmrc dice 18 mientras Docker usa 22
• Fallos en la construcción de complementos nativos después de la actualización de la imagen base
• Monorepo necesita una actualización coordinada de múltiples servicios

Entradas

Salidas

• Tabla de cambios importantes (OpenSSL, fetch, ejecutor de pruebas, ESM)
• Secuencia de PRs con propietarios
• Actualización de la matriz de CI (node-version: [24.18.0])
• Diferencia de FROM node:24.18.0-alpine en el Dockerfile
• Lista de verificación de prueba en staging (24-48h)
• Comandos de reversión

Medidas de Seguridad

1. Actualiza las herramientas antes que el código de la aplicación: CI en verde con el nuevo Node antes de fusionar los cambios de tiempo de ejecución.
2. Nunca mezcles versiones de Node en un mismo artefacto desplegable.
3. Reconstruye los módulos nativos: elimina node_modules y regenera el archivo de bloqueo si aparecen errores de ABI.
4. Ejecuta npm audit después de la reinstalación: la resolución puede cambiar.
5. Somete a staging a una prueba de carga con tráfico de producción en sombra cuando sea posible.
6. Mantén la etiqueta Docker anterior desplegable durante 7 días.

Receta

Tarjeta de receta de referencia rápida: lista para copiar y pegar.

# Fase 1 - prueba local en LTS objetivo
fnm install 24.18.0 && fnm use 24.18.0
node -v   # v24.18.0
rm -rf node_modules
npm ci
npm run typecheck
npm test
npm run build
 
# Fase 2 - matriz de CI (extracto)
# .github/workflows/pr-checks.yml
# node-version: '24.18.0'
 
# Fase 3 - Docker
# FROM node:24.18.0-alpine
 
# Fase 4 - verificación de producción
kubectl set image deploy/orders-api orders-api=orders-api:node24-abc123
kubectl rollout status deploy/orders-api

Matriz de Cambios Importantes (20 → 24)

Ejemplo de Trabajo: Orden de PR en Monorepo

## Tren de PRs de actualización (Node 24.18.0)
 
PR1 [plataforma] - .nvmrc, engines, node-version de GitHub Actions
PR2 [docker]  - Todas las líneas FROM de Dockerfile
PR3 [service-a] - Corrige tiempos de espera de prueba expuestos en 24
PR4 [service-b] - Reconstruye sharp después de la actualización de ABI
PR5 [docs]    - CONTRIBUTING.md, runbooks
 
Prueba de carga: staging 48h, observa la latencia p95 y la tasa de error
Reversión: kubectl rollout undo deploy/orders-api

// package.json (cada raíz de espacio de trabajo y servicio)
{
  "engines": {
    "node": "24.18.0",
    "npm": ">=10.0.0"
  }
}

# .nvmrc
24.18.0

Ejemplos de Solicitudes

Usa la Habilidad de Actualización de Node:
- Actual: Node 20.18.0 en 4 servicios en monorepo de npm workspaces
- Objetivo: 24.18.0
- Dependencias nativas: bcrypt en auth-api, sharp en media-worker
- Despliegue: EKS con Helm
- Salida: Tren de PRs + matriz de cambios importantes + reversión

Preguntas Frecuentes

Relacionado

• Política de Lanzamiento y LTS de Node.js - lo que la producción puede ejecutar
• Instalación y Gestión de Versiones - fnm/nvm
• engines y engine-strict - aplicar localmente
• Antes/Después de la Actualización LTS de Node 20→24 - caso de estudio

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS Activo), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.