Refactoriser son code PHP, avec Rector

Si vous suivez ce blog depuis un moment, vous devez vous souvenir que j’avais parlé dans un précédent article de l’importance des mises à jour. (Si vous ne l’avez pas lu je vous invite à y aller mais vous faites bien ce que vous voulez 😛)

Lorsque vous travaillez sur un projet depuis longtemps et même s’il est en production, vous pouvez avoir à faire des mises à jour selon l’évolution des ressources que vous utilisez. En général, on se base sur les LTS de ces ressources, comprenez “Long Term Service” donc les dernières versions maintenues.

Par exemple si vous utilisez Symfony, la dernière version LTS est la 6.4 depuis la récente sortie de la version 7 du framework.

Pour PHP, la LTS est la 8.2 (la 8.1 expirera définitivement en fin d’année, support de sécurité inclus).

Adapter son code aux mises à jour

“C’est super tout ça mais pourquoi tu nous fais un listing des versions de ces logiciels ?”

Déjà parce qu’il est important de se tenir au courant de ce genre de choses 😛

Mais aussi parce que le lire n’est pas suffisant. Il faut aussi parfois passer à l’action pour s’assurer que vos sites et applications soient globalement à jour pour éviter les failles de sécurité.

Imaginez (et c’est réellement le cas) que des failles de sécurité soient découvertes sur PHP 7 et que vous ayez encore des sites en 7.1. Les mises à jour n’étant plus assurées sur cette version, votre code contient des failles exploitables.

“Ah oui carrément. Que doit-on faire alors ?”

Parfois une simple ligne de commande suffit, souvent pour ce qu’on appelle les mises à jour mineures. Par exemple Symfony traite très bien ce cas et je n’ai jamais rencontré de problème pour ce type de mise à jour.

Mais parfois il faut mettre les mains dans le code et réadapter certaines choses, ce que l’on appelle les breaking changes lors de mises à jours majeures.

C’est précisément ce qui m’est arrivé récemment, lorsque j’ai voulu passer Neartrip sur la LTS de Symfony, 6.4 donc si vous avez suivi 😛

Le problème ? Entre la 6.1 et la 6.4, les annotations PHP ne sont plus supportées, au profit des récents attributs PHP instaurés dans PHP 8.

Concrètement, cela veut dire que j’étais obligé de repasser sur chaque fichier du code source pour convertir les annotations en attributs. C’est un travail long et fastidieux alors il fallait trouver un outil capable de faire ça. 🙂

Rector, un outil pour automatiser la réécriture de code

C’est ainsi que j’ai découvert Rector, un petit package open source dispo sur Github. Le principe est simple, vous lui donnez un ensemble de règles à suivre dans un fichier de configuration rector.php à la racine de votre projet. Vous lancez ensuite une commande classique et il va se charger de tout.

vendor/bin/rector

En tous cas, de tout ce que vous lui aurez dit de gérer. Effectivement dans le cas des annotations Symfony par exemple vous pouvez avoir du @Rest/Get ou bien du @Route, etc…

Il faut donc lister toutes ces différentes annotations dans le script de rector de cette manière :

Une fois la commande lancée et le script terminé, le code est automatiquement transformé 😀

Avant

Après

Pratique non ? 🙂

Un ensemble des règles disponibles et applicables par Rector sont disponibles dans la doc si vous en avez besoin pour d’autres usages.

Conclusion

Rector est l’un de ces outils qui permet un gain de temps incroyable pour des tâches souvent rébarbatives. Car certes tenir son code à jour c’est important mais ce n’est pas non plus la partie la plus fun de notre métier. Alors trouver ce genre de petits facilitateur de quotidien c’est vraiment pratique et on peut remercier la communauté derrière. 😀