⏱️ Lectura: 10 min
GitHub anunció el conjunto de cambios que traerá npm v12, la próxima versión mayor del gestor de paquetes de Node.js, estimada para julio de 2026. No son features nuevas: son tres comportamientos que hoy ocurren de forma automática en npm install y que pasarán a requerir tu permiso explícito.
📑 En este artículo
- TL;DR
- Qué cambia exactamente en npm v12
- Por qué npm v12 toma esta decisión
- Cómo prepararte hoy con npm v12
- Impacto y análisis para equipos en LATAM
- Qué sigue
- Preguntas frecuentes
- ¿Cuándo se lanza npm v12?
- ¿Qué pasa con mis dependencias que usan node-gyp?
- ¿Dónde se guarda la lista de scripts aprobados?
- ¿Por qué cambia el comportamiento de las dependencias Git si ya uso –ignore-scripts?
- ¿Tengo que cambiar algo si solo uso dependencias normales del registro?
- ¿Esto afecta a las dependencias locales por ruta de archivo?
- Referencias
La idea de fondo es simple y dura: instalar una dependencia ya no debería implicar ejecutar su código. Todas las protecciones ya están disponibles como advertencias en npm 11.16.0, así que puedes prepararte hoy en lugar de descubrir los errores el día de la actualización.
TL;DR
- npm v12 llega estimado en julio de 2026 con cambios de seguridad que rompen comportamientos por defecto de
npm install. allowScriptspasa a off: ya no se ejecutanpreinstall,installnipostinstallde dependencias salvo que las apruebes explícitamente.- Los builds nativos con
node-gyp(binding.gyp) también quedan bloqueados aunque el paquete no declare script de instalación. --allow-gitpasa anone: no se resuelven dependencias Git directas ni transitivas sin permiso explícito (desde npm 11.10.0).--allow-remotepasa anone: no se resuelven tarballs por URL remota sin permiso explícito (desde npm 11.15.0).- Todo está disponible como advertencia en npm 11.16.0+;
npm approve-scriptsgenera una allowlist enpackage.jsonque debes commitear. - Sirve para cortar el vector de la cadena de suministro: el postinstall malicioso fue la técnica de incidentes como event-stream y ua-parser-js.
Qué cambia exactamente en npm v12
Cada uno de los tres cambios convierte un comportamiento que hoy se ejecuta solo en uno al que tienes que entrar de forma voluntaria. En términos de seguridad esto se llama pasar de un modelo opt-out (peligroso por defecto, te proteges desactivando) a uno opt-in (seguro por defecto, habilitas lo que confías).
1. allowScripts pasa a off
Hoy, cuando ejecutas npm install, cualquier dependencia puede declarar scripts de ciclo de vida —preinstall, install y postinstall— que se ejecutan automáticamente en tu máquina con tus permisos. En npm v12 eso deja de ocurrir: los scripts de las dependencias no corren a menos que estén explícitamente permitidos en tu proyecto.
El detalle importante es que el bloqueo también cubre las compilaciones nativas. Un paquete que trae un archivo binding.gyp y no declara un script de instalación explícito igualmente queda bloqueado, porque npm dispara un node-gyp rebuild implícito por él. Esto afecta a módulos populares con código nativo (bases de datos embebidas, librerías de hashing, bindings de C/C++), así que es muy probable que tu proyecto tenga al menos uno en la lista. Los scripts prepare de dependencias de tipo git, file y link se bloquean del mismo modo.
⚠️ Ojo: si tu rutina de instalación depende de un postinstall para compilar binarios o generar archivos, ese paso dejará de correr en silencio tras la actualización. En npm 11.16.0+ ya aparece como advertencia: ese es el momento de detectarlo.
2. –allow-git pasa a none
npm v12 ya no resolverá dependencias de Git —ni directas ni transitivas— salvo que las habilites con --allow-git. Esto cierra una ruta de ejecución de código menos obvia: el archivo .npmrc de una dependencia Git podía sobrescribir el ejecutable de git y correr código, incluso si habías pasado --ignore-scripts. Es decir, desactivar los scripts no era suficiente. Este cambio se anunció el 18 de febrero de 2026 y está disponible desde npm 11.10.0.
3. –allow-remote pasa a none
El tercer cambio: npm v12 dejará de resolver dependencias desde URLs remotas —como tarballs servidos por HTTPS, directos o transitivos— salvo que lo habilites con --allow-remote. Está disponible desde npm 11.15.0. Vale aclarar que los flags relacionados --allow-file y --allow-directory no cambian sus valores por defecto en v12, así que las dependencias locales por ruta de archivo siguen funcionando igual.
graph LR
A["npm install"] --> B{"allowScripts on?"}
B -->|no| C["scripts bloqueados"]
B -->|si| D["ejecuta postinstall / node-gyp"]
C --> E["dependencias instaladas"]
D --> EPor qué npm v12 toma esta decisión
Para entender por qué npm v12 endurece tanto el comportamiento por defecto hay que mirar la historia de los ataques a la cadena de suministro de software. El postinstall ha sido durante años el vector favorito de los atacantes: basta con publicar (o comprometer) un paquete cuya instalación ejecute código, y todo el que lo instale —o instale algo que dependa de él— corre ese código sin darse cuenta.
Los casos son célebres en la comunidad JavaScript. En el incidente de event-stream, una dependencia transitiva ampliamente usada fue comprometida para inyectar código que apuntaba a robar credenciales de billeteras de criptomonedas. En el de ua-parser-js, versiones maliciosas publicadas tras un secuestro de cuenta instalaban mineros de criptomonedas y ladrones de credenciales a través de un script de instalación. En ambos, el denominador común fue el mismo: instalar significaba ejecutar.
💭 Clave: el riesgo no es solo lo que instalas a propósito, sino lo que tus dependencias instalan por ti. Un proyecto típico tiene decenas de dependencias directas y cientos de transitivas; cualquiera de ellas con un postinstall es superficie de ataque.
La novedad real de npm v12 es que la lista de paquetes a los que les permites ejecutar código queda escrita en tu package.json y se commitea al repositorio. Por primera vez, quién puede correr código durante la instalación se convierte en un artefacto revisable: aparece en los diffs, pasa por code review y queda en el historial de Git. Eso transforma una decisión invisible en una decisión auditable.
Cómo prepararte hoy con npm v12
No tienes que esperar a julio de 2026. El flujo recomendado es actualizar a npm 11.16.0 o posterior, correr tu instalación normal y revisar las advertencias. Empieza por actualizar npm en tu máquina:
# Windows (PowerShell)
npm install -g npm@latest
npm --version
# macOS / Linux
npm install -g npm@latest
npm --version
Con npm 11.16.0+ instalado, descubre qué paquetes de tu proyecto traen scripts que quedarían bloqueados:
# Ver qué paquetes tienen scripts pendientes de aprobar
npm approve-scripts --allow-scripts-pending
# Aprobar los paquetes en los que confías (escribe la allowlist en package.json)
npm approve-scripts
# Bloquear explícitamente el resto
npm deny-scripts
La allowlist resultante se guarda en tu package.json y debes commitearla, para que tu equipo y tu pipeline de CI/CD compartan exactamente la misma política. Tras la actualización a v12, solo los scripts que aprobaste seguirán corriendo; cualquier cosa que dejaste sin aprobar dejará de ejecutarse.
Si tu proyecto sí necesita dependencias Git o tarballs remotos, habilítalos de forma explícita en el comando de instalación:
# Permitir una dependencia Git concreta
npm install --allow-git
# Permitir resolución de dependencias por URL remota
npm install --allow-remote
💡 Tip: integra npm approve-scripts --allow-scripts-pending en tu CI antes de que v12 sea obligatorio. Así detectas paquetes nuevos con scripts en cada pull request, en lugar de que un build de producción falle el día de la migración.
Impacto y análisis para equipos en LATAM
Para los equipos de desarrollo en Latinoamérica, npm v12 tiene una doble cara. Por un lado, es una mejora de seguridad enorme y gratuita: muchos equipos no tienen presupuesto ni personal dedicado a auditar la cadena de suministro, y este cambio les da una defensa por defecto que antes había que configurar a mano con herramientas externas.
Por otro lado, hay un costo de migración concreto que conviene planificar. Si tu monorepo o tu app depende de módulos con código nativo —muy común en stacks que usan bases de datos embebidas, procesamiento de imágenes o criptografía— vas a tener una lista de paquetes que aprobar. Y si tu equipo usa una dependencia apuntando directo a un repositorio de Git (un patrón frecuente para forks internos o librerías privadas sin registro propio), esa instalación dejará de resolverse sin el flag correspondiente.
La recomendación práctica es tratar esto como una tarea de migración con fecha: dedicar una sesión a correr npm approve-scripts --allow-scripts-pending en cada proyecto activo, revisar la lista con el equipo (¿realmente confiamos en que este paquete ejecute código?), commitear la allowlist y verificar que el build sigue verde. Hacerlo ahora, con npm en modo advertencia, es barato; hacerlo bajo presión cuando v12 ya rompió el pipeline, no.
Qué sigue
npm v12 se enmarca en una tendencia más amplia: GitHub viene reforzando la seguridad de la cadena de suministro con publicación escalonada (staged publishing), nuevos controles en tiempo de instalación y soporte ampliado de OIDC para Dependabot. La dirección es clara: reducir la confianza implícita en el ecosistema de paquetes y reemplazarla por decisiones explícitas y auditables.
Mientras tanto, lo accionable es lo de siempre con un breaking change anunciado: probarlo antes de que sea obligatorio. La versión 11.16.0 te da la red de seguridad de las advertencias; aprovéchala para que la llegada de v12 en julio de 2026 sea un no-evento en tus proyectos.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Cuándo se lanza npm v12?
La fecha estimada es julio de 2026. Todos los cambios de comportamiento ya están disponibles como advertencias en npm 11.16.0 y versiones posteriores, para que puedas prepararte antes del lanzamiento.
¿Qué pasa con mis dependencias que usan node-gyp?
Quedan bloqueadas por defecto, incluso si el paquete no declara un script de instalación explícito, porque npm ejecuta un node-gyp rebuild implícito por ellas. Debes agregarlas a la allowlist con npm approve-scripts si confías en ellas y necesitas su compilación nativa.
¿Dónde se guarda la lista de scripts aprobados?
La allowlist se escribe en tu package.json y debe commitearse al repositorio. Así tu equipo y tu pipeline de CI/CD comparten la misma política de qué paquetes pueden ejecutar código durante la instalación.
¿Por qué cambia el comportamiento de las dependencias Git si ya uso –ignore-scripts?
Porque el archivo .npmrc de una dependencia Git podía sobrescribir el ejecutable de git y ejecutar código aun con --ignore-scripts activo. Desactivar los scripts no cerraba esa ruta; por eso --allow-git pasa a none por defecto.
¿Tengo que cambiar algo si solo uso dependencias normales del registro?
Si ninguna de tus dependencias tiene scripts de ciclo de vida ni compilación nativa, probablemente no notes nada. Aun así, corre npm approve-scripts --allow-scripts-pending para confirmarlo: las dependencias transitivas suelen esconder sorpresas.
¿Esto afecta a las dependencias locales por ruta de archivo?
No. Los flags --allow-file y --allow-directory no cambian sus valores por defecto en npm v12, así que las dependencias locales por ruta siguen funcionando como hasta ahora.
Referencias
- GitHub Changelog — anuncio oficial de los breaking changes de npm v12.
- Documentación oficial de npm — referencia de comandos, incluidos approve-scripts y deny-scripts.
- npm/cli en GitHub — repositorio del CLI de npm, releases y discusiones de la comunidad.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios