Tâches / améliorations Alstart v2 ?

[raphaelgoetter]

Je propose de faire quelques améliorations à Alstart :

1. tâche Minify : plutôt que d'utiliser gulp-minify-css , je propose d'utiliser gulp-csso qui semble plus performant (même si ça ne doit pas changer grand chose au final)
2. tâche gulp-load-plugins : je propose de l'utiliser parce que je la trouve super pratique pour éviter de devoir faire les require à la main : http://andy-carter.com/blog/automatically-load-gulp-plugins-with-gulp-load-plugins
3. tâche gulp-sync : à utiliser dans le cas de tâches à exécuter dans un ordre précis, généralement la tâche de prod : https://www.npmjs.com/package/gulp-sync
4. une tâche de Build et une tâche de Prod ? (cf. issue https://github.com/alsacreations/alstart/issues/2)
5. je propose de ne pas intégrer par défaut les tâches unCSS et critical (ce qui est déjà le cas d'ailleurs) : elles sont très utiles mais pas forcément à employer par défaut sur tous les projets
6. tâche gulp-html-extend (celle qui permet de faire des includes en HTML "pur") : à débattre. Elle me semble très pratique pour livrer du statique à un client. Au pire, si la tâche n'inclut rien, elle sert à cloner simplement les fichiers HTML de src vers dist
7. plusieurs m'ont dit du bien de gulp-plumber en guise de bonne pratique. À débattre ?
8. Quid d'installer les node modules en global une fois pour toutes ? cf. http://simblestudios.com/blog/development/gulp-saving-disk-space.html
9. gulp-styledown me semble bien pratique mais j'ai vraiment du mal à obtenir un résultat vraiment parlant (http://goetter.fr/styleguide.html). Du coup, sans explications ou template, je le trouve relativement peu intéressant

Bon alors, on en discute ?

[raphaelgoetter]

Je ping @alsacreations/les-coupains

[edenpulse]

1. L'avantage de gulp-minify-css c'est qu'il est compatible aussi avec la generation de sourcemaps, et surtout toutes les options suivantes : https://github.com/jakubpawlowicz/clean-css#how-to-use-clean-css-programmatically
2. Oué pas mal :)
3. Je pense qu'utiliser un outil qui "Gruntise" Gulp n'est peut-être pas terrible. Normalement, quand tu as toujours moyen d'écrire tes tâches pour que ça fonctionne dans un certain ordre. T'aurais un contre-exemple ?
4. Me parait important
5. Je valide
6. Pas d'avis sur la question
7. ça à l'air cool
8. ça à pas grand chose à faire avec le code ça, plutôt une pratique à adopter personnellement non ?
9. Je ne pense pas qu'il faille s'inquiéter du styleguide quand l'on est à l'étape du code en fait. Il devrait être réalisé déjà avant. Je n'en trouve pas l'utilité personnellement.

[raphaelgoetter]

Merci @edenpulse , t'es preums :)

1. OK pour les sourcemaps sur le principe. Mais :
   • pour l'instant on les a désactivées parce qu'elles foirent la minification (les styles CSS sont tout cassés)
   • qui s'en sert en pratique ?
2. ok
3. En général c'est sûr qu'il est plus intéressant de tout asynchroniser. Ce n'est pas un souci pour une tâche de Build. Par contre, pour avoir testé des choses comme Critical ou unCSS, il est obligatoire que ces tâches se fassent dans un ordre précis. Du coup, pour la tâche finale de Prod (celle qu'on ne fait qu'une fois ou deux dans un projet), ça me semble plus sûr
4. ok
5. ok
6. ok
7. ok
8. c'est vrai que c'est plutôt un choix personnel. Mais j'aimerais savoir s'il y a vraiment des inconvénients parce que moi je trouve ça hyper pratique
9. Là aussi sur le principe, ce serait génial. Surtout pour le client : il aurait un aperçu du visuel final des éléments importants de la page (titres, textes, mais aussi surtout boutons et autres éléments d'interface) et la classe CSS correspondante. Idéal pour intégrer ensuite les livrables statiques qu'on lui file. En théorie en tout cas ;)

Bon week-end ;)

[blupdew]

