Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problèmes de fiablité de npm #1529

Closed
SpaceFox opened this issue Sep 24, 2014 · 31 comments
Closed

Problèmes de fiablité de npm #1529

SpaceFox opened this issue Sep 24, 2014 · 31 comments
Labels
Milestone

Comments

@SpaceFox
Copy link
Member

@SpaceFox SpaceFox commented Sep 24, 2014

NPM est un outil tout sauf fiable. On a une proportion délirante de builds Travis qui finissent en :

The command "npm install" failed and exited with 34 during .

Soyons clairs : c'est insupportable.

Donc il devient indispensable de :

  • Soit trouver un moyen de fiabiliser cette chose
  • Soit lui trouver une alternative
@Alex-D

This comment has been minimized.

Copy link
Contributor

@Alex-D Alex-D commented Sep 24, 2014

Soit trouver un moyen de fiabiliser cette chose

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.

Soit lui trouver une alternative

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.

@SpaceFox

This comment has been minimized.

Copy link
Member Author

@SpaceFox SpaceFox commented Sep 24, 2014

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.

@Alex-D

This comment has been minimized.

Copy link
Contributor

@Alex-D Alex-D commented Sep 24, 2014

Si tu retire node.js, tout le front ne fonctionne plus, tout simplement.

@sandhose

This comment has been minimized.

Copy link
Member

@sandhose sandhose commented Sep 24, 2014

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!

@SpaceFox

This comment has been minimized.

Copy link
Member Author

@SpaceFox SpaceFox commented Sep 24, 2014

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
littéralement des mois qu'on se le traîne, et la seule réponse que j'ai
c'est "LOL c'est pas réparable".

Le 24 septembre 2014 20:25, Sandhose notifications@github.com a écrit :

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!


Reply to this email directly or view it on GitHub
#1529 (comment)
.

@sandhose

This comment has been minimized.

Copy link
Member

@sandhose sandhose commented Sep 24, 2014

Celui de NPM, ça fait littéralement des mois qu'on se le traîne

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.

@SpaceFox

This comment has been minimized.

Copy link
Member Author

@SpaceFox SpaceFox commented Sep 24, 2014

