Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !
GitHub (Microsoft) se paie le gestionnaire de paquets npm

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.

9 commentaires
Avatar de brazomyna INpactien
Avatar de brazomynabrazomyna- 17/03/20 à 11:49:33

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.

Avatar de TheMyst INpactien
Avatar de TheMystTheMyst- 17/03/20 à 12:25:12

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 ?

Avatar de NiCr Abonné
Avatar de NiCrNiCr- 17/03/20 à 13:21:17

TheMyst a écrit :

Perso, j'ai surtout pu voir les problèmes qu’amène une gestion non centralisé des dépôts avec Maven.

Aha clairement, quiconque a déjà travaillé avec Maven sait à quel point c'est l'enfer le principe des repos décentralisés pour avoir une base stable.

Au final pour avoir de la stabilité tu te fais ou passe par un miroir qui centralise de la même façon que peut le faire npm...

Avatar de brazomyna INpactien
Avatar de brazomynabrazomyna- 17/03/20 à 14:29:18

TheMyst a écrit :

Perso, j'ai surtout pu voir les problèmes qu’amène une gestion non centralisé des dépôts avec Maven. Quelle plaie de compiler un projet un peu exotique depuis des dépôts qui n'existent plus.

Entre ultra-centralisé et totalement décentralisé, il y a des solutions médianes qui sont sans doute plus avantageuses que la dichotomie "single point of failure" vs "repo-anarchie"

Perso, avoir un acteur unique, privé, qui détient à lui seul autant de pouvoir ça me met toujours mal à l'aise.

Avatar de wagaf Abonné
Avatar de wagafwagaf- 17/03/20 à 14:52:52

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.

Édité par wagaf le 17/03/2020 à 14:53
Avatar de spidermoon Abonné
Avatar de spidermoonspidermoon- 17/03/20 à 16:12:01

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.
Sans compter ceux qui utilisent des package.json sans nettoyer les dépendances (merci Node Starter de MS :mad:) 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.

Édité par spidermoon le 17/03/2020 à 16:13
Avatar de kgersen Abonné
Avatar de kgersenkgersen- 17/03/20 à 16:44:57

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.

Avatar de Tamadadoo Abonné
Avatar de TamadadooTamadadoo- 17/03/20 à 22:51:16

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.

Avatar de TexMex Abonné
Avatar de TexMexTexMex- 18/03/20 à 08:52:54

 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.

 

Il n'est plus possible de commenter cette actualité.