Reprise du message précédent :

apt je suis pas sûr que tu puisses dépublier un paquet sans passer par les admins. Sinon techniquement pas grand chose, la différence est plus pratique/communautaire, il est plus rare d'avoir des arbres de dépendance très profonds avec des nano-librairies et des gens qui ont 100+ libs. Alors que c'est une pratique courante sur npm.

 
apt c'est sûr que tu peux pas, il faut être debian developer pour avoir la responsabilité d'un paquet

En partie oui, moins si tu bundles.

De notre côté on va probablement utiliser des tarballs pour les versions diffusées dans l'updater de notre appliance, ça évitera tout problème

Bref, pour du dev c'est très bien, en prod c'est moins pratique.

Et tu te retrouves avec Babel qui ne marche plus car il dépend d'une lib de 17 loc en v0.0.3 fait par un dev solo
Je comprends pas que les devs de gros projets comme ça inspectent pas leur arbre de dépendance et font l'analyse de risque qui va bien derrière.
Ca + le problème de mutabilité du repository central qui ne devrait pas pouvoir dégager un truc déjà publié selon moi.

et même pour un debian developer on ne va pas te laisser faire si ça casse le reste de la distrib.

 
T'as déjà vu la gueule d'un arbre de dépendance npm un peu sérieux? Perso je refuse d'inspecter un tel bordel, je prends que des libs répandues et "matures", et je prie.

Je touche pas aux technos de hipsters.

Mais ça veut dire que de base, l'éolienne n'est pas instrumentée pour surveiller ce genre de truc ? C'est quelle marque ?
Sinon c'est peut être l'éolienne qui a un problème de fausse mesure, genre un anémomètre qui a du jeu...

Y'a 3 problèmes dans cette histoire :

1) Les dépendances de mongols genre left-pad ou isArray qui sont des dépendances qui contiennent une seule et unique fonction. C'est complètement délirant et c'est souligné dans l'article NPM & left-pad: Have We Forgotten How To Program?

2) Pour lister ses packages, npm utilise un seul et unique namespace global. Ca veut dire que si veux mecs font un package "currency", il va y avoir collision de noms et il faudra donc renommer les packages. Du coup, dans sa politique de résolution des conflits de noms, npm est susceptible de changer le gestionnaire du package pour le confier à quelqu'un d'autre qui aurait des droits sur ce noms ou un truc bien con dans le style. Maven utilise le même système que les packages java pour séparer les namespaces (ex: org.junit pour tous les packages de junit).

3) La fragilité des builds npm qui exacerbe le problème plus général que quand tu ajoutes une dépendance à ton projet, il faut la maintenir et ça a un coût. Beaucoup de gens se bercent dans l'illusion que rajouter une dépendance c'est gratuit (ou presque)

en fait elles ont une tonne d'instrument, mais c'est le constructeur qui a le pied sur les données, du coup le proprio il a accès à rien.
Dans un monde normal notre boite servirait à rien, mais en fait on contourne le constructeur en ré-instrumentant la chose et en montrant les données au proprio.
 
dans ce cas très précis, on pourrait être en-dessous de la sensibilité des capteurs du constructeur, ils utilisent de la grosse artillerie fiable mais peu précise.

dites, c'est quoi pour vous LinkedIn ? pourquoi mes 2 parents qui sont retraités sont dessus avec comme profession "retraité" ?

Chuis pas vraiment d'accord avec cette vision. Si c'est pas présent dans la stdlib (parce que c'est javascript et t'as pas de stdlib) et que tu pars du principe que le package manager est un peu sérieux, t'as besoin d'une fonction A, entre récupérer une lib qui est A, récupérer un gros sac qui contient A et 40 billions d'autres trucs dont tu te fous (genre apache-commons) ou copier/coller A depuis stackoverflow, à difficulté équivalente et toutes choses étant égales t'as aussi bien fait de prendre le premier. L'assertion de "une fonction n'est pas une librairie" est complètement arbitraire et sans support.

 
Ils répondent à du spam/scam.

1/ Bof, ça m'arrange d'avoir accès a des fonctions testées et maintenues qui ne sont pas dispo dans la lib std. Est-ce que d'autres gros projets comme Babel devrait dépendre de ça est une autre histoire.
2/ Le namespacing ne résoudra pas les inévitables conflits de nom.
3/ Npm n'est pas beaucoup moins fiables que les autres systèmes de paquets.

