npm v12 annonce des changements cassant la compatibilité descendante

 (github.blog)
1 points par GN⁺ 2026-06-11 | 1 commentaires | Partager sur WhatsApp
  • Le comportement par défaut de npm install devient axé sur la sécurité : des fonctionnalités jusqu’ici exécutées automatiquement ne fonctionneront désormais que si l’utilisateur les autorise explicitement (opt-in)
  • allowScripts désactivé par défaut — les scripts preinstall, install et postinstall inclus dans les paquets externes installés sont bloqués par défaut, et seuls les paquets autorisés par le projet peuvent les exécuter
    • Ce changement bloque les scripts qui s’exécutaient automatiquement au simple moment de l’installation d’un paquet, afin de réduire les possibilités d’injection de code malveillant
    • Les builds natifs node-gyp sont aussi concernés : les paquets qui n’ont qu’un binding.gyp sans script d’installation séparé ne pourront plus être compilés non plus, car npm exécute en interne node-gyp rebuild
    • Les scripts prepare des paquets récupérés via git, file ou link sont eux aussi bloqués de la même manière
    • Utilisation : vérifier quels paquets contiennent des scripts avec npm approve-scripts --allow-scripts-pending → autoriser uniquement ceux de confiance avec npm approve-scripts, bloquer les autres avec npm deny-scripts → la liste des autorisations est enregistrée dans package.json, il faut donc la committer
  • --allow-git vaut désormais none par défaut — les paquets récupérés directement depuis des dépôts Git, y compris leurs dépendances transitives, sont bloqués par défaut et ne pourront être installés qu’en les autorisant avec --allow-git
    • Cela bloque la voie par laquelle le .npmrc d’un paquet Git pouvait remplacer l’exécutable Git lui-même (un problème exploitable même avec --ignore-scripts) (npm 11.10.0+)
  • --allow-remote vaut désormais none par défaut — les paquets récupérés depuis des URL distantes comme des tarballs HTTPS, y compris de manière transitive, sont bloqués par défaut et ne pourront être installés qu’en les autorisant avec --allow-remote (npm 11.15.0+)
    • En revanche, les valeurs par défaut de --allow-file et --allow-directory ne changent pas dans cette v12
  • Tous ces changements sont d’abord proposés sous forme d’avertissements à partir de npm 11.16.0, afin de permettre une vérification et une adaptation en amont avant la sortie officielle
  • La sortie de v12 est prévue pour juillet 2026

À lire aussi

1 commentaires

 
GN⁺ 2026-06-11
Commentaires sur Hacker News

  • Je ne sais pas comment j’ai pu rater le fait que npm a été racheté par GitHub, mais soudain beaucoup de choses commencent à s’expliquer
    J’ai du mal à imaginer pire foyer pour un composant aussi important de l’écosystème Node

  • Les scripts postinstall auraient dû être supprimés depuis longtemps, c’est un cancer des paquets NPM
    Il y a bien trop de postinstall profondément imbriqués, non contrôlés, qui s’exécutent aléatoirement quand on récupère quelque chose
    Je ne sais pas qui a pu trouver que c’était une bonne idée à l’époque

    • Je ne suis pas sûr de bien comprendre le fond de l’inquiétude autour des scripts post-install
      En général, le code des dépendances packagées finit de toute façon par être exécuté à un moment donné, souvent avec les mêmes privilèges que le processus d’installation
      Du coup, ces scripts de configuration peuvent, pour le meilleur ou pour le pire, simplement déplacer leur point d’entrée de npm vers l’endroit où se produit un import ou un require
      À moins que tout l’écosystème ne migre vers un environnement sandboxé façon Deno, au mieux ça ressemble à une petite friction. C’est peut-être le plan, cela dit
    • Il ne faut surtout pas faire ça, il y a beaucoup de cas d’usage valables
      L’exemple qui me vient tout de suite est https://www.npmjs.com/package/patch-package
      J’espère que l’hystérie actuelle ne débouchera pas sur ce genre de décision absurde

  • J’ai l’impression que ce sujet a dû être discuté des centaines de fois en interne chez NPM depuis sa publication il y a 10 ans
    À cause de Shai Halud, c’est désormais trop gros pour être ignoré

    • J’aime bien l’idée que l’histoire de JavaScript soit en gros une concentration de mentalité développeur
      « je corrigerai ça plus tard » finit presque toujours en « merde, il faut qu’on corrige ça maintenant »
    • Bien, maintenant c’est au tour de Python

  • Je me demande si les versions Node LTS actuelles, de mémoire 22, 24, 26, vont recevoir npm v12 dans leur bundle pour bénéficier de ce correctif de sécurité
    Pour l’instant elles incluent toutes npm v11

    • Il y a déjà eu par le passé des mises à niveau majeures de npm dans des releases intermédiaires de Node
      npm est passé de 9 à 10 dans v18.19.0[1] et v20.10.0[2]
      [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
      [2]: https://nodejs.org/en/blog/release/v20.10.0
    • On peut y voir un changement de posture de sécurité puisque la valeur par défaut change, mais le correctif de sécurité lui-même est déjà applicable par tout le monde
      Comme l’indique l’article, il suffit de définir les bons paramètres par défaut
      Le meilleur aspect de ce changement, c’est qu’avec ce nouveau défaut, les paquets pénibles qui supposent que ces options sont activées dès qu’un nouveau développeur lance simplement install vont casser immédiatement
      Ça peut par exemple forcer l’arrêt de la pratique consistant à présumer que les scripts peuvent s’exécuter

  • Ce n’est pas totalement clair à la lecture de l’article, mais la liste d’autorisation des scripts semble prendre en charge une autorisation par paquet plutôt qu’un réglage global
    Ça devrait faciliter le maintien de règles à l’échelle d’une organisation pour n’autoriser les scripts que sur certains paquets
    Je me demande s’il existe un linter capable d’empêcher ce type de valeurs par défaut non sûres dans la configuration du gestionnaire de paquets

    • Un grep, ça ne suffirait pas ?

  • Je me demande s’il y a encore une raison d’utiliser Yarn
    Je ne sais pas si Yarn a aussi mis en place des protections contre les attaques de supply chain
    Jusqu’ici je ne connaissais que pnpm, donc c’est bien de voir npm s’aligner aussi

    • Bien sûr que oui
      La dernière release majeure de Yarn, la 4.x, garantit un comportement déterministe presque à l’excès, et on peut s’attendre à un comportement cohérent dans toute l’équipe
      Côté fonctionnalités, il y a plein de petits détails qui, une fois qu’on s’y habitue, finissent par faire une vraie différence
      La prochaine release majeure va continuer dans la même direction avec de meilleures performances, ainsi que des fonctionnalités qui n’ont pas pu être implémentées jusqu’ici précisément parce qu’elles dépendaient de ces gains de performance
      Pour référence, je suis le mainteneur principal de Yarn
    • J’ai travaillé sur un projet qui utilisait Yarn depuis ses débuts jusqu’à la v3, et c’est extrêmement lent mais ça fonctionne
      Il y a aussi des fonctionnalités de protection de la supply chain
      J’ai fini par ne plus le supporter et je suis passé à pnpm, ce qui a rendu les installations bien plus rapides à la fois en CI et sur les machines de dev locales
      La migration m’a pris environ une journée avec l’aide d’un LLM
    • Un des points différenciants, c’est la stratégie d’installation optionnelle qui permet d’exécuter les paquets directement depuis des archives compressées au lieu de les décompresser dans node_modules
      https://yarnpkg.com/features/pnp
      C’est assez proche de l’usage de .jar en Java plutôt qu’une arborescence de répertoires de fichiers .class
      Cela dit, c’est un peu bricolé, et le support des éditeurs et outils est inégal
      Comme il y a beaucoup moins de petits fichiers, ça peut être particulièrement plus rapide si vous êtes contraint de travailler sous Windows
      On peut aussi mettre les archives dans le dépôt git, ce qui supprime la dépendance à Internet et au registre de paquets
    • Je ne sais pas ce que fait NPM, mais avec Yarn, l’installation des dépendances est bien plus rapide qu’avec NPM
    • Ceux qui downvotent mon commentaire peuvent aussi répondre à la question
      Je ne connais vraiment pas la réponse

  • Je ne savais pas que npm appartenait à GitHub
    Ça explique pas mal de choses

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 mars 2020, 571 commentaires, 1829 points) - https://github.blog/news-insights/company-news/npm-is-joinin...
      Certaines réactions sont intéressantes à relire avec le recul
      Le commentaire le plus haut disait en gros : « Microsoft ne réussit pas tout, mais honnêtement le rachat de GitHub s’est bien mieux passé que prévu. Au lieu d’imposer à GitHub des politiques centrées sur Microsoft, Microsoft a davantage adopté des éléments de GitHub du point de vue produit. GitHub continue de fonctionner comme une entreprise distincte »
    • L’entreprise NPM était pratiquement au bord de la faillite en 2020
      Elle avait levé du capital-risque, mais n’avait pas réussi à trouver un modèle économique viable
      GitHub l’a rachetée pour sauver l’écosystème, et cette acquisition n’a quasiment pas apporté de gros bénéfices à GitHub
    • La plupart des gens le savent, mais ce qui explique vraiment beaucoup de choses, c’est que GitHub appartient à Microsoft
      Et Microsoft a migré GitHub sur Azure
    • Je savais que c’était la propriété de GitHub, mais c’est la première fois que je vois directement des notes de release sur le blog GitHub plutôt que sur le blog npm

  • Je me demande si la liste d’autorisation dans package.json est figée jusqu’à la version du paquet, ou si elle ne verrouille que le nom du paquet

  • C’est bien que allowScripts soit désactivé par défaut
    [regarde sa montre] npm ne fait que rattraper pnpm avec 18 mois de retard ?

    • Maven en Java n’avait rien de ce genre, et je n’ai jamais eu l’impression que c’était nécessaire
      À quoi ça sert exactement côté JavaScript ?