1. sourcemaps : je pense que ce n'est pas parce que tout le monde ne s'en sert pas (alors qu'on devrait) que cela les rend useless, au contraire cela devrait être un encouragement à s'y mettre ;)
2. les require à la main ne prennent pas tant de temps que ça et on peut les nommer ? mais pas très important...
3. ok
4. ok
5. ok
6. ok, soit, pour les récents projets clients concernés toutefois on ne s'est pas limités à des includes simples donc PHP devenait nécessaire (faire du random, utiliser des variables, etc) - même pour une livraison de HTML
7. il paraît
8. pas d'avis à ce moment
9. c'est le styleguide le plus simple que j'ai pu trouver, la doc explique comment cela fonctionne (syntaxe) https://github.com/styledown/styledown - il y en a d'autres plus puissants mais plus complexes aussi. l'intérêt de l'inclure à la phase code c'est 1) de réfléter les modifications/adaptations éventuelles qui arrivent souvent 2) d'avoir quelque chose de toujours à jour comme référence 2.1) pour l'intégrateur 2.2) pour le client 2.3) pour les tests navigateurs

[raphaelgoetter]

@blupdew

Sourcemaps : j'ai beau me dire que c'est utile et me forcer, j'ai vraiment du mal à les trouver vraiment utiles. Mais je suis open au changement.

HTML-extend : les variables sont fonctionnelles. Par contre, oui, il n'est pas prévu de random, de fonctions, etc.

Styledown : Je confirme qu'il semble excellent, par rapport à d'autres que j'ai survolé. Je pense qu'il me faut un exemple en live expliqué parce que même en me tapant la doc je ne comprends rien à la syntaxe "à la jade" :

h1 My Awesome Styleguides
    div#styleguides(sg-content)

Il faudrait vraiment l'intégrer à la refonte Alsa.fr, ça nous donnerait un exemple concret de styledown

[hiwelo]

1. Minify : Perso, je teste CSSO en ce moment et je le trouve vraiment pas mal, et il existe pas mal d'options. Après ce que soit minify-css, clean-css ou csso, tout me va. Côté sourcemap, je ne m'en sers pas sur les projets que j'ai intégré, vu que je connais mon rangement ^^ mais oui, ça peut être utile, notamment sur des projets complexes très modulaires.
2. gulp-load-plugins : Plugin Gulp vraiment pas mal, je l'ai essayé quand tu m'en as parlé et depuis il est adopté de mon côté :smile_cat:
3. gulp-sync : J'ai du mal à voir l'intérêt, même dans le cadre de la mise de prod je ne vois pas quel problème il vise à résoudre. Les scripts JS & CSS sont peut-être exécutés en même temps mais ce n'est pas grave à mes yeux puisque l'important c'est l'ordre des tâches dans les pipes et là, c'est fixe :) Mais au pire, ça n'allourdi rien donc pareil, ça ne me dérange pas.
4. built & prod : accompagné du gitignore file que j'ai mis en pull request (#5) c'est plutôt une bonne chose pour ne pas s'en soucier lors du dev et avoir les deux canaux existants à la livraison. Dans cette optique, on peut aussi réfléchir au git flow à appliquer : une branche master dédiée aux livraisons avec un gitignore qui n'exclue pas le répertoire dist/ et une branche develop qui centralise les développements en cours qui ignore dist/ et les vendors. Qu'est-ce que vous en pensez ? Comme ça, chacun bosse dans sa branche, et merge dans develop et il n'y a qu'une seule personne par projet qui est responsable de merger develop avec master.
5. unCSS & CriticalCSS : je suis d'accord, c'est à voir projet par projet et selon le budget du client non ? C'est une prestation différente de l'intégration à mes yeux, une prestation de performance (pour critical CSS) vous pensez pas ? (presta performances avec criticalCSS, lazy loading, réflexion sur les fonts, etc. non ?)
6. gulp-html-extend : pas encore testé mais je ne vais pas tardé sur la refonte de mon site perso, j'ai hâte d'essayer :smiley_cat:
7. gulp-plumber : j'en ai marre de devoir relancer mon gulp && gulp watch à chaque erreur, donc je veux bien tester sur mon prochain projet d'intégration :wink:
8. node modules : on ne sait jamais qui va bosser sur nos projets, pourquoi et comment, ça ne me gêne pas de les installer à chaque projet. Avoir le répertoire node_modules en .gitignore permet d'éviter de stocker en git cela et puis l'installation ne se fait qu'une fois en début de projet non ? :wink:
9. gulp-styledown : ça à l'air cool :)