Bof, pour moi cette histoire met surtout en évidence des problèmes humains :
- Le connard de chez kik
- La politique de merde @npm, qui 1/ change les repo owners quand ça lui chante 2/ autorise le unpublish
Avec des explications venant de Npm tellement peu convaincantes et contradictoires, ça confirme qu'ils partent dans une mauvaise direction

 
Même ressenti ici.

 
Euh, si? Dans ce cas ça aurait permis d'avoir org.toto.Kik et com.cogip.Kik non?

 
Y'aurait pas aussi le problème de la centralisation du repo, gérée par une seule boîte?
Genre sous maven le gars il aurait juste hosté ses jars dans un autre repo et roule.

Sous Maven t'as un repository central public non?

Vu qu'on est vendredi, on peut discuter de l'absence de stdlib de qualité pour Javascript.

Oui, mais pas que, certaines boites hostent leur propres repo privé. Pour notre build, on a maven central, deux autres repos, + un repo a nous ou on mets des libs qui ne sont pas dans maven ou qu'on a modifié. Si maven central disparait, on rehoste les libs dans notre repo a nous et on est bons.

 
J'ai l'impression que c'est aussi ça le pb oui. Mais j'en vois un autre: le fait de se fier a du code fait par personnes (par transitivité) que tu connais pas et qui peuvent le changer par de la merde a tout moment.

Et quand l'allemand kik voudra faire une api pour son webstore, il demandera quoi ? Apres tout, il était la en premier
 
Je suis favorable au namespacing pour des raisons de clarté et parce que ça fait bien rangé, mais c'est tout.

 
J'ai du mal à voir où stdlib aurait résolu le problème.
 
Le problème n'est pas "Javascript".

Oui et non  
Tu te fies a une version taggée d'une lib, qui reste constante (si npm faisait pas de la merde )

Dès que tu mets une dépendance tu entres dans une relation de confiance.
Pour le changement faut toujours se mettre sur des tags sur les dépendances (ou une branche si le support de semver est réél par le mainteneur).

T'aurais eu, dans ce cas précis, une version native pour padder du texte à gauche

Oui, voila, ça ressemblerait à ce que fait php, ce serait parfait

Un vrai langage

Oui mais donc ça aurait rien changé, Azer aurait quand même pu supprimer ses projets et pêter les builds de tous les ceux qui ont pas un miroir perso. Ça aurait juste limité les dégats dans les grosses boites qui avaient déjà mis en place un proxy ou un repo local.

On pourrait même imaginer un truc de ouf genre une méthode pour le formattage de texte

Ou une méthode pour savoir si un objet est un array direct dans la stdlib

 
C'est quoi le nom de la fonction qui fait ca ?

Ouais mais au moins si il y a un patch de sécurité il sera appliqué automatiquement

 
je suis plus circonspect :  
- si y'a pas de namespace, le mec a pas le choix de nommer son outil forcément autrement
- si il n'exerce pas son droit, il le perd, donc il a pas tellement eu le choix que de le faire (si demain je sors un package XenOrchestra parce que je trouve le nom rigolo, je doute que Plam ne réagisse pas, surtout si il souhaite en publier un aussi)
- le dev de la lib a un peu fait le douchebag, ça lui coutait pas grand chose de changer le nom, et son propos sur le grand capital qui l'empeche de faire ce qu'il veut c'était un poil gamin
 

Dans la majorité des langages c'est plus généralement géré par les fonctions de formattage de texte, genre printf("%3s", str). Python a aussi un str.ljust

À noter qu'en Java, avant Java 1.5 (String.format) t'avais droit à leftPad

La seule différence, c'est que c'était au milieu des 435KB de commons-lang au lieu d'être une lib indépendante, donc c'est probablement mieux ()

Il peut parfaitement nommer son truc kik-api ou kik-messenger ou kik-ws.

Qu'il soit content ou pas ne change rien à rien

C'est absolument pas le cas sur les domaines, pas de raison que ce soit le cas pour un package sans rapport, tant que c'est pas du squatting ça n'a pas de raison d'être un problème. Le droit des marques on lui fait dire n'importe quoi.

Et? En quoi il devrait changer le nom de son projet juste parce qu'un mec en fait la demande? Un mec arrive et dit qu'il veut s'appeler jubijub tu vas lui dire "yes massa" ou tu vas lui dire "désolé c'est mon pseudo et je l'aime d'amour alors non merci"?

