* chore(web): session de polish global — version, checkbox, danger zone, icônes
- Affiche le numéro de version (package.json, injecté via Vite) en bas de
la sidebar, masqué en mode collapse et en mobile.
- Factorise les checkbox/radio dupliqués (AllergySelect, DietTagSelect,
IngredientPicker, UserPreferencesPage) en composants partagés
CheckboxOption/RadioOption (components/ui/), et inverse le layout pour
que la case soit à gauche du label.
- Teinte la "zone de danger" de suppression de compte en rouge (fond +
bordure), pas seulement le bouton.
- Migre les icônes de navigation générale vers lucide-react (nav-icons.tsx
devient un fichier de ré-export) ; les pictogrammes d'ingrédients métier
restent en SVG custom (pas d'équivalents fins côté lucide).
Vérifié : pnpm build, pnpm lint, pnpm --filter web e2e (43/43), et
vérification visuelle manuelle (sidebar desktop/collapsed/mobile, light/dark).
* feat(web): icônes d'ingrédients depuis foodiconpack.com + page de crédits
- Remplace 19 des 22 pictogrammes génériques d'ingrédients par des icônes
curées du pack gratuit "Common ingredient icons"/"Common Utensils" de
foodiconpack.com (CC BY 4.0) : carotte, pomme, basilic, bœuf, poulet,
saumon, crevette, riz, pois chiches, amandes, lait, cheddar, œufs,
cannelle, miel, huile d'olive, bière, marmite, sucre.
- BREAD/DOUGH/SPROUT restent en SVG custom : pas d'équivalent net dans le
pack (packs "ingrédients"/"ustensiles"/"plats"/"boissons" vérifiés).
Architecture inchangée : `icon` reste un enum de 22 valeurs partagées en
base (pas de migration, pas de mapping par ingrédient — cf. le
commentaire du fichier sur l'historique emoji→enum générique).
- Nouveau wrapper FilledIcon (fill="currentColor", viewBox 2048) à côté du
wrapper Icon existant (stroke) — les deux stylent au même endroit via
CSS, donc le mélange des 19+3 icônes reste visuellement homogène.
- Ajoute /parametres/credits (CreditsPage) créditant foodiconpack.com et
liant la licence CC BY 4.0, requis par la licence des icônes utilisées ;
nouvelle entrée de nav "Crédits" (icône lucide Info).
Vérifié : pnpm build, pnpm lint, pnpm --filter web e2e (43/43), et
vérification visuelle (grille des 22 icônes dans le picker, page crédits).
* feat(web,api): zone dangereuse rouge, préférences élargies, onglet favoris par défaut, e2e recettes, catalogue en uid+i18n
- Zone dangereuse (compte) : le bouton "Supprimer mon compte" est rouge.
- Pages préférences/paramétrage : contenu centré et élargi (32rem -> 56rem)
au lieu de coller à gauche sur un écran large.
- Page recettes : l'onglet "Favoris" est sélectionné par défaut.
- Ajout de apps/web/cypress/e2e/recipes.cy.ts (onglets, recherche, sélection
master-detail, favori, suppression, lien nouvelle recette).
- Catalogue de référence (ingrédients/régimes/allergènes) : la colonne
`name` (le libellé français, utilisé comme clé unique) devient `key`, un
slug stable et opaque au sens produit (ex. "vegetarien", "boeuf_hache").
Le libellé lui-même déménage entièrement côté client, dans
apps/web/src/locales/fr/translation.json sous le namespace `catalog.*`,
résolu via `t(\`catalog.ingredients.${key}\`)` etc. — même schéma que
IngredientCategory/IngredientSubcategory. Migration Prisma
(rename + backfill des ~456 lignes déjà seedées), seed/service/tests API
et composants web mis à jour en conséquence.
- apps/api/src/utils/slugify.ts + scripts/generate-catalog-i18n.ts
(regénère le fichier de traduction depuis reference-seed-data.ts).
- 102 tests Mocha + 32 scénarios Cucumber passent contre la base migrée.
Note : cypress run plante dans cet environnement (le processus GPU
Chromium/Electron crash même headless, indépendamment des flags) — les
recipes.cy.ts n'ont pas pu être exécutés ici ; vérifiés par lecture du code
source des composants visés et par un passage manuel dans le navigateur de
prévisualisation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(api): les uids du catalogue sont en anglais, pas des slugs français
reference-seed-data.ts reste rédigé en français (c'est juste le libellé
d'autoring, jamais stocké/exposé), mais la clé stable (`Diet.key`/
`Category.key`/`Ingredient.key`) qu'on en dérive doit elle-même être un
identifiant anglais, indépendant de la langue d'autoring — pas juste le
même texte français passé à slugify().
- apps/api/src/db/catalog-en-keys.ts : dictionnaire écrit à la main
(label français -> clé anglaise) pour les 5 régimes, 14 allergènes et
437 ingrédients ; getEnglishKey() lève une erreur explicite si un
nouvel élément n'a pas encore d'entrée plutôt que de retomber sur un
slug français silencieux.
- scripts/validate-catalog-en-keys.ts : vérifie que chaque diet/allergène/
ingrédient de reference-seed-data.ts a une entrée, et que les clés
anglaises résultantes sont uniques (437/437, 14/14, 5/5 — zéro manquant,
zéro collision).
- reference-seed-data.ts et scripts/generate-catalog-i18n.ts utilisent
désormais getEnglishKey() au lieu de slugify(nom français).
- Nouvelle migration (20260818193000_catalog_keys_to_english) qui
remappe les lignes déjà seedées avec un slug français (par la migration
précédente) vers leur clé anglaise définitive.
- apps/web/src/locales/fr/translation.json régénéré : catalog.* est
maintenant indexé par clé anglaise ("vegetarian", "eggs",
"ground_beef"...), toujours avec le libellé français en valeur.
- Tests/step-definitions mis à jour (getEnglishKey() au lieu de
slugify()) ; 102 tests Mocha + 32 scénarios Cucumber passent contre la
base migrée. Vérifié aussi en direct via GET /reference/diets et
/reference/allergies.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(web): crypto.randomUUID plante hors contexte sécurisé, empêchant d'associer un ingrédient
Écran noir + "TypeError: crypto.randomUUID is not a function" au clic sur
une carte d'ingrédient dans le formulaire de recette. crypto.randomUUID()
n'est défini que dans un "contexte sécurisé" (https, ou littéralement le
host "localhost") — il est absent sur une IP locale (test sur un vrai
appareil), dans une WebView Capacitor (l'enrobage mobile prévu pour cette
app), ou en http sur un vrai domaine. RecipeFormPage/StepListEditor s'en
servaient pour générer l'identité React (`key`) de chaque ligne
d'ingrédient/étape en brouillon.
- apps/web/src/lib/client-key.ts : remplace par un générateur qui ne
touche jamais `crypto` — un compteur + Math.random suffit, cette valeur
n'a besoin d'être unique que le temps de la session de rendu, jamais
envoyée au serveur.
- apps/web/cypress/e2e/recipe-form.cy.ts : couvre l'association d'un
ingrédient (recherche, sélection, exclusion du picker une fois
sélectionné, retrait), la création et l'édition d'une recette, et un
test de non-régression dédié qui supprime crypto.randomUUID avant le
chargement de la page (comme le ferait un vrai contexte non sécurisé)
pour vérifier que l'ajout de plusieurs ingrédients/étapes ne plante
plus.
Vérifié en direct dans le navigateur de prévisualisation en supprimant
crypto.randomUUID à la main (reproduit le crash), puis en confirmant que
l'ajout d'ingrédient fonctionne à nouveau après le correctif. cypress run
ne peut toujours pas s'exécuter dans cet environnement (voir le commit
précédent) — non exécutés avec Cypress lui-même, mais vérifiés par
lecture des sélecteurs réels et rejoués à la main dans le navigateur.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(ci): corrige les specs Cypress cassées par le refactor uid+i18n, applique biome
- onboarding.cy.ts / preferences.cy.ts / recipes.cy.ts mockaient encore
GET /reference/diets|allergies avec l'ancienne forme {id, name}. Depuis
les deux derniers commits l'API renvoie {id, key} (uid anglais) et le
composant résout le libellé via i18n (t(`catalog.diets.${key}`)) — avec
key manquant, ça affichait littéralement "catalog.diets.undefined" au
lieu de "Végétarien"/"Omnivore"/etc., faisant échouer cy.select()/
cy.contains() dans ces 3 specs. Corrigé pour mocker {key: "vegetarian"},
{key: "peanuts"}, etc.
- recipes.cy.ts : le test "shows a not-found message" utilisait le
mauvais code d'erreur (4041 au lieu de ErrorCode.RECIPE_NOT_FOUND =
4045), donc RecipeDetailPanel tombait dans son état d'erreur générique
au lieu du message "Cette recette n'existe pas." — bug dans mon propre
test, sans rapport avec le refactor.
- pnpm lint (biome) : les fichiers touchés par le refactor précédent
avaient quelques soucis de formatage/tri d'imports (des sed multi-
fichiers, pas d'édition via l'outil habituel) — corrigés par
`biome check --write`.
Vérifié : ces 3 specs + recipe-form.cy.ts passent maintenant dans le job
CI GitHub Actions (Linux, Cypress s'y exécute réellement — contrairement
à cet environnement Windows sandboxé, voir les commits précédents) ; 102
tests Mocha + 32 scénarios Cucumber toujours au vert en local.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
168 lines
6.7 KiB
TypeScript
168 lines
6.7 KiB
TypeScript
import assert from "node:assert/strict";
|
|
import { Given, Then, When } from "@cucumber/cucumber";
|
|
import { getEnglishKey } from "../../src/db/catalog-en-keys.js";
|
|
import { prisma } from "../../src/db/prisma.js";
|
|
import { TEST_REFERENCE_DATE } from "../../test-support/reference-date.js";
|
|
import type { CustomWorld } from "../support/world.js";
|
|
|
|
/**
|
|
* Resolves a reference ingredient by its seeded French name — every
|
|
* scenario below names an ingredient by its `reference-seed-data.ts` name,
|
|
* never a raw id or its slug `key` directly, so this slugifies before
|
|
* matching.
|
|
*/
|
|
async function findIngredientId(name: string): Promise<number> {
|
|
const ingredient = await prisma.ingredient.findFirstOrThrow({
|
|
where: { key: getEnglishKey(name) },
|
|
});
|
|
return ingredient.id;
|
|
}
|
|
|
|
When("I request the recipe catalog", async function (this: CustomWorld) {
|
|
this.response = await this.agent.get("/recipes");
|
|
});
|
|
|
|
When("I request the recipe catalog tab {string}", async function (this: CustomWorld, tab: string) {
|
|
this.response = await this.agent.get("/recipes").query({ tab });
|
|
});
|
|
|
|
Then(
|
|
"the recipe catalog response should include {string}",
|
|
function (this: CustomWorld, name: string) {
|
|
const names = (this.response.body as Array<{ name: string }>).map((recipe) => recipe.name);
|
|
assert.ok(names.includes(name), `expected ${JSON.stringify(names)} to include "${name}"`);
|
|
},
|
|
);
|
|
|
|
When(
|
|
"I create a recipe named {string} with ingredient {string} and step {string}",
|
|
async function (this: CustomWorld, name: string, ingredientName: string, step: string) {
|
|
const ingredientId = await findIngredientId(ingredientName);
|
|
this.response = await this.agent.post("/recipes").send({
|
|
name,
|
|
dietIds: [],
|
|
ingredients: [{ ingredientId, quantity: 1, unit: "unité" }],
|
|
steps: [{ description: step }],
|
|
});
|
|
},
|
|
);
|
|
|
|
When(
|
|
"I create a recipe named {string} with unknown ingredient id {int} and step {string}",
|
|
async function (this: CustomWorld, name: string, unknownIngredientId: number, step: string) {
|
|
this.response = await this.agent.post("/recipes").send({
|
|
name,
|
|
dietIds: [],
|
|
ingredients: [{ ingredientId: unknownIngredientId, quantity: 1, unit: "unité" }],
|
|
steps: [{ description: step }],
|
|
});
|
|
},
|
|
);
|
|
|
|
Then(
|
|
"the created recipe should have ingredient {string} and step {string}",
|
|
function (this: CustomWorld, ingredientName: string, step: string) {
|
|
const body = this.response.body as {
|
|
ingredients: Array<{ ingredient: { key: string } }>;
|
|
steps: Array<{ description: string }>;
|
|
};
|
|
const expectedKey = getEnglishKey(ingredientName);
|
|
assert.ok(body.ingredients.some((line) => line.ingredient.key === expectedKey));
|
|
assert.ok(body.steps.some((s) => s.description === step));
|
|
},
|
|
);
|
|
|
|
// Created directly via Prisma (with a nested ingredient + step), not through
|
|
// the API — same rationale as `planning.steps.ts`'s equivalent "already
|
|
// exists" step: this is background state the scenario needs in place before
|
|
// its actual `When`, not the behavior under test. `authorId` is the
|
|
// currently-logged-in agent's own profile — `visibility` defaults to
|
|
// `PERSONAL` (schema.prisma), matching a recipe this agent just created for
|
|
// themselves.
|
|
Given(
|
|
"a recipe named {string} already exists with ingredient {string} and step {string}",
|
|
async function (this: CustomWorld, name: string, ingredientName: string, step: string) {
|
|
const ingredientId = await findIngredientId(ingredientName);
|
|
const me = await this.agent.get("/auth/me");
|
|
await prisma.recipe.create({
|
|
data: {
|
|
name,
|
|
authorId: me.body.id,
|
|
ingredients: { create: [{ ingredientId, quantity: 1, unit: "unité" }] },
|
|
steps: { create: [{ description: step, order: 0 }] },
|
|
},
|
|
});
|
|
},
|
|
);
|
|
|
|
// Same as above but `visibility: PUBLIC` — needed for scenarios where a
|
|
// *second* user must be able to see (though not necessarily edit) the
|
|
// recipe, e.g. the "only the author can edit" scenario: a `PERSONAL`
|
|
// recipe would 404 for anyone else before the authorship check even runs
|
|
// (see `recipe.service.ts`'s `canView`).
|
|
Given(
|
|
"a public recipe named {string} already exists with ingredient {string} and step {string}",
|
|
async function (this: CustomWorld, name: string, ingredientName: string, step: string) {
|
|
const ingredientId = await findIngredientId(ingredientName);
|
|
const me = await this.agent.get("/auth/me");
|
|
await prisma.recipe.create({
|
|
data: {
|
|
name,
|
|
authorId: me.body.id,
|
|
visibility: "PUBLIC",
|
|
ingredients: { create: [{ ingredientId, quantity: 1, unit: "unité" }] },
|
|
steps: { create: [{ description: step, order: 0 }] },
|
|
},
|
|
});
|
|
},
|
|
);
|
|
|
|
// Distinct from `planning.steps.ts`'s "my household has a planning covering
|
|
// today with recipe {string}..." — that step always creates a *new* recipe
|
|
// row with the given name, which wouldn't exercise the actual `RECIPE_IN_USE`
|
|
// check against a recipe this feature already created. This step instead
|
|
// looks up the already-existing recipe by name and points the planning item
|
|
// at its real id.
|
|
Given(
|
|
"my household has a planning that uses the recipe named {string}",
|
|
async function (this: CustomWorld, recipeName: string) {
|
|
const houseRes = await this.agent.post("/house").send({ name: "Foyer de test" });
|
|
const houseId: number = houseRes.body.id;
|
|
const recipe = await prisma.recipe.findFirstOrThrow({ where: { name: recipeName } });
|
|
|
|
const planning = await prisma.planning.create({
|
|
data: {
|
|
houseId,
|
|
startDate: TEST_REFERENCE_DATE.minus({ days: 2 }).toJSDate(),
|
|
finishDate: TEST_REFERENCE_DATE.plus({ days: 2 }).toJSDate(),
|
|
},
|
|
});
|
|
await prisma.planningItem.create({
|
|
data: { planningId: planning.id, weekDay: "lundi", meal: "diner", recipeId: recipe.id },
|
|
});
|
|
},
|
|
);
|
|
|
|
When("I delete the recipe named {string}", async function (this: CustomWorld, name: string) {
|
|
const recipe = await prisma.recipe.findFirstOrThrow({ where: { name } });
|
|
this.response = await this.agent.delete(`/recipes/${recipe.id}`);
|
|
});
|
|
|
|
When("I favorite the recipe named {string}", async function (this: CustomWorld, name: string) {
|
|
const recipe = await prisma.recipe.findFirstOrThrow({ where: { name } });
|
|
this.response = await this.agent.post(`/recipes/${recipe.id}/favorite`);
|
|
});
|
|
|
|
When(
|
|
"the second user tries to modify the recipe named {string}",
|
|
async function (this: CustomWorld, name: string) {
|
|
const ingredientId = await findIngredientId("Tomate");
|
|
const recipe = await prisma.recipe.findFirstOrThrow({ where: { name } });
|
|
this.secondResponse = await this.secondAgent.patch(`/recipes/${recipe.id}`).send({
|
|
name,
|
|
dietIds: [],
|
|
ingredients: [{ ingredientId, quantity: 1, unit: "unité" }],
|
|
steps: [{ description: "Hack" }],
|
|
});
|
|
},
|
|
);
|