Problèmes de fiablité de npm #1529
Comments
A la base npm part du principe que tu as du cache, là on re DL tout à chaque installation : c'est pas du tout prévu pour fonctionner comme ça.
Ca n'existe pas. C'est le repo officiel. Le seul moyen d'optimiser tout ça c'est de créer un miroir et de dire à npm d'aller chercher les choses sur ce miroir et non sur le registry global. |
|
Bah même si c'est pas prévu pour fonctionner comme ça, c'est flippant un outil qui te plante une primo-installation sur 10... Et personnellement je n'ai aucun scrupule à dégager node.js s'il t'oblige à travailler avec des outils non fiables. |
|
Si tu retire node.js, tout le front ne fonctionne plus, tout simplement. |
|
J'ai ri en lisant cette issue Et PIP qui faisait planter le build travis, on en parle ? C'est vrai ça, pourquoi vous inclueriez pas toutes les dépendances Python dans le répo direct, huh ? Comme ça, on est sûr de pas être dépendant de pip le jour ou il y a un problème... Non sérieusement, tu nous demandes de virer notre gestionnaire de dépendances... C'est complètement absurde! |
|
Non, je me contente de remettre en cause le choix de l'outil à l'origine. D'autre part, le problème de PIP a été réglé. Celui de NPM, ça fait Le 24 septembre 2014 20:25, Sandhose notifications@github.com a écrit :
|
C'est complètement fou que je n'ai jamais entendu quelqu'un me dire "Oh, mon install marche pas, NPM plante à l'install". Le SEUL cas ou on a ça, c'est pendant les build travis... Après, si tu y tiens, on peux très bien se faire chier à louer un serveur juste pour faire un registry npm si jamais celui officiel ne répond plus! Et puis autant faire pareil avec un dépot apt et un dépot pip, comme ca on est certain que tous nos tests passeront! Dans tous les cas, on a besoin de node pour linter le JS (y'en a qui demandent qu'on test le front, nan ?). Après, si tu tiens à revoir l'époque ou on avait des diffs énorme juste pour une petite règle CSS changée, pourquoi pas... Une autre solution serait de passer à Travis Pro (bien sûr, c'est pas moi qui vais payer), qui supporte le cache npm, comme ça on est certain que le build passera à tout le coup! Plus sérieusement, on songera à ne plus utiliser npm lorsque vous n'utiliserez plus pip. Tu as mon avis et ma condition pour la "résolution" de cette issue mineure et complètement insensée. |
|
Bon l'issue est rédigée en mode troll mais il y a un vrai problème derrière. En trois points :
Le point 4 est sans doute qu'à ma connaissance, on a une seule personne dans l'équipe qui maîtrise correctement cet outil. Bref. Une question se pose : Est-ce que NPM sert à quelque chose d'autre que du build ? Si oui, c'est un outil de build (comme Maven en Java). Et comme tout outil de build, il n'a rien à faire en prod, il devrait être cantonné à un environnement de build. Et on met en prod les paquet déjà buildé. Principaux intérêts :
Notez que tout ceci s'applique à tout outil de build et n'est pas spécifique à NPM. Question si c'est bien un outil de build : comment gérer Travis ? Question si c'en est pas un : comment améliorer la fiabilité de la chose ? |
tl;drnpm est un outil de build, on pourrais balancer le paquet déjà build sur la prod, et host les dépendances npm autre part pour Travis En détail:En soit, npm sert à installer les différents outils qui servent à build, c'est à dire (selon le package.json, en enlevant les plugins purement utilitaires):
Note: Tous ces outils sont installés dans le dossier Ces outils servent donc à build le front, et à vérifier la syntaxe. Tout ce qui se trouve dans le dossier Pour la prod, on peut donc utiliser une version déjà compilée. Pour travis, j'ai vu que Bootstrap, par exemple, contournais ce problème en hébergeant le dossier node_modules sur un AWS. Une solution similaire peut être envisagée. |
Ca va pas être problématique pour les choses qui sont recompilées ? Car j'avais pensé à ça, mais certains modules tapent dans
On la build où ? Comment ? Avec quels moyens ? La réponse est pour moi simple : celui qui met en prod le fait à partir d'une branche dédiée (celle de la stabilisation par exemple) fait un build en local, force l'ajout de Le problème : ceux qui mettent en prod n'ont pas les outils pour et n'ont pas souhaité les installer jusqu'ici. Il faut donc que ceux qui fassent les mises en production installent ces outils et sachent faire un build |
|
C'est moi ou c'est encore |
|
Je dirais juste que npm est pas à jour env de test (1.4.14 vs 2.1.0)... Et |
|
On peut en parler ici : http://zestedesavoir.com/forums/sujet/1564/rationalisation-des-outils-de-developpement/ |
|
Normalement le problème avec Travis est corrigé. À rouvrir si la correction ne suffit pas. |
C'est corrigé pour travis, mais est-ce que c'est corrigé pour les MEPs ? |
|
J'avais proposé d'investiguer avec SpaceFox y'a un moment, mais ça ne s'est finalement pas fait. Avec les ajouts de la v2.0 de npm, il y a possibilité de n'avoir que npm/node comme dépendance, et que l'on ai plus besoin de gulp/bower d'installé. Ca permet notamment d'être en non-root tout le temps quelque soit l'installation, et de réduire les erreurs liés aux permissions. Je vais faire une issue expliquant ce qu'il y à faire, et ce que ça permetterait |
|
Visiblement la solution proposée en #1734 ne suffit pas si j'en crois ce commentaire : #1747 (comment) |
|
D'ailleurs nos dépendances npm sont rouges. Elles sont carrément out-of-date. Il faudrait penser à la MAJ : |
|
@SpaceFox Le problème est que vu que le build a été relancé, je ne retrouve pas les logs... Sinon, j'ai vu une erreur par rapport à node-sass... Je suis suis en train de voir si c'est une erreur récurrente, et si je peux éventuellement trouver comment fixer ça... (Même si la, je vois pas trop, puisque ça a l'air de dépendre de l'environnement de build) |
|
Ca a vraiment sa place en v1.3 ca ? |
|
Bah si le problème est réglé, oui. |
|
Bah vu que je vois une PR qui n'est pas mergé je me demande... |
|
Si tu parles de la #1752, elle est prête, je viens de la QA ! Le 27 novembre 2014 19:36, Eskimon notifications@github.com a écrit :
|
|
Ouai mais ca change rien, la V1.3 est fermé puisqu'en preprod |
|
Bah du coup vu qu'il y a (je crois) des PR en v1.3 et des PR en v1.4 pour 2014-11-27 19:39 GMT+01:00 Eskimon notifications@github.com:
|
|
NPM a planté récemment ? Si non, on peut fermer ! |
|
Il a planté y'a pas moins de quelques jours je crois. J'ai du relancer le firm1
|
|
Je pense qu'on peut fermer ici. Qu'un build plante ça peut arriver, on est pas au 1/3 constaté fut une époque. |
|
assez d'accord avec @gustavi |
|
Je ferme, on ré-ouvrira si on a de nouveaux des problèmes. |
NPM est un outil tout sauf fiable. On a une proportion délirante de builds Travis qui finissent en :
Soyons clairs : c'est insupportable.
Donc il devient indispensable de :
The text was updated successfully, but these errors were encountered: