PrestaFlow sans Flashlight : brancher sur sa stack locale

Décor

La série a supposé Flashlight partout — image Docker PrestaShop clé en main, jetable, idéale pour le CI. C’est le bon choix dès qu’on parle de reproductibilité (automatisation en CI) ou de matrice multi-versions.

Mais dans la vraie vie du dev, beaucoup de gens ont déjà une boutique qui tourne en local via Valet, MAMP, DevKinsta, Herd, ou une docker-compose.yml maison. Une boutique qui a leur config à eux, leur thème custom, leur base peuplée. Booter Flashlight à côté ferait doublon — voire noierait le vrai contexte de dev.

PrestaFlow se fiche royalement de savoir où la boutique tourne. Il lui faut juste une URL qui répond. Cette annexe montre comment le brancher sur votre stack existante, en une paire de lignes de .env, et quand ce choix est le bon.

La configuration minimale

Reprenons le .env de l’article d’introduction — mais cette fois, on pointe sur une boutique locale déjà installée, par exemple https://prestashop.test servi par Laravel Valet :

PRESTAFLOW_PS_VERSION=8.1.7
PRESTAFLOW_LOCALE=fr
PRESTAFLOW_FO_URL=https://prestashop.test/
PRESTAFLOW_BO_URL=https://prestashop.test/admin-dev/
PRESTAFLOW_BO_EMAIL=demo@prestashop.com
PRESTAFLOW_BO_PASSWD="Correct Horse Battery Staple"
PRESTAFLOW_HEADLESS=false

C’est tout. Vous lancez :

composer prestaflow -- run ./tests/prestaflow

Vos suites tournent contre prestashop.test — la boutique qui tourne déjà sur votre machine, avec sa config, ses modules installés, ses données. Pas de conteneur démarré, pas d’attente de boot.

Ce que ce mode donne (et ne donne pas)

Les gains

Zéro attente de boot. Un run PrestaFlow local démarre aussitôt, alors que Flashlight doit d’abord démarrer son conteneur et installer la boutique.
Contexte de dev réaliste. Votre thème custom, vos modules installés, votre config personnalisée, votre catalogue à vous. Vous testez ce que vous développez, pas ce qu’un conteneur générique aurait servi.
Persistance entre runs. Un produit ajouté au panier persiste, une config modifiée reste. Utile pour explorer manuellement l’état laissé par un scénario, sans qu’un conteneur ne le jette derrière vous.
Vitesse d’itération. Combiné à PRESTAFLOW_HEADLESS=false et à l’app PrestaFlow, on obtient la boucle courte parfaite pour écrire un scénario en tâtonnant.

Les pertes

Reproductibilité perdue. Votre boutique a votre config, votre catalogue, votre base. Ce qui passe chez vous ne passera pas forcément chez le collègue — ni sur la CI. C’est le miroir inversé de la promesse Flashlight.
Pollution de la base. Vos suites laissent des traces (produits créés, adresses saisies, abonnements newsletter). Sans cleanup soigné (voir l’annexe module tiers sur le suffixe unique et l’étape de nettoyage), la base grossit et se dégrade.
Impossible en CI. Sur GitHub Actions, il n’y a pas de prestashop.test — il faut soit Flashlight, soit monter une boutique dans le workflow.

Quand choisir Flashlight, quand choisir sa stack locale

Un cadre simple :

Moment	Bon choix
Écriture d’un scénario, itération rapide	Stack locale — pas de boot, votre contexte
Debug d’un scénario capricieux	Stack locale — headed + persistance = pratique
Test avant push	Stack locale puis Flashlight — d’abord chez soi, puis le CI
CI sur chaque push	Flashlight — reproductibilité, matrice versions
Test multi-versions PrestaShop	Flashlight — l’input `ps-version` de l’Action
Démo à un collègue distant	Flashlight — il obtient le même résultat que vous

Autrement dit : les deux ne s’opposent pas, ils se complètent. La stack locale sert la boucle courte du dev, Flashlight sert le filet de sécurité partagé.

Combiner les deux modes dans un même projet

Rien n’empêche d’avoir les deux prêts, chacun avec son .env :

psflowdemo/
├─ .env                  ← local, .gitignored, pointe sur prestashop.test
├─ .env.flashlight       ← versionné, pointe sur votre Flashlight (ex. http://localhost:8000/)

Flashlight n’écoute pas forcément sur le port 80 : c’est le port que vous publiez avec Docker (-p 8000:80, par exemple), et PS_DOMAIN doit reprendre la même valeur (localhost:8000).

En local, vous laissez PrestaFlow lire .env par défaut. En CI, deux cas :

Avec l’Action et flashlight: true, c’est elle qui démarre Flashlight (sur le port 8000, 8001 ou 8002, le premier libre) et qui écrit un .env.local avec deux variables seulement : PRESTAFLOW_FO_URL et PRESTAFLOW_PS_VERSION. La lib lit .env.local en priorité et ignore alors .env : inutile d’y copier .env.flashlight, les autres variables gardent leurs valeurs par défaut.
Sans l’Action, avec un Flashlight lancé à la main dans le workflow, copiez .env.flashlight en .env dans un step préalable. Évitez de passer ces variables par env: : la version 1.7.1 de la lib les lit dans $_ENV, qui reste vide si PHP est configuré sans le E de variables_order.

Interaction avec les autres annexes

Cookies pré-injectés — récupérer le cookie de session admin de votre stack locale est trivial (DevTools sur la page BO ouverte à la main). Copier-coller dans PRESTAFLOW_COOKIES, et vos suites BO démarrent déjà connectées.
Preprod htpasswd — si votre stack locale est protégée par un htpasswd (cas rare mais possible pour partager une instance de dev entre plusieurs personnes), PRESTAFLOW_BASIC_* s’applique à l’identique.
Fixtures — les init-scripts Flashlight ne s’appliquent pas ici (pas de conteneur), le niveau 1 disparaît. Les niveaux 2 (step pré-run) et 3 (override before()) restent pertinents pour maintenir un état stable sur votre boutique locale.