deudtens a écrit: Je vais te donner mon avis, mais c'est purement subjectif : je hais l’écosystème JS du moment. Ya des dizaines d'outils différents pour le même but, aucun qui se détache vraiment, la hype qui passe de l'un à l'autre en quelques mois... c'est simple, entre les gulp, grunt, bower, je suis peaumé. J'ai toujours eu des problèmes pour installer nodjs + npm sur des serveurs et environnements de dev : le nom du binaire change, npm est parfois fourni en dépendance, parfois pas... bref, ça m'a saoulé.
Bon sur tout ça, je plussoie (même si bon sur le dev, t'as ça tous les jours, ah mais pourquoi t'utilises symfony et pas laravel ou phalcon). Bref j'ai toujours fonctionné avec le minimum syndical, sauf que je me suis dit, bon on va quand même tester et force est d'admettre que quand ça fonctionne, ça fait bien le boulot. Après ça me saoule toute la config en amont, car je déteste ça et le fait que tout n'est pas bowerisable... donc pour le moment on a clairement pas un environnement parfait. Par contre ne suis pas du tout sûr de l'intérêt d'installer nodejs + npm sur un serveur, je pense que la machine de dev doit l'avoir et l'utiliser et on peut inclure les assets qui ont été buildés automatiquement dans le git. Du coup, tu t'évites pas mal de boulot de config et potentiellement le mec qui ne fait que du back n'en a rien à battre et n'a même pas à s'occuper de ça.
deudtens a écrit: Du coup j'utilise assetic, et j'ai zéro runtime js sur la stack de mon projet perso en cours de développement. Assetic fournit un truc qui fait du cache busting en donnant des suffixes à tes fichiers css et js. Assetic, c'est lourd, c'est du php, ce n'est plus hype, mais j'en ai absolument rien à foutre.
La hype et moi sur le dev ça a toujours fait 2, donc c'est pas vraiment le but recherché.
deudtens a écrit: Par contre, gros bémol, ça ne le fait pas pour les fichiers images. Pour l'instant j'ai pas encore cherché si yavait quelque chose de tout prêt pour le faire, mais ya environ 5 ans, j'avais fait un truc un peu moche :
- lors du déploiement, je fais un coup de sed dans mon fichier css pour remplacer les noms des images ainsi : toto.jpg -> toto-dyn123456789.jpg . 123456789 correspond à la date du déploiement ou un numéro de version.
- au niveau du serveur qui héberge les images (c'était un apache je crois), je rajoute une regex qui traduit un truc dans ce genre (syntaxe inventée, mais tu vois l'idée j'espère) : (.*)(-dyn)([0-9]*).(.*) -> (1).(4)
L'inconvénient avec cette méthode, c'est que tu niques le cache de toutes les images au moindre déploiement. Quand je me suis barré, certains ont repris le truc et on fait en sorte que ce qui se trouve derrière le dyn soit un hash du fichier de l'image, qui ne changerait donc pas si l'image restait la même.
Bon j'ai rencontré les même limites que toi avec assetics, mais le projet n'étant pas terminé, j'ai laissé un peu de côté, mais je comptais utiliser compass (vu que j'ai encore compass sur ce projet) pour gérer le cache/versioning des images. Après dans mon souvenir, j'avais un problème de copie de certains fichiers.
Bon ça me rassure sur ce que j'ai toujours fait, mais du coup tu me fais hésiter sur un nouveau projet à bazarder mon grunt. Mais vu que symfony a jarté assetics de base, je pense que symfony se dirige doucement vers une sortie totale d'assetics. Donc je pense faire une passe Grunt (compilation sass, concaténation, compression css et js) et intégration dans twig avec asset.
|
. Sur mes projets perso, j'utilise un jenkins sur mon serveur perso qui build et qui déploie une fois les tests validés. Jsuis pas trop fan non plus du déploy à partir du poste de dev, j'ai peur d'effets de bord induits par l'environnement.