Supprimer grumphp ?

[SebSept]

On peut se faire la discussion en fr.

J'avais pour idée de virer grumphp, vu que ça fonctionne plus vraiment chez moi et pas seulement.
Mais @Kaudaj n'a pas de problème.

Mon idée était remplacer grumphp par un ensemble de scripts composer (comme je l'ai déjà fais, ça fonctionne bien pour ce que j'ai pu en faire).

[ghost]

Je l'aime bien le vieux, mais disons que j'ai CSfixer à la sauvegarde et je lance phpstan donc j'avoue que je ne vois pas trop l'utilité de le garder.

[tom-combet]

Perso je pense que je ne pourrai plus me passer de pre-commit à présent, en tout cas dans mes projets.
Il y aura toujours un moment où j'oublierai de lancer tel ou tel outil. Là on a que CSFixer et Stan, mais sur mes projets j'ai ESLint, PHPUnit et header-stamp en plus, bientôt autoindex si je fais une PR avec un --dry-run...
Alors on pourrait laisser aux développeurs le soin d'assurer leur syntaxe avec l'IDE ou manuellement. Mais si c'est intégré au projet, ça permet deux choses selon moi : ça encourage à respecter les coding standards (moins d'efforts pour le dev, tout est déjà prêt) et tout le monde a les mêmes résultats ("t'as quelle extension de csfixer toi ? ah oui nan elle est outdated celle là, moi j'ai celle-ci" et cie).
Après ça n'exclut pas de combiner les deux : utiliser les extensions pour avoir des retours pendant qu'on code, corriger en temps réel ou quand on save, et puis valider en final avec le pre-commit en cas d'oubli, de bug de l'extension, de différence de version entre le projet et l'extension etc. Un peu comme une validation côté client (IDE) et une validation côté serveur (pre-commit + github workflows).

Après que ce soit Composer ou GrumPHP qui s'en occupe, en vrai tant que ça marche...
J'ai une préférence pour le vieux parce que je trouve que c'est assez simple d'utilisation au final, tout en yaml. Et puis même si on l'appelle le vieux, il est toujours maintenu régulièrement ! 😛
@SebSept Tu peux nous redonner le lien vers les scripts composer que tu avais déjà fais, pour qu'on puisse voir la différence stp ?

[SebSept]

Phive, c'est pas mal, ça permet d'être indépendant de composer. Mais c'est pas la question vraiment ici 😝 .
Mais de choisir entre des scripts composer ou grumphp.
Si tu n'as de motivation particulièrement forte pour changer tout, faut pas le faire !

Donc, oui, je crois que remettre Grumphp serait la meilleure option... en espérant que ça puisse fonctionner si on l'utilise en commitant directement en ligne de commande ou via l'ide.

On part la dessus @friends-of-presta/fop-console-contributors ? et tu t'y colles @Kaudaj ?

[nenes25]

Yes je suis pour grump php aussi :)

[tom-combet]

Ah oui ok ok je comprends mieux, j'avais pas très bien regardé. C'est surtout ta commande PreCommitHook qui fait tout enfaite.
Bref ok ça marche on fait comme ça, je m'occupe de Grum, et puis on avisera en fonction. 👍

[SebSept]

#150

[ghost]

Il est beau en plus

[SebSept]

@friends-of-presta/fop-console-contributors vous en pensez quoi ?
Vous voyiez ce que c'est grumphp ?

[jf-viguier]

Je ne connais pas je vous fait confiance

[SebSept]

C'est bien aimable 😄
Et tu vois de quoi on parle ?
Tu as pu le voir en fonctionnement sur ta machine ?
ça passe bien ?

[jf-viguier]

Non, ça ne fonctionne pas chez moi

[SebSept]

c'est noté. merci pour le retour 👍🏼

[SebSept]

au passage, tu aurais pu répondre en 'thread' @jf-viguier , comme sur slack quoi 😄

[tom-combet]

si même le patron s'y met 🙄 ... 🤭

[jf-viguier]

MDR !!

[SebSept]

Donc, en résumé, il y a que @nenes25 qui est pour maintenir grumphp , c'est bien ça ?
On le vire ?

votez 👍🏼 pour le garder et 👎🏼 pour le virer.
ping @okom3pom @Kaudaj @jf-viguier

[tom-combet]

Dans sa dernière version, je suis pro-grum. Mais effectivement en l'état (en php 7.2), on dirait qu'il est pas assez mature.

[SebSept]

Si on a une config qui fonctionne bien, on peut le garder, mais sinon faut le virer...