Templating du projet

[enguerranws]

Actuellement, on part des principes que :

• l'hébergement devra se faire sur les pages Github
• le projet est ouvert aux pros et aux étudiants (enfin, dans l'absolu : à tout le monde)

Pour l'hébergement, si c'est bien le cas, il faut une solution qui produise un site statique.
Si ça ne l'est pas , on peut s'affranchir de cette règle et utiliser PHP : les étudiants le voient en cours, tous les pros ont PHP sur leur machine (enfin tout ceux que je connais pour être exact :) ), on ajouterait pas une dépendance trop compliquée à gérer. Pour Node / NPM, même si je suis un gros consommateur, les étudiants ne le voient pas en cours et ça implique des manipulations supplémentaires.

Plus largement, on pourrait même penser à d'autres solutions, qui pourraient coller avec Github pages, comme du templating à base de WebComponents par ex, ou simplement JS pour s'occuper de layout (sans dépendance).

Toutes ces solutions ont leur pour et leurs contre, j'aimerais déjà bien voir les contraintes qu'on se pose.

[YannisDelmas]

J'imaginais que les étudiants et pros n'utiliseraient que le site public https://yannisdelmas.github.io/beau-code-web. Seuls les contributeurs auraient besoin du système de templating.

J'avais deux objectifs principaux:

• Templating des pages et des recommandations, histoire d'avoir un aspect homogène et une meilleure maintenabilité.
• Modularisation, histoire d'avoir un fichier pour chaque recommandation et éviter de se marcher sur les pieds (côté git) en travaillant sur plusieurs recommandations en parallèle dans des branches différentes. Cf. modularisation #14.

Comme l'hébergement de Github ne propose que du statique, cela exclut PHP.

Le templating JS côté client me semble possible pour la mise en page, pourquoi pas, mais pas pour la modularisation, à cause du référencement.

Il reste donc la compilation des pages en amont du Git. Je ne vois que ça. Pour ça, je n'ai trouvé que make si on prend du PHP, ou les gestionnaires de tâche basés sur Node.js (Grunt, Gulp, Webpack…). Normalement les spécialistes du web susceptibles de contribuer ne devraient pas avoir de problème avec NPM, je dirais.

[enguerranws]

Ah, je comprends mieux. Pour ma part, je pensais que :

• potentiellement, les étudiants ou d'autres pros pourraient être amené à contribuer
• on était pas spécialement arrêté sur Github Pages

Si c'est le cas, effectivement, il faut passer par un task runner, ou Webpack (mais je ne suis pas sûr qu'il serait intéressant sur ce projet).

Cela implique plusieurs choses selon moi :

• mettre en place des commandes de watch et de build (a minima) via NPM
• mettre en place l'outil sans avoir besoin d'installation au global (toujours via NPM :) )
• il faudra penser à préciser la/les version/s de Node compatibles : sur ces outils, une version = une version de Node (souvent) et probablement indiquer d'utiliser NVM aux contributeurs via le Readme

[YannisDelmas]

J'imagine bien que des pros pourront contribuer, mais je suppose qu'ils auront un niveau suffisant pour comprendre le README et exécuter les quelques commandes au demeurant assez simples (quand on a NPM).

