nvm: versiones de Node y estado del shell
Desplegar nvm en equipos y CI: inicializar la shell también es construir
Planifica versiones fijadas, propiedad de perfiles e inicialización no interactiva sin confundir la terminal personal con el entorno CI.
Qué aprenderás
- Define los cambios permitidos de instalación
- Los trabajos no interactivos necesitan inicialización explícita
- El arranque de producción es otra frontera
Antes de empezar
- Comandos de shell y entorno de procesos
- Distinguir instalación y selección del runtime
Diagnostica la versión solicitada frente a la activa y define límites explícitos de instalación y verificación.
Conclusiones clave
- Evitar edición del perfil no evita las demás escrituras.
- Cada shell no interactiva necesita inicialización deliberada.
- Verifica el runtime bajo la identidad real del servicio.
Define los cambios permitidos de instalación
El install.sh inspeccionado elige destino, obtiene archivos y detecta un perfil para añadir fragmentos de carga. PROFILE=/dev/null desactiva la edición del perfil, pero no convierte la instalación en operación de solo lectura. El plan debe registrar revisión, destino, perfil previsto y si se instalará también una versión de Node solicitada.
Revisa el instalador descargado antes de ejecutarlo y conserva su identidad de origen. No mezcles líneas manuales y gestionadas sin buscar duplicados. Un perfil equivocado o una shell no inicializada explica muchos errores de comando ausente; volver a descargar lo mismo no sustituye averiguar qué archivo lee realmente esa shell.
Los trabajos no interactivos necesitan inicialización explícita
Un paso CI no tiene necesariamente la misma shell que la terminal del desarrollador. El README explica carga explícita e integración con BASH_ENV para Bash no interactivo. Elige un mecanismo deliberado y pruébalo en el runner real. Una variable NVM_DIR por sí sola no define la función nvm ni selecciona un ejecutable Node.
Fija por separado gestor y runtime, y muestra el runtime efectivo en registros sin revelar secretos. Si cada paso inicia otra shell, la selección anterior no se convierte automáticamente en estado de la siguiente. Un wrapper que inicialice y seleccione antes de construir puede hacer visible ese límite entre procesos.
El arranque de producción es otra frontera
nvm-exec carga el gestor con --no-use, selecciona mediante NODE_VERSION o búsqueda del proyecto y ejecuta la orden con exec. Esto explica el proceso hijo previsto, pero aquí se inspeccionó el script sin ejecutarlo. Usuarios de servicio, permisos, rutas y reinicios de producción necesitan validación específica del entorno.
Trata las actualizaciones del runtime como cambios de aplicación con aceptación y reversión. Un directorio conservado en disco no prueba que el servicio pueda utilizarlo ni que sus dependencias sean compatibles. El artículo proporciona una lista de integración, no una afirmación de haber construido y desplegado una imagen, trabajo CI o servicio productivo.
Pasos de implementación
- 1
Registra versiones, destino y propietario del perfil.
- 2
Revisa el instalador y autoriza sus escrituras.
- 3
Prueba una shell no interactiva nueva en el runner.
- 4
Valida aplicación y reversión antes de cambiar servicios.
Ejemplo para copiar
# Fragmento CI: nvm y este runtime deben estar instalados
# NVM_DIR procede de la configuración autorizada del runner
. "$NVM_DIR/nvm.sh" --no-use || exit 1
nvm use 24.14.0 || exit 1
nvm which current
node --version
# Construye el proyecto solo tras superar estas comprobacionesPreguntas frecuentes
¿PROFILE=/dev/null significa que no se instala nada?
No. Suprime la edición del perfil; descargar el gestor y otras acciones de instalación siguen siendo independientes.
¿Por qué desaparece nvm en el siguiente paso CI?
Puede iniciar una shell nueva sin inicializar. Comprueba los límites reales del runner, no la disponibilidad en una terminal anterior.
Fuentes
- README.mdFuente verificada 2026-09-08
- install.shFuente verificada 2026-09-08
- nvm-execFuente verificada 2026-09-08