npm v12 anuncia cambios que rompen compatibilidad hacia atrás

 (github.blog)
1 puntos por GN⁺ 2026-06-11 | 1 comentarios | Compartir por WhatsApp
  • El comportamiento predeterminado de npm install cambia a un enfoque centrado en la seguridad, por lo que funciones que hasta ahora se ejecutaban automáticamente ahora pasarán a funcionar solo si el usuario las permite explícitamente (opt-in)
  • allowScripts desactivado por defecto — los scripts preinstall·install·postinstall incluidos en paquetes externos instalados se bloquearán por defecto, y solo se ejecutarán los paquetes permitidos por el proyecto
    • Se cambia para bloquear scripts que se ejecutaban automáticamente con solo instalar un paquete, reduciendo así la posibilidad de que se cuele código malicioso
    • Las compilaciones nativas con node-gyp también quedan bloqueadas, por lo que incluso paquetes que solo tienen binding.gyp y no un script de instalación separado dejarán de compilarse (porque npm ejecuta internamente node-gyp rebuild)
    • El script prepare de paquetes traídos por git·file·link también se bloqueará de la misma manera
    • Uso: revisar qué paquetes tienen scripts con npm approve-scripts --allow-scripts-pending → permitir solo los confiables con npm approve-scripts y bloquear el resto con npm deny-scripts → como la lista de permitidos se guarda en package.json, debe hacerse commit
  • --allow-git con valor predeterminado none — los paquetes traídos directamente desde repositorios Git (incluyendo sus dependencias transitivas) se bloquearán por defecto, y solo se instalarán si se permite con --allow-git
    • Esto bloquea la vía por la que .npmrc dentro de un paquete Git podía sustituir el ejecutable de Git en sí (--ignore-scripts no evitaba este problema) (npm 11.10.0+)
  • --allow-remote con valor predeterminado none — los paquetes obtenidos desde URLs remotas como tarballs por https (incluyendo dependencias transitivas) se bloquearán por defecto, y solo se instalarán si se permite con --allow-remote (npm 11.15.0+)
    • Sin embargo, los valores predeterminados de --allow-file y --allow-directory no cambian en esta v12
  • Todos estos cambios se ofrecerán primero como advertencias en npm 11.16.0 o superior, para que sea posible revisarlos y prepararse antes del lanzamiento oficial
  • El lanzamiento estimado de v12 es en julio de 2026

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-06-11
Comentarios de Hacker News

  • No sé cómo se me pasó que npm fue adquirido por GitHub, pero de repente muchas cosas empiezan a tener sentido
    Cuesta pensar en un peor hogar para una parte tan importante del ecosistema de Node

  • Los scripts de postinstall debieron eliminarse hace mucho tiempo; son como un cáncer en los paquetes de NPM
    Hay demasiados postinstall profundos, anidados y sin control ejecutándose aleatoriamente cuando traes cualquier cosa
    No sé quién pensó en algún momento que esto era una buena idea

    • No creo entender bien el fondo de la preocupación con los scripts post-install
      Normalmente igual vas a ejecutar en algún momento el código de dependencias empaquetado, y por lo general con los mismos permisos que en el proceso de instalación
      Entonces esos scripts de configuración, para bien o para mal, solo moverían el punto de entrada desde npm al lugar donde ocurra un import o require
      A menos que todo el ecosistema se mueva a un entorno sandbox tipo Deno, como mucho esto parece un pequeño obstáculo. Aunque quizás ese sea el plan
    • No, para nada; hay muchos casos de uso válidos
      El ejemplo que se me viene de inmediato es https://www.npmjs.com/package/patch-package
      Ojalá la histeria actual no lleve a decisiones inútiles de este tipo

  • Esto probablemente se ha discutido cientos de veces dentro de NPM desde que se reportó públicamente hace 10 años
    Por culpa de Shai Halud, ahora ya es demasiado grande para ignorarlo

    • Me gusta que la historia de JavaScript parece prácticamente una destilación de la mentalidad del desarrollador
      “Lo arreglamos pronto” casi siempre termina siendo “mierda, ahora sí hay que arreglarlo”
    • Bien, ahora le toca a Python

  • Me pregunto si las versiones actuales LTS de Node, si no recuerdo mal 22, 24 y 26, planean subir el npm incluido a v12 para beneficiarse de esta corrección de seguridad
    Ahora mismo todas incluyen npm v11

    • Ya ha pasado antes que Node meta una actualización mayor de npm en una versión intermedia
      En v18.19.0[1] y v20.10.0[2] subieron npm de 9 a 10
      [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
      [2]: https://nodejs.org/en/blog/release/v20.10.0
    • Como es un cambio de valor por defecto, sí puede verse como un cambio en la postura de seguridad, pero la corrección de seguridad en sí ya está disponible para todos
      Como dice el artículo, solo hace falta configurar los valores correctos por defecto
      Lo mejor de este cambio es que, al cambiar el valor por defecto, vamos a ver romperse de inmediato esos paquetes molestos que asumen que estas configuraciones estarán activadas cuando un desarrollador nuevo simplemente corra install
      Por ejemplo, podría hacer que se abandone la práctica de asumir que se pueden ejecutar scripts

  • No queda claro solo leyendo el artículo, pero parece que la lista de scripts permitidos no es una configuración global sino que admite permisos por paquete
    Parece que será más fácil mantener reglas organizacionales que solo permitan scripts para paquetes específicos
    Me pregunto si existe algún linter que sirva para evitar valores inseguros por defecto en configuraciones del gestor de paquetes

    • ¿No bastaría con grep?

  • Me pregunto si todavía hay alguna razón para usar Yarn
    No sé si Yarn también implementó protecciones para frenar ataques a la cadena de suministro
    Hasta ahora solo conocía pnpm, así que está bien que npm también se esté poniendo al día

    • Claro que sí
      La rama actual de Yarn, 4.x, garantiza un comportamiento determinista hasta un grado quizá excesivo, y puedes esperar consistencia en todo el equipo
      En funciones, tiene muchos pequeños detalles que, una vez que te acostumbras, se acumulan y terminan marcando una gran diferencia
      La próxima versión mayor también seguirá empujando en esa misma dirección, con mejor rendimiento y funciones que hasta ahora no se habían podido implementar precisamente por depender de esas mejoras de rendimiento
      Por cierto, soy el maintainer principal de Yarn
    • Trabajé en un proyecto que usaba Yarn desde sus inicios hasta v3, y era lentísimo pero funcionaba
      También tiene funciones de protección de la cadena de suministro
      Al final ya no lo soportamos y migramos a pnpm; las instalaciones quedaron mucho más rápidas tanto en CI como en las máquinas locales
      La migración nos tomó como un día con ayuda de un LLM
    • Una diferencia es que tiene estrategias de instalación opcionales, como ejecutar paquetes directamente desde archivos comprimidos en vez de descomprimirlos en node_modules
      https://yarnpkg.com/features/pnp
      Se parece bastante a usar .jar en Java en vez de un árbol de directorios de archivos .class
      Aunque es un poco hacky, y el soporte en editores y herramientas es irregular
      Como reduce muchísimo la cantidad de archivos pequeños, puede ser especialmente más rápido si te toca trabajar en Windows sí o sí
      Incluso puedes meter los archivos comprimidos en el repositorio git, eliminando la dependencia de Internet y del registro de paquetes
    • No sé qué haga NPM, pero Yarn instala dependencias muchísimo más rápido que NPM
    • Los que me están downvoteando también pueden responder la pregunta
      De verdad no sé la respuesta

  • No sabía que npm era propiedad de GitHub
    Eso explica varias cosas

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 de marzo de 2020, 571 comentarios, 1829 puntos) - https://github.blog/news-insights/company-news/npm-is-joinin...
      Algunas partes resultan interesantes de leer con el paso del tiempo
      El comentario más votado decía: “Microsoft no hace todo bien, pero honestamente la adquisición de GitHub ha salido mucho mejor de lo que esperaba. En lugar de imponer políticas centradas en Microsoft a GitHub, Microsoft ha adoptado más cosas de GitHub desde la perspectiva de producto. GitHub sigue operando como si fuera una empresa separada”
    • La empresa NPM estuvo a punto de quebrar en 2020
      Había levantado capital de riesgo, pero no encontró un modelo de negocio sostenible
      GitHub la adquirió para salvar el ecosistema, y esa adquisición tampoco es que le haya dado grandes beneficios a GitHub
    • La mayoría sabe eso, pero lo que realmente explica muchas cosas es que GitHub pertenece a Microsoft
      Y Microsoft movió GitHub a Azure
    • Sabía que era de GitHub, pero esta es la primera vez que veo las notas de lanzamiento directamente en el blog de GitHub y no en el blog de npm

  • Me pregunto si la lista permitida en package.json fija también la versión del paquete, o solo el nombre del paquete

  • Qué bueno que allowScripts venga desactivado por defecto
    [mira el reloj] ¿Apenas 18 meses detrás de pnpm?

    • Maven en Java nunca tuvo algo así, y nunca sentí que hiciera falta
      ¿Qué propósito tiene esto del lado de JavaScript?