Oui enfin vu les menaces qui ont précédé

 
http://php.net/manual/fr/function.str-pad.php

Ah, oui, je vois le scénario.

Mes parents ont eu le même problème si ca te rassure, sauf qu'ils m'ont demandé avant de s'inscrire

 
J'aime bien ton exemple d'apache-commons, mais y'a une nuance à apporter. En gros je vois 4 niveaux de granularité de lib dans la discussion :  
 
1) apache-commons : tout apache commons, des tonnes de trucs pas forcément liés et une grosse majorité de choses dont tu n'auras pas besoin. Personne n'importe tout apache-commons.
2) commons-lang : un subset encore assez large d'apache-commons, c'est ce qu'on va rajouter en dépendance. Si tu utilises peu de choses, c'est pas utile.
3) StringUtils : une classe seule ou un petit groupe de classes cohérentes, c'est une bonne échelle parce que tu ne prends que le strict nécessaire sans forcément faire exploser le nombre de dépendances.
4) isAlphanumeric : une méthode seule. Tu n'as QUE ce dont tu as besoin, mais à ce niveau de granularité on fait exploser le nombre de dépendances.  
 
Et moi j'ai un gros problème avec un très grand nombre de dépendances.
Une dépendance c'est pas gratuit en termes de configuration, mais c'est pas gratuit "physiquement". Pour reprendre l'exemple de isArray, pour une fonction, tu trimballes 8 fichiers, configuration, metadata, build, etc.
Et quand tu sais que les dépendances vont s'aggréger les unes et les autres, t'arrives aux aberrations décrites dans l'article où t'as 25000 fichiers dans un projet vide.
Je sais que les SSD sont rapides, mais quand même.
 
 
Les bonnes granularités sont les granularités 2 et 3. La 2 donne un avantage à celui qui package (ça reviendrait à grouper des releases de dépendances de niveau 3), la 3 donne un contrôle plus fin à l'utilisateur.
 

 
Le problème c'est pas d'avoir accès à des fonctions, c'est avoir accès à des fonctions éparpillées dans tous les sens.
En termes de cohésion du code, ça n'a strictement aucun sens de séparer certaines fonctions. C'est comme si d'un coup, le concept d'interface devenait caduc.
 
Pour une bonne tranche de rire, https://www.npmjs.com/package/pad-left, avec toute la collection de fonctions accompagnantes, qui pourraient se résumer à une ou deux dépendances au total, sans plus.
Mais non, visiblement dans le monde du JS on aime bien se tartiner des millions de téléchargements séparés
 
 

 
Ah bon ? Le système de noms de packages de Java (qui sont en gros des hostnames à l'envers, e.g. fr.hardware.forum) permet d'éviter de façon assez habile les collisions en intégrant la notion d'organisation.
Si Jean Duschmole et la World Company ont un package docker-client, t'auras fr.duschmole.docker-client et com.worldcompany.docker-client.
 
Problem solved.
 

 
Non mais comme tu l'as dit, leur politique les rend fragiles.

Une stdlib correcte réduit le besoin pour des dépendances qui couvrent des choses très basiques.
Du coup t'as peu de chances d'avoir un "left-pad" ou un "isArray".

+1 avec Mask
Mais je rajouterais l'url qu'on a vu passé en boucle pendant 2 jours suite a cette affaire : https://www.eff.org/deeplinks/2013/ [...] r-internet
La lib originelle est opensource et n'est pas dans le scope de ce que fait la companie.  
Donc pas de confusion possible et ça aurait difficilement tenu au niveau légal.

D'accord aussi avec masklinn sur la question du "kik" et la connerie de npm, mais en gros ça ne serait pas arrivé avec un mécanisme de groupId à la maven, qui force de base les gens à aller dans des namespaces différents.

 
Et si la world company s'appelle Duschmole ?

Bah elle sera com.duschmole, qui est différent de fr.duschmole.

Par contre si t'as le Duschmole de Picardie et celui de NPDC, bah c'est premier arrivé premier servi. Le namespacing va juste réduire (de pas mal généralement) les chances de conflit. En théorie c'est un reverse du domaine, donc l'unification est faite là dessus, mais ça gère pas trop le cas où les boites ont pas de domaine (et prennent un truc arbitraire) où les cas où un domaine change de main.