3ad854a269
* Add login/signup UI (apps/web)
Wires the frontend to the existing auth API: signup, login, logout,
session restore on load.
- src/api/client.ts — fetch wrapper, credentials: "include" (required
for the httpOnly session cookie — api and web run on different
origins)
- src/features/auth/AuthContext.tsx — global auth state; calls
GET /auth/me on mount to restore the session from the cookie
- src/features/auth/RequireAuth.tsx / RedirectIfAuthenticated.tsx —
react-router-dom route guards (/ requires auth, /login and /signup
redirect away if already authenticated)
- src/pages/{Login,Signup,Home}Page.tsx — forms with client-side
validation via the shared zod schemas, API errors displayed as-is
Moves signupSchema/loginSchema from apps/api into packages/shared
(new SafeUserProfile type too) so frontend and backend validate with
the exact same rules — this is what that package was scaffolded for.
apps/api's auth.schema.ts is gone, auth.routes.ts/auth.service.ts now
import from @batch-cooking/shared directly.
Translated all user-facing API error messages and zod validation
messages to French (were English, inconsistent with the rest of the
UI) — found by actually clicking through the flow in a browser, not
just reading the code.
zod pinned to the same v3 range across api/web/shared on purpose:
apps/web's `pnpm add zod` initially resolved v4, which would have let
a major-version mismatch slip in silently (zod v3 and v4 aren't drop-in
compatible) since shared's schemas are built with v3.
Cypress specs updated for the new routing (unauthenticated visitors
now land on /login, not the old placeholder) and a new auth.cy.ts
mocking the API via cy.intercept — the e2e CI job has no live
backend, so these test frontend behavior only. Real API behavior is
covered by apps/api's Mocha/Cucumber suites against a real database.
Verified end-to-end in a real browser (not just curl): signup, session
persistence across reload, logout (confirmed the cookie was actually
cleared server-side, not just client state), wrong-password error
display, client-side validation blocking short passwords without a
network round trip, duplicate-email conflict. Full lint/mocha/
cucumber/build suite green.
* Fix packages/shared: build to dist/ instead of shipping raw TS
Found by Docker-packaging apps/api and actually running the container:
it crash-looped with "Cannot find module
'/repo/packages/shared/src/schemas/auth.js'" — Node's plain ESM loader
(node dist/server.js, no tsx/ts-node registered) can't execute .ts
source files.
This was invisible everywhere else: tsx (dev, mocha, cucumber) and
Vite both transpile TS on the fly regardless of what package.json
points to, so every dev/test/build path masked the problem. The
Docker container is the first place this code path actually runs
through a plain Node runtime — exactly the kind of thing "package
every change in Docker and run it" is supposed to catch.
Fix: give packages/shared a real build (tsc emitting to dist/, with
.d.ts), and point package.json's main/types/exports at dist/ instead
of src/index.ts. Added as a postinstall (same pattern as apps/api's
`prisma generate`) so dist/ regenerates automatically after any
`pnpm install`; after editing packages/shared's source directly,
`pnpm --filter shared build` (or `pnpm build`) is needed before the
change is visible to consumers pointing at the compiled dist/.
Verified: `node dist/server.js` (plain node, no tsx — mirrors exactly
what the Docker container runs) starts and responds on /health.
Rebuilt the Docker images and re-ran a full signup through the
containerized stack end-to-end. Full lint/mocha/cucumber/build suite
still green.
174 lines
8.2 KiB
Markdown
174 lines
8.2 KiB
Markdown
# batchCooking
|
|
|
|
## Structure
|
|
|
|
Monorepo pnpm workspaces :
|
|
|
|
- `apps/api` — backend Express/TypeScript (squelette générique : healthcheck, config env, Prisma non modélisé, tests Mocha + Cucumber/BDD)
|
|
- `apps/web` — frontend React/Vite/TypeScript, prêt à être embarqué par Capacitor plus tard.
|
|
Page de connexion/inscription en place ; le reste est encore un squelette générique.
|
|
- `packages/shared` — code partagé entre `api` et `web` : schémas zod (`signupSchema`,
|
|
`loginSchema`) et types (`SafeUserProfile`) — même règles de validation des deux côtés,
|
|
pas de risque de dérive entre front et back.
|
|
|
|
## Prérequis
|
|
|
|
- Node.js 22 (voir `.nvmrc`)
|
|
- pnpm 10 (`corepack enable` puis `corepack use pnpm@10.12.4`, ou installation manuelle)
|
|
- Docker (pour Postgres en local)
|
|
|
|
## Installation
|
|
|
|
```bash
|
|
pnpm install
|
|
cp .env.example .env
|
|
cp apps/api/.env.example apps/api/.env
|
|
cp apps/web/.env.example apps/web/.env
|
|
```
|
|
|
|
Puis **édite ces deux `.env`** pour renseigner de vrais `POSTGRES_USER`/`POSTGRES_PASSWORD`
|
|
(et la `DATABASE_URL` correspondante dans `apps/api/.env`) : les fichiers `.env.example`
|
|
ne contiennent volontairement aucun identifiant réel (juste `changeme`), et
|
|
`docker-compose.yml` refuse de démarrer tant que `POSTGRES_USER`/`PASSWORD`/`DB` ne
|
|
sont pas définis dans `.env` — pas de valeur par défaut en dur dans les fichiers commités.
|
|
Même règle pour `apps/api/.env` : `JWT_SECRET` est **requis, sans défaut** (génère le
|
|
tien, voir le commentaire dans `apps/api/.env.example`).
|
|
|
|
### Cypress : téléchargement du binaire
|
|
|
|
`pnpm install` installe le package `cypress` mais **pas forcément son binaire** (le
|
|
téléchargement du `.exe`/binaire natif peut être ignoré selon l'environnement où
|
|
`pnpm install` a été lancé — ex. un environnement sandboxé/CI dont le cache ne
|
|
correspond pas à celui de ta machine). Si `pnpm --filter web e2e` échoue avec une
|
|
erreur du type :
|
|
|
|
```
|
|
No version of Cypress is installed in: ...\AppData\Local\Cypress\Cache\...
|
|
Please reinstall Cypress by running: cypress install
|
|
```
|
|
|
|
lance simplement, depuis ta machine :
|
|
|
|
```bash
|
|
pnpm --filter web exec cypress install
|
|
```
|
|
|
|
(à faire une seule fois par machine ; le binaire est mis en cache localement,
|
|
hors du repo).
|
|
|
|
## Développement
|
|
|
|
```bash
|
|
# Base de données Postgres locale
|
|
docker compose up -d
|
|
|
|
# Applique le schéma (première fois / après un changement de prisma/schema.prisma)
|
|
pnpm --filter api exec prisma migrate dev
|
|
|
|
# Backend (http://localhost:3000)
|
|
pnpm dev:api
|
|
|
|
# Frontend (http://localhost:5173)
|
|
pnpm dev:web
|
|
```
|
|
|
|
> **Conflit de port possible sur `5432`** : si tu as déjà un Postgres natif installé
|
|
> sur ta machine (service Windows, Homebrew, etc.), il peut occuper le port 5432 et
|
|
> intercepter les connexions à la place du conteneur Docker (symptôme : Prisma
|
|
> renvoie `P1000: Authentication failed` alors que les identifiants sont corrects).
|
|
> Dans ce cas, mets `POSTGRES_PORT=5433` (ou autre) dans ton `.env` **et** adapte le
|
|
> port dans la `DATABASE_URL` de `apps/api/.env`.
|
|
|
|
## Qualité / Tests
|
|
|
|
```bash
|
|
pnpm lint # Biome (lint + format check)
|
|
pnpm lint:fix # Biome --write
|
|
pnpm test # tests unitaires/intégration (Mocha, apps/api)
|
|
pnpm --filter api test:bdd # tests d'intégration BDD (Cucumber/Gherkin, apps/api)
|
|
pnpm --filter web e2e # tests e2e (Cypress, démarre le serveur dev automatiquement)
|
|
pnpm build # build de tous les workspaces
|
|
```
|
|
|
|
La CI GitHub Actions (`.github/workflows/ci.yml`) exécute lint + tests + build sur chaque push/PR vers `main`, puis les tests e2e Cypress.
|
|
|
|
### Cucumber (apps/api)
|
|
|
|
Tests d'intégration lisibles en Gherkin, en complément de Mocha (qui reste pour les
|
|
tests unitaires purs) :
|
|
|
|
- `apps/api/features/*.feature` — scénarios en Given/When/Then (`health.feature` sert
|
|
d'exemple)
|
|
- `apps/api/features/step-definitions/*.steps.ts` — implémentation des steps
|
|
- `apps/api/features/support/world.ts` — contexte partagé entre les steps d'un
|
|
scénario (instancie l'app Express in-process via `createApp()`, comme le fait déjà
|
|
supertest côté Mocha — pas besoin de lancer un vrai serveur)
|
|
- `apps/api/cucumber.cjs` — config (extension `.cjs` volontaire, voir la remarque
|
|
TypeScript/ESM ci-dessous)
|
|
|
|
Pour ajouter un scénario : écrire le `.feature`, lancer `pnpm --filter api test:bdd`,
|
|
implémenter les steps manquants (Cucumber affiche des snippets tout prêts pour ceux
|
|
qui n'existent pas encore).
|
|
|
|
> **Piège TypeScript/ESM à connaître** (déjà rencontré avec `cypress.config.ts`) :
|
|
> les fichiers de config d'outils tiers qui font du chargement dynamique de TS
|
|
> (`cucumber.cjs`, `cypress.config.ts`…) sont sensibles au `"type": "module"` du
|
|
> `package.json`. `cucumber.cjs` évite le problème *pour sa propre config* en étant
|
|
> explicitement CommonJS ; les steps/world restent en `.ts` ESM classique et sont
|
|
> chargés via `tsx` (`NODE_OPTIONS=--import=tsx`, voir le script `test:bdd`).
|
|
|
|
## Auth (apps/api)
|
|
|
|
Inscription (création de profil + foyer) et connexion, JWT dans un cookie httpOnly.
|
|
|
|
- `POST /auth/signup` — `{ firstName, lastName, email, password }` → crée le foyer
|
|
(`house`) et le profil (`user_profiles`) en une transaction, pose le cookie de
|
|
session, renvoie le profil (201)
|
|
- `POST /auth/login` — `{ email, password }` → pose le cookie de session, renvoie le
|
|
profil (200) ; message d'erreur volontairement générique (401) que ce soit
|
|
l'email ou le mot de passe qui soit incorrect
|
|
- `POST /auth/logout` — efface le cookie (204)
|
|
- `GET /auth/me` — profil courant, nécessite le cookie de session (401 sinon)
|
|
|
|
Mots de passe hachés avec argon2. Le hash est indépendant du foyer : un profil crée
|
|
toujours son propre foyer à l'inscription (rejoindre un foyer existant n'est pas
|
|
encore implémenté).
|
|
|
|
> **argon2 : version pinnée à `0.31.2`, pas de `^`.** La version `0.45.1` (dernière au
|
|
> moment de l'écriture) segfault au runtime sur au moins une configuration Windows —
|
|
> reproduit de façon stable (bash sandboxé, bash non-sandboxé, PowerShell), alors que
|
|
> `0.31.2` fonctionne parfaitement avec la même API. Si tu montes la version, revérifie
|
|
> concrètement (`argon2.hash(...)` dans un `node -e`) avant de merger, un `pnpm build`
|
|
> qui passe ne suffit pas à détecter un crash runtime.
|
|
|
|
Les tests (Mocha + Cucumber) tournent avec un coût argon2 réduit
|
|
(`NODE_ENV=test`, voir `auth.service.ts`) — le coût par défaut est volontairement
|
|
élevé (sécurité), ce qui rendrait la suite de tests lente/instable sinon. La CI
|
|
provisionne un vrai Postgres de service (`.github/workflows/ci.yml`) et exécute
|
|
`prisma migrate deploy` avant les tests.
|
|
|
|
> **Les tests automatisés et `pnpm dev:api` partagent la même base Postgres locale.**
|
|
> Lancer `pnpm test`/`test:bdd` **vide `user_profiles`/`house`** (`TRUNCATE ... CASCADE`,
|
|
> voir `test-support/reset-db.ts`) — si tu es en train de tester manuellement à la main
|
|
> (via le navigateur ou curl) contre le serveur de dev, un run de tests en parallèle
|
|
> efface tes données de test sans prévenir. Pas un bug, juste à savoir.
|
|
|
|
## Page de connexion / inscription (apps/web)
|
|
|
|
- `src/api/client.ts` — client fetch vers l'API (`credentials: "include"`, requis pour
|
|
que le cookie de session httpOnly parte/revienne — l'API et le front sont sur des
|
|
origines différentes). URL configurable via `VITE_API_URL` (voir `.env.example`).
|
|
- `src/features/auth/AuthContext.tsx` — état d'auth global ; appelle `GET /auth/me` au
|
|
chargement pour restaurer la session depuis le cookie.
|
|
- `src/features/auth/RequireAuth.tsx` / `RedirectIfAuthenticated.tsx` — gardes de route
|
|
(react-router-dom) : `/` exige d'être connecté, `/login` et `/signup` redirigent vers
|
|
`/` si on l'est déjà.
|
|
- `src/pages/{Login,Signup,Home}Page.tsx` — validation client instantanée via les
|
|
schémas zod partagés (`packages/shared`), erreurs API affichées telles quelles
|
|
(messages déjà en français côté serveur).
|
|
|
|
Tests Cypress (`apps/web/cypress/e2e/`) : `smoke.cy.ts` + `auth.cy.ts` mockent l'API via
|
|
`cy.intercept` plutôt que de dépendre d'un vrai backend — le job e2e de la CI ne
|
|
provisionne pas de Postgres/API, seulement le serveur de dev Vite. Le comportement
|
|
réel de l'API est couvert par les suites Mocha/Cucumber d'`apps/api` (contre une vraie
|
|
base).
|