Bon l'issue est rédigée en mode troll mais il y a un vrai problème derrière. En trois points :

  1. J'ai des problèmes de NPM genre à la moitié des déploiements.
  2. Malgré 4 modifications de ces deux lignes https://github.com/zestedesavoir/zds-site/blob/dev/server/deploy.sh#L41 on a toujours pas été foutus de les faire fonctionner
  3. Le système me plante 1/10è des builds Travis. Je ne sais pas si c'est NPM lui-même ou le serveur ou que sais-je : si le composant défectueux n'est pas remplaçable, c'est toute la chaîne qui déconne et donc toute la chaîne qui est problématique.

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 ?
Autrement dit : est-ce qu'il est utilisé pendant le fonctionnement du site, à un autre moment qu'au déploiement ?

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 :

  1. On ne déploie pas des outils qui ne servent pas sur le serveur de prod (moins de risque de plantage, moins de surface d'attaque)
  2. On garantit que la même version est livrée partout

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 ?

@sandhose

This comment has been minimized.

Copy link
Member

@sandhose sandhose commented Sep 24, 2014

tl;dr

npm 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):

  • gulp: Task-runner qui "orchestre" tout le build, selon le Gulpfile.js
  • gulp-autoprefixer: Permet de préfixer automatiquement le CSS pour assurer la compatibilité avec la plupart des navigateurs
  • gulp-cache: Permet de "mettre en cache" une partie du build, pour gagner du temps
  • gulp-clean: Plugin pour supprimer un dossier/fichier (gulp clean supprime le dossier dist/)
  • gulp-concat: Permet de fusionner plusieurs fichiers (ex: les différents fichiers JS
  • gulp-imagemin: Optimise les images
  • gulp-jshint: Vérifie la syntaxe du JS
  • gulp-livereload: Plugin utile au développement ; permet de "recharger" le JS/CSS pendant l'édition, sans recharger la page manuellement
  • gulp-minify-css: Minifie le CSS
  • gulp-newer: Détermine si un fichier a été modifié ou non (s'il faut le recompiler ou non)
  • gulp-rename: Permet de renommer un fichier (genre main.css -> main.min.css)
  • gulp-sass: Compile les fichiers SCSS en CSS
  • gulp-size: Affiche dans la console la taille de certains fichiers
  • gulp-uglify: Minifie le JS
  • gulp-zip: Permet la création d'un zip (en l’occurrence, le pack.zip)
  • gulp.spritesmith: S'occupe de la création du sprite
  • jshint-stylish: Affichage des erreurs JSHint
  • main-bower-files: Utilisé pour "récuperer" les fichiers des dépendances bower (type jQuery ou autre)

Note: Tous ces outils sont installés dans le dossier node_modules/

Ces outils servent donc à build le front, et à vérifier la syntaxe. Tout ce qui se trouve dans le dossier dist/ est généré par ce build.

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.

@Alex-D

This comment has been minimized.

Copy link
Contributor

@Alex-D Alex-D commented Sep 25, 2014

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 ~/.node si je ne me trompe pas :/

Pour la prod, on peut donc utiliser une version déjà compilée.

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 /dist et tag ce commit comme étant la dite version. C'est ce que je fais pour mon plugin WYSIWYG et sa disponibilité en version buildé sur Bower.

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 gulp pack (plus simple on meurt).

@SpaceFox

This comment has been minimized.

@Alex-D

This comment has been minimized.

Copy link
Contributor

@Alex-D Alex-D commented Sep 29, 2014

C'est moi ou c'est encore image-min qui fou son brin @sandhose ?

@sandhose

This comment has been minimized.

Copy link
Member

@sandhose sandhose commented Sep 29, 2014

Je dirais juste que npm est pas à jour env de test (1.4.14 vs 2.1.0)... Et
que les env. travis sont pas totalement clean, ce qui fait planter npm 1x
sur 2...

@firm1

This comment has been minimized.

Copy link
Contributor

@firm1 firm1 commented Oct 31, 2014

@SpaceFox

This comment has been minimized.

Copy link
Member Author

@SpaceFox SpaceFox commented Nov 12, 2014

Normalement le problème avec Travis est corrigé.

À rouvrir si la correction ne suffit pas.

@SpaceFox SpaceFox closed this Nov 12, 2014
@firm1

This comment has been minimized.

Copy link
Contributor

@firm1 firm1 commented Nov 12, 2014

À rouvrir si la correction ne suffit pas.

C'est corrigé pour travis, mais est-ce que c'est corrigé pour les MEPs ?

@sandhose

This comment has been minimized.

Copy link
Member

@sandhose sandhose commented Nov 12, 2014

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

@sandhose

This comment has been minimized.

Copy link
Member

@sandhose sandhose commented Nov 12, 2014

cf. #1739

@Situphen est sur le coup 👍

@SpaceFox

This comment has been minimized.

Copy link
Member Author

@SpaceFox SpaceFox commented Nov 14, 2014

Visiblement la solution proposée en #1734 ne suffit pas si j'en crois ce commentaire : #1747 (comment)

@SpaceFox SpaceFox reopened this Nov 14, 2014
@firm1

This comment has been minimized.

Copy link
Contributor

@firm1 firm1 commented Nov 14, 2014

D'ailleurs nos dépendances npm sont rouges. Elles sont carrément out-of-date.

Il faudrait penser à la MAJ : Dependency Status

@sandhose

This comment has been minimized.

Copy link
Member

@sandhose sandhose commented Nov 15, 2014

@firm1 Corrigé dans #1752

@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)

@Eskimon

This comment has been minimized.

Copy link
Member

@Eskimon Eskimon commented Nov 27, 2014

Ca a vraiment sa place en v1.3 ca ?

@Situphen

This comment has been minimized.

Copy link
Contributor

@Situphen Situphen commented Nov 27, 2014

Bah si le problème est réglé, oui.

@Eskimon

This comment has been minimized.

Copy link
Member

@Eskimon Eskimon commented Nov 27, 2014

Bah vu que je vois une PR qui n'est pas mergé je me demande...

@Situphen

This comment has been minimized.

Copy link
Contributor

@Situphen Situphen commented Nov 27, 2014

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 :

Bah vu que je vois une PR qui n'est pas mergé je me demande...


Reply to this email directly or view it on GitHub
#1529 (comment)
.

@Eskimon

This comment has been minimized.

Copy link
Member

@Eskimon Eskimon commented Nov 27, 2014

Ouai mais ca change rien, la V1.3 est fermé puisqu'en preprod

@Situphen

This comment has been minimized.

Copy link
Contributor

@Situphen Situphen commented Nov 27, 2014

Bah du coup vu qu'il y a (je crois) des PR en v1.3 et des PR en v1.4 pour
cette issue, je dirai qu'il faut mettre v1.4.

2014-11-27 19:39 GMT+01:00 Eskimon notifications@github.com:

Ouai mais ca change rien, la V1.3 est fermé puisqu'en preprod


Reply to this email directly or view it on GitHub
#1529 (comment)
.

@Situphen

This comment has been minimized.

Copy link
Contributor

@Situphen Situphen commented Dec 12, 2014

NPM a planté récemment ? Si non, on peut fermer !

@firm1

This comment has been minimized.

Copy link
Contributor

@firm1 firm1 commented Dec 13, 2014

Il a planté y'a pas moins de quelques jours je crois. J'ai du relancer le
build de travis.

firm1
Le 13 déc. 2014 00:30, "Situphen" notifications@github.com a écrit :

NPM a planté récemment ? Si non, on peut fermer !


Reply to this email directly or view it on GitHub
#1529 (comment)
.

@gustavi

This comment has been minimized.

Copy link
Member

@gustavi gustavi commented Dec 13, 2014

Je pense qu'on peut fermer ici. Qu'un build plante ça peut arriver, on est pas au 1/3 constaté fut une époque.

@Eskimon

This comment has been minimized.

Copy link
Member

@Eskimon Eskimon commented Dec 13, 2014

assez d'accord avec @gustavi

@gustavi

This comment has been minimized.

Copy link
Member

@gustavi gustavi commented Dec 13, 2014

Je ferme, on ré-ouvrira si on a de nouveaux des problèmes.

@gustavi gustavi closed this Dec 13, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.