GitHub a beau avoir été racheté pour 7,5 milliards de dollars en octobre 2018, l’entité garde une certaine indépendance. Elle vient d’annoncer le rachat de Node Package Manager pour un montant non précisé.
npm est un service particulièrement populaire de distributions de paquets pour applications JavaScript. Selon les propres chiffres fournis par l’éditeur, 75 milliards de paquets sont ainsi distribués chaque mois. La plateforme contient plus de 1,3 million de paquets, pour une communauté de 12 millions de développeurs.
Il faut donc s’attendre à un renforcement des liens entre GitHub et npm. Trois axes ont été définis : construire un registre et une infrastructure fiables, améliorer l’expérience centrale et renforcer les liens avec la communauté.
Par ailleurs, npm reste gratuit. Le support des comptes Pro, Teams et Enterprise sera assuré par le nouveau propriétaire. Il leur sera proposé de convertir leurs paquets npm en GitHub Packages, ce qu’ils pourront refuser.
GitHub organisera dans les jours à venir une session de questions/réponses sur Reddit.
Commentaires (9)
#1
Pour moi (à long terme) npm est voué à disparaître ; l’avenir est du côté des repositories avec un fonctionnement moins centralisé, dont on a eu plusieurs fois l’occasion de voir les limites en cas d’indispo etc…
On a l’exemple qui me semble parfait avec Deno (une sorte de ‘post nodejs’ qui mange aussi du typescript en natif). Il permet tout simplement de spécifier ses imports au moyen de n’mporte quelle URL.
#2
Perso, j’ai surtout pu voir les problèmes qu’amène une gestion non centralisé des dépôts avec Maven.
Qu’elle plaie de compiler un projet un peu exotique depuis des dépôts qui n’existent plus. Obliger de creuser sur différente machine si untel n’a pas le bon paquet dans son cache. Et si ce n’est pas le cas ? Obligé de compiler les sources soi même puis de déposer ça dans son cache.
Je ne dit pas que le dépôt centralisé soit la réponse, mais une chose est sur c’est que le non-centralisation (par un éclatement des paquets sur différents dépôts) n’est pas la solution.
Peut-être faudrait-il simplement plusieurs miroirs, comme ce qui est fait depuis des années sur les dépôts Debian ?
#3
#4
#5
C’est une bonne chose pour npm car c’est une infrastructure critique qui doit rester gratuite et sécurisée alors que bien sûr ils ont des coûts importants.
Microsoft est en train de devenir ce que Google a été dans les années 2000-2020..
Je pense que Google aujourd’hui sous-estime l’impact qu’ils ont eu en embauchant un grand nombre de développeurs de projets Open Source, en en finançant un grand nombre avec le GSOC, en plus des 20% des employés pour bosser sur des projets open source.. Ça leur aura permis de prendre le contrôle des principaux languages, outils de développements et bibliothèques de base, sans nécessairement les “posséder”, à l’époque où MS s’enfonçait dans l’obsolescence. Google n’a pas fait évoluer sa stratégie avec le temps, dans cette logique c’est eux qui auraient du acheter GitHub, voire StackExchange…
Dans le même temps Microsoft a évolué dans le bon sens, ils ont viré Ballmer, et pour la première fois dans leur histoire ont mis quelqu’un qui comprend Internet et l’informatique à la place.
#6
Avoir un mirroir interne fonctionne très bien. La vraie plaie ce sont des modules comme “node sass” ou “mongodb-memory-driver”, qui vont chercher des trucs sur internet en plus des modules, et comme nos serveurs n’ont pas internet, c’est la galère.
" />) et on se retrouve à télécharger des milliers de petits fichiers. Le moindre projet pèse ainsi 200Mo avec quelques dizaines de milliers de fichiers modules.
Sans compter ceux qui utilisent des package.json sans nettoyer les dépendances (merci Node Starter de MS
#7
ce n’est pas si simpliste. Google fait toujours les choses avec 5 ans a 10 ans de projection. C”est leur principale force et leur méthode depuis toujours. C’est ce qui fait qu’on leur reproche d’abandonner trop rapidement les technos sans avenir aussi.
Microsoft c’est plutôt l’inverse ils sont extrêmement forts pour “fédérer” les trainards et les ‘enfermer’ dans des technos matures du moment. NPM est devenu une techno mature qui ne va sans doute plus évoluer de façon drastique et qui va péricliter lentement.
Google est focus sur les technos de la prochaine vague, comme Kubernetes par exemple ou la suite d’Android. On ne peut pas dire que Microsoft a innover de ce coté la…par exemple leur tentative de fagocitage de Docker (pour Windows) a tuer Docker (la société) plus qu’autre chose.
Autre exemple: le browser façon Chrome est devenu mature donc Microsoft se l’accapare. etc
Pour bien comprendre les différences fondamentales de ces 2 boites, il faut se projeter dans 5 ans par exemple. Est-ce que Github et NPM seront centraux et attracteurs de talents dans 5 ans comme ils l’ont été il y a 5 ans ? j’en doute.
#8
Le gros problème de node/npm , dans son coté centralisé, et hyper imbriqué des dépendances , c’est qu’un tout petit package insignifiant, qui est déjà une dépendance de dépendance de dépendance, peut se retrouver la cible d’un exploit qui passe inaperçu.
Et ainsi se retrouver dans 26000 projets d’un jour à l’autre , au gré des webpack et autres joyeusetés du genre. C’est une aberration devenue incontrôlable au niveau sécurité, au vu du spaghetti quasi fractal des dépendances.
Et pour les performances , même problème, ça me rappelle quand les devs de Wallmart se sont rendu compte que se qui bloquait leur montée en charge, c’était un sous-sous-sous-package de Express.js qui était codé avec les pieds.
Quand ils ont réglé le problème de ce sous-package, ils se sont aperçu qu’ils pouvaient en fait tenir l’équivalent de plusieurs Black Friday sur une journée X, avec leur infrastructure actuel. Le jour et la nuit.
#9
Est-ce que le rachat va changer la donne? Probablement.
Est-ce que ce sera dans le sens de la communauté? Si cela ne rentre pas en conflit avec les intérêts de MS.
Est-ce que les problèmes de sécurité comme on a pu voir avec l’épisode de l’exploit BitCoin seront du passé? Pas certain.
Si MS rachète; il y a une raison. Ici on ne sait pas trop laquelle. Faire plaisir aux developpeurs n’est pas vraiment le mode opératoire de MS.
La centralisation n’est pas tant le problème. Les proxy et les miroirs ça sert à ça. C’est l’autorité qui chapeaute qui peut le devenir. Que va devenir ce truc?? Wait & see.
Il y a aussi le fabuleux problème du trop plain de paquets et librairies. On en vient à voir deux développeurs différents écrire les mêmes librairie/modules dans un langage X puis Y (ou plateforme X ou Y). M’est avis qu’il faudrait un peu plus d’universalité dans la chose histoire d’aider le coté sécurité mais aussi de ramener de la compétence la ou il en faut. CAD au bout des doigt boudinés de ces devs plus ou moins pisseur de code. Quand ce n’est pas du Clikotron. Il manque cruellement d’interopérabilité entre les langages (utiliser une lib en C avec du java par ex). Même si c’est parfaitement faisable on ne le voit que trop peu.