Même famille de bug que les 2 commits précédents : dès qu'un
Before()/After() Cucumber est enregistré, le browser runtime du
preprocessor lit `messages.HookType.BEFORE_TEST_CASE`/`AFTER_TEST_CASE`
pour le rapporter — absent de @cucumber/messages@17.1.1 (voir
l'override dans package.json). Confirmé par le run CI précédent :
chaque scénario plantait sur "Cannot read properties of undefined
(reading 'BEFORE_TEST_CASE')", y compris ceux n'ayant a priori rien à
voir avec le profil (le seul Before() du repo vit dans
common.steps.ts, partagé par toutes les features).
Le seul hook du repo ne servait qu'à réinitialiser le profil "connecté"
courant entre scénarios. Remplacé par un reset explicite au tout début
du step "I am signed in as ...", le point d'entrée par lequel passe
systématiquement toute construction de profil — équivalent
fonctionnellement, sans avoir besoin d'enregistrer de hook du tout.
Les tests e2e (apps/web/cypress/e2e/) étaient de simples specs Cypress
(.cy.ts), sans lien avec Cucumber alors qu'apps/api utilise déjà
Gherkin pour ses propres tests BDD. Intègre
@badeball/cypress-cucumber-preprocessor pour écrire les scénarios
utilisateurs en Gherkin des deux côtés, même vocabulaire.
- cypress.config.ts : specPattern sur *.feature, wiring du
préprocesseur (esbuild bundler + plugin cucumber)
- Les 11 fichiers .cy.ts sont remplacés par des paires .feature/.steps.ts
(co-localisées, même nom) — conversion complète, comportement
équivalent (mêmes intercepts, mêmes assertions)
- cypress/support/step_definitions/common.steps.ts : steps partagés
entre features (connexion, navigation, assertions génériques de
texte/URL/champ) — globaux à toute la suite, réutilisables tels quels
- cypress/support/profile.ts : profil du compte "connecté" courant,
assemblé au fil de plusieurs Given avant le premier visit/When
- README : nouvelle section "Cucumber (apps/web)" (miroir de la section
existante pour apps/api), mise à jour des références aux anciens noms
de fichiers .cy.ts (déjà obsolètes avant ce changement)
Vérification : impossible d'exécuter Cypress dans cet environnement
(crash Electron/GPU au lancement, limitation déjà documentée dans le
README — reproductible sur main, indépendante de ce changement). À la
place :
- les 447 steps Gherkin des 11 .feature ont été vérifiés
programmatiquement contre les 165 patterns de step enregistrés : 0
non résolu, 0 ambigu
- les 11 .feature parsent correctement avec le parser Gherkin officiel
(57 scénarios au total)
- tous les .steps.ts passent `biome check` (syntaxe + style) sans erreur
- CYPRESS_INSTALL_BINARY déjà géré (voir PR précédente) — le binaire est
bien présent localement (`cypress verify` OK), donc le blocage est
spécifiquement le sandbox GPU de cet environnement, pas l'installation
La vraie exécution reste à vérifier via le job `e2e` de la CI GitHub
Actions sur cette PR — c'est le chemin déjà documenté dans le README
pour cet environnement précis.
* Scaffold generic pnpm monorepo (api + web + shared)
Sets up the initial project infrastructure only, no business modules yet:
- apps/api: Express/TypeScript backend skeleton (healthcheck route, zod-validated
env config, error handling, Prisma initialized with no models yet, Postgres
as the target DB)
- apps/web: React/Vite/TypeScript frontend skeleton, Capacitor-ready for the
future mobile app
- packages/shared: empty placeholder for types/schemas shared between api and
web once the data model is defined
- Tooling: Biome (lint/format), Mocha+Chai+Supertest (api tests), Cypress
(web e2e smoke test), GitHub Actions CI (lint + test + build + e2e)
- docker-compose.yml for local Postgres
- README documents setup steps, including the Cypress binary caveat (pnpm
install doesn't always fetch the native binary — needs `cypress install`
run locally per machine)
Fixes along the way:
- apps/web/cypress.config.ts: disable GPU on browser launch for
headless/sandboxed environments
- apps/web/tsconfig.*: split into solution/app/node tsconfig files (standard
Vite pattern) — the previous single-file setup caused `tsc -b` to emit
compiled .js/.d.ts next to vite.config.ts and cypress.config.ts
* Remove hardcoded credentials from committed env/compose files
.env.example and apps/api/.env.example had a real usable default
credential pair (batchcooking/batchcooking) baked in, and
docker-compose.yml fell back to the same values via ${VAR:-default}
if .env was missing. Neither should ship a working credential:
- .env.example / apps/api/.env.example now use "changeme" placeholders
that must be edited before use.
- docker-compose.yml uses ${VAR:?...} instead of ${VAR:-default} for
POSTGRES_USER/PASSWORD/DB, so compose fails loudly if .env isn't set
up rather than silently falling back to a guessable credential.
Healthcheck reads the container's own env var ($$POSTGRES_USER)
instead of duplicating the value in the compose file.
- README updated to say .env.example must be edited, not just copied.
Verified: `docker compose config` fails with a clear message when
.env is absent, and resolves correctly once .env is filled in.
* Fix CI: remove pnpm version conflict with packageManager field
pnpm/action-setup@v4 errored with "Multiple versions of pnpm
specified" because the workflow pinned version: 10 while
package.json's packageManager field pins pnpm@10.12.4. The action
already reads packageManager automatically, so drop the redundant
version input.
* Fix CI: install Cypress binary explicitly before running e2e
Same root cause as the README caveat: pnpm install doesn't reliably
trigger Cypress's postinstall binary download, so `cypress run` failed
in CI with "The cypress npm package is installed, but the Cypress
binary is missing." Add an explicit `cypress install` step, and cache
~/.cache/Cypress keyed on the lockfile so subsequent runs don't
re-download it.
* Fix Cypress config loading: give the solution tsconfig a module system
apps/web/tsconfig.json (the tsc -b "solution" file) had no
compilerOptions, only files/references. Cypress's bundled ts-node
picks the nearest tsconfig.json to transpile cypress.config.ts, and
with no "module" specified it defaulted to CommonJS while
package.json declares "type": "module" — causing:
ReferenceError: exports is not defined in ES module scope
Adding module/moduleResolution to the solution config (harmless for
tsc -b itself, since it only builds the referenced projects) fixes
the mismatch. This regressed after the earlier fix for the stray
vite.config.js emission and was never re-verified against Cypress
until CI caught it.
kyuno053
