Un module compatible 1.7 à 9 : pourquoi c'est souvent une mauvaise idée

Trois versions de Symfony, deux de PHP, un seul code. J'ai essayé sur mes propres modules — voilà où passe la frontière entre une branche et deux.

L'idée séduisante

Un seul module, un seul dépôt, une seule version, qui s'installe de PrestaShop 1.7 à PrestaShop 9. Sur le papier c'est élégant. En pratique, on demande à un même code de tourner sur trois versions majeures de Symfony — 3.4, 4.4 et 6.4 — et sur deux branches de PHP qui ne parlent pas la même langue.

J'ai essayé sur mes propres modules. Voici ce que j'y ai trouvé.

Ce qui bloque en descendant

PrestaShop 1.7.8 tourne encore sous PHP 7.4 chez beaucoup d'hébergeurs. Quatre écritures suffisent à tout casser :

• les types de retour union — bool|array — introduits en PHP 8.0 ;
• str_contains(), qui n'existe pas avant PHP 8.0 ;
• les attributs #[…], même purement informatifs pour l'éditeur ;
• et le piège le plus sournois : un namespace nommé …\Class. C'est un mot réservé, refusé par PHP 7.4. Mon PHP 8.4 local l'acceptait sans broncher, ce qui masquait le problème jusqu'au déploiement.

Aucune de ces quatre corrections n'est difficile. Ensemble, elles retirent au module tout ce que PHP 8 apporte de confortable — et un développeur qui reprendra le code dans deux ans ne comprendra pas pourquoi il est écrit comme en 2019.

Ce qui bloque en montant

Dans l'autre sens, la difficulté est ailleurs. PrestaShop 9 déprécie FrameworkBundleAdminController, la classe de base de tout contrôleur d'administration, au profit de PrestaShopAdminController. Les deux ne coexistent pas gracieusement : le contrôleur devient un service, ses dépendances passent par le constructeur, la manière d'accéder aux services change.

Écrire un contrôleur qui satisfait les deux, c'est écrire deux contrôleurs et brancher le bon selon la version détectée. À ce stade, on n'a plus un module compatible : on a deux modules dans un seul dossier, avec la complexité en prime.

Où passe la frontière

Elle est nette, et elle ne dépend pas de la version de PrestaShop mais de l'architecture du module :

• Un module à hooks classiques, sans contrôleur Symfony, couvre 1.7.6 à 9.x sans effort particulier. Ce n'est pas de la chance : il ne touche à rien de ce qui a bougé.
• Un module avec des contrôleurs d'administration Symfony ne franchira pas le pas de la 9 sans réécriture. Autant l'assumer.

Ma conclusion

Deux branches. Une pour 1.7.8 → 8.x, une pour 9.x, chacune taguée et publiée séparément. C'est ce que font les éditeurs de modules sérieux, et ce n'est pas de la paresse : une couche de compatibilité qui tente de couvrir tout l'éventail finit par casser des deux côtés, et personne ne sait plus quel chemin le code a pris.

Le seul cas où le module unique se défend, c'est précisément celui où il n'y a rien à concilier : pas de contrôleur, pas de service, pas de formulaire Symfony. Si votre module est dans ce cas, gardez-le ainsi le plus longtemps possible. C'est sa meilleure qualité.