[raphaelgoetter]

Pour gulp-sync oui on est d'accord : tant qu'on est dans le pipe, il ne sert à rien. Je pense qu'il ne sera nécessaire que dans le cas ou on utilise des tâches telles que Critical ou unCSS, où il est obligatoire que ces tâches se fassent dans un ordre précis. Du coup, pour la tâche finale de Prod (celle qu'on ne fait qu'une fois ou deux dans un projet), ça me semble plus sûr.

Bien vu aussi pour la réflexion sur unCSS, Critical, lazyloading et fonts.

[hiwelo]

Pour info, je viens de tester gulp-plumber sur un de mes projets personnels là, il ne permet pas d'éviter le crash de la task watch lors d'une erreur JS ou CSS. Il permet uniquement d'avoir un affichage plus intelligible de l'erreur que j'ai provoqué.

[hiwelo]

Par contre, voici un extrait de mon fichier Gulp perso avec lequel j'ai réussi à retirer le crash de la tâche watch lors d'une erreur : (en gros, la fonction et l'appel qui règle le soucis :wink: )

function onError(err) {
  console.log(err);
  this.emit('end');
}

gulp.task('css', function () {
  return gulp.src(source + '/css/styles.less')
    .pipe(plugins.less())
    .on('error', onError)
    .pipe(plugins.autoprefixer())
    .pipe(plugins.csso())
    .pipe(plugins.rename({
      suffix: '.min'
    }))
    .pipe(gulp.dest(prod + '/css/'));
});

[geoffreycrofte]

Combiné à https://github.com/mikaelbr/gulp-notify ça peut faire des miracles, presque comme du Prepros à la bonne époque ;)

[hiwelo]

Cool, je testerais ça demain matin ! C'est effectivement une combinaison qui peut être plutôt sympa :)

[raphaelgoetter]

Bon, un mois après, je relance de 15 et essaye de faire un résumé :

1. Minify : On remplace par CSSO (qui ne foire pas quand on essaye de faire des maps) ?
2. gulp-load-plugins : On adopte officiellement ?
3. gulp-sync (obligatoire si on utilise des plugins séquentiels tels que unCSS ou Critical) : On adopte ou pas ?
4. built & prod (= avoir 2 canaux "build" et "prod") : On adopte ou pas ? Si oui il faut discuter de la meilleure manière de procéder : @hiwelo a proposé une variante qui pourrait être intéressante.
5. unCSS & CriticalCSS : On vote officiellement pour ne pas les ajouter par défaut ?
6. gulp-html-extend : Tâche non systématique. Cependant, elle ne "casse" rien s'il n'y a pas d'extend (elle ne fait juste rien). On adopte officiellement ou pas ?
7. gulp-plumber : On adopte officiellement ou pas ?
8. node modules : On laisse tomber les liens virtuels. Confirmé ?
9. gulp-styledown : Je n'arrive toujours pas à le faire fonctionner. Il me faut un VF-TP

à vous...

[hiwelo]

De mon côté, mon avis n'a pas changé : Je suis partant totalement partant pour csso, gulp-load-plugins, gulp-html-extend (même si je pense continuer les inclusions PHP, mais au final ça ne change rien à mon workflow).

Côté gulp-plumber, je n'ai finalement pas vu d'intérêt à l'installer lors de mes tests. Et j'ai résolu de mon côté le soucis de gulp watch arrêté en cas d'erreur sans l'utiliser.

Côté build & prod, je m'adapterais quoi qu'il arrive ;)

[raphaelgoetter]

csso vien de remplacer minify-css :)

On avance comme des oufs !

[hiwelo]

:tada:

[raphaelgoetter]

Hopla.

Je reviens à Gulp-Plumber. Effectivement, de base il n'empêche pas le crash du Watch.

Par contre, de cette manière ça me semble résolu dans tous mes tests (= le watch continue à opérer) :

.pipe(plumber({
        handleError: function (err) {
            console.log(err);
            this.emit('end');
        }
    }))

[raphaelgoetter]

Toujours est-il que Alstart v2 est en marche : nous avons un VendredyFriday cet aprèm, je ferai un résumé pour les absents :)