Pour le NPM, si je ne me suis pas trompé (je n'ai pas bien l'habitude de l'outil), tout est bien installé en local dans la branche expérimental/grunt. Pour les versions de node compatibles et le conseil sur NVM, je te laisse faire. J'ai installé les paquets requis sans trop me poser de question, en prenant la dernière version. Il y a juste un petit détail: j'ai forcé une version du paquet merge qui ne pose pas de problème de pollution de prototype, contrairement à ce que NPM indique.

Concernant la commande de build, il s'agit de pouvoir saisir npm run build au lieu de grunt, c'est bien ça? Ou bien tu avais autre chose à l'esprit? Pour ma part, je viens d'ajouter une tâche de build dans VScode qui lance grunt quand je fais ctrl+maj+B et ça m'a l'air assez efficace. Mais, bon, npm run build est certainement beaucoup plus générique, nous sommes d'accord.

Concernant la commande de watch, il s'agit de lancer grunt à chaque fois qu'on enregistre un fichier source, c'est ça? Ça peut être pratique. Quelle est la bonne méthode? npm-watch?

[enguerranws]

Concernant la commande de build, il s'agit de pouvoir saisir npm run build au lieu de grunt, c'est bien ça? Ou bien tu avais autre chose à l'esprit? Pour ma part, je viens d'ajouter une tâche de build dans VScode qui lance grunt quand je fais ctrl+maj+B et ça m'a l'air assez efficace. Mais, bon, npm run build est certainement beaucoup plus générique, nous sommes d'accord.

L'idée, c'est d'abord de ne pas avoir à installer grunt dans l'environnement global (via un npm i -g) ou d'avoir à l'ajouter à son PATH. Ensuite, effectivement, si on peut utiliser des commandes génériques (npm run start|build) ce serait pas mal.

Concernant la commande de watch, il s'agit de lancer grunt à chaque fois qu'on enregistre un fichier source, c'est ça? Ça peut être pratique. Quelle est la bonne méthode? npm-watch?

C'est ça, ça peut être fait avec https://github.com/gruntjs/grunt-contrib-watch et probablement avec npm-watch. L'ennui avec tout ce qui est lié à Grunt (comme grunt-contrib-watch), c'est que ce sont des projets qui ne sont plus à jour. Je ne sais pas ce que ça donne avec Node 16...

Le top de ce côté, ce serait de mettre en place une commande (ex: npm run dev) en plus du watch, qui lance un serveur de dev (sur localhost:3000, par ex) et qui fait du hot reload de ce qu'on est en train d'éditer. Ça parait un peu gros pour le projet, mais c'est super confortable à l'utilisation.

[YannisDelmas]

De mon côté j'utilise NodeJS en version 16. Tout à l'air de bien fonctionner. Grunt lui-même a une dernière version de mai 21 et le plugin pour TwigJS est plus ancien (2 ans), mais TWigJS lui-même est bien tenu à jour, apparemment. Je dirais que c'est l'essentiel.

Je viens de mettre en œuvre les scripts NPM. C'est plutôt sympa, même si j'ai galéré un moment avant de comprendre qu'il ne s'intéressait qu'aux fichiers JS, sauf mention contraire.

@enguerranws Est-ce que quelque chose comme ça te conviendrait ?

[enguerranws]

J'ai testé et ça fait le boulot. Par contre, comme je le craignais, c'est pas le plus performant (entre 1 et 2 secondes à exécuter la tâche). D'un autre côté, Grunt n'est plus trop maintenu : officiellement, il l'est, mais vu le temps de réponse aux tickets, il semble que de fait, il soit laissé de côté. (gruntjs/grunt#1700)

@YannisDelmas si ces 2 "défauts" inhérents à Grunt te semblent compatibles avec le projet, ça m'ira aussi. Ça dépend aussi de ce qu'on prévoit de faire à l'avenir avec : si on se dit que ce serait intéressant d'avoir aussi du Sass et un code JS organisé en modules (et Babel pour assurer la compatibilité), Grunt va être aux fraises (je pense que ça lui prendra plus de 5 secondes pour faire tout ce boulot). Si on s'en tient à ce qu'on a actuellement, ça reste encore acceptable je pense.

[YannisDelmas]

Concernant la vitalité de Grunt, je ne suis pas trop inquiet: ce qu'il fait est assez basique. En cas de problème, j'ai vu que Gulp fait sensiblement la même chose, même si la formulation est différente.

Concernant la rapidité, chez moi l'essentiel du temps est dépensé sur le Twig, donc sauf à repasser en PHP, on ne gagnera rien (ou pas grand-chose) en passant à un autre task manager.

Je vais mettre ça en place, ça nous simplifiera la gestion des propositions...