* feat(recipes): migre la detection des tech steps de node-nlp vers un microservice Python spaCy Remplace TechStepClassifierService's node-nlp (NlpManager) par services/tech-step-intent-service, un microservice FastAPI/spaCy dedie (PhraseMatcher pour le NER par synonymes, textcat pour la classification d'intention). Corpus (TECH_STEP_TRAINING_DATA) toujours possede par apps/api, pousse au service via POST /v1/train a chaque warm-up ; le service ne touche jamais Postgres (meme posture que services/tech-step-llm-worker). Cote apps/api : - intent-service-client.ts : client HTTP vers le nouveau service - tech-step-matcher.ts : delegue NER + intent classification au client, logique pure (splitIntoClauses, seuil/fallback) inchangee - env.ts : INTENT_SERVICE_BASE_URL/INTENT_SERVICE_SECRET (secret requis, service coeur non optionnel) - server.ts : warm-up avec retry/backoff (service Python demarre a part) - scripts/calibrate-tech-step-threshold.ts : recalibration empirique de CONFIDENCE_THRESHOLD contre le jeu d'eval existant - node-nlp retire (package.json, node-nlp.d.ts, model.nlp du .gitignore) docker-compose.yml : nouveau service tech-step-intent-service (pas de port expose, healthcheck, app en depend). CI : job intent-service-test (pytest) + le job test demarre le service en arriere-plan avant la suite Mocha (jamais de mock d'un service interne, cf specs/dev-conventions.md). Verifie : 26/26 tests pytest du service (dont les offsets caracteres exacts de tech-step-matcher.test.ts), lint + build complets du monorepo, smoke test HTTP reel bout en bout. La suite Mocha et docker compose build/up n'ont pas pu etre executes dans cet environnement (pas de Postgres/Docker disponibles ici) — a confirmer via la CI et en local. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): corrige les matches dupliques et le timeout de warm-up des tests CI Deux bugs reels trouves par la premiere execution CI de la migration node-nlp -> tech-step-intent-service : 1. PhraseMatcher retourne tous les matches y compris chevauchants — un synonyme comme "fondre" litteralement contenu dans "faire fondre" (tous deux synonymes de `melt`) produisait deux candidats separes pour la meme technique, dupliquant son techStepId dans le resultat final. Fixe avec spacy.util.filter_spans (garde le plus long match par position) dans LocalePipeline.process. Test de non-regression ajoute. 2. La suite Mocha construit `app` directement via createApp(), sans jamais passer par server.ts — le warm-up (POST /v1/train fr+en sur le corpus complet) se declenchait donc paresseusement dans le premier test qui appelait le classifieur, depassant le timeout Mocha de 10s par test. Fixe par un root hook plugin Mocha (test-support/mocha-root-hooks.ts, .mocharc.json) qui reset la DB et warm up le classifieur une seule fois avant toute suite, avec son propre timeout de 60s. Verifie : 27/27 tests pytest du service (dont le nouveau test de non-regression), lint + build complets du monorepo. La suite Mocha elle-meme n'a toujours pas pu etre executee dans cet environnement (pas de Postgres disponible ici) — a confirmer via la CI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * ci(temp): ajoute un run de calibrate-tech-step-threshold.ts pour observation Etape temporaire pour lire le sweep de seuils de confiance contre le vrai service tech-step-intent-service en CI (aucun Postgres/service disponible localement dans cette session) — sera retiree une fois CONFIDENCE_THRESHOLD recalibre dans tech-step-matcher.ts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): recalibre CONFIDENCE_THRESHOLD pour le nouveau classifieur spaCy 0.75 (calibre a l'origine contre node-nlp) laissait de vrais verdicts corrects sur des clauses sans ancre NER (rien sur quoi retomber) sous le seuil : melt scorait 0.68 sur "jusqu'a ce que le beurre ait disparu dans la poele" (le cas motivant tout ce pipeline), preheat 0.52 sur "mettre la poele sur feu vif" — tous deux corrects, tous deux rejetes a 0.75. Recalibre a 0.45 : marge confortable au-dessus du bruit (texte anglais via le classifieur francais score ~0.04, indiscernable du hasard sur ~26 classes) et sous les deux cas ci-dessus. Confirme par calibrate-tech-step-threshold.ts contre TECH_STEP_EVAL_DATASET (F1 plafonne a 0.987 des 0.45, reste plat jusqu'a 0.95 — 0.45 est deja le seuil le plus bas qui capture tout le gain disponible). Retire l'etape CI temporaire de calibration (ci.yml) une fois la valeur choisie. Verifie : lint + build complets du monorepo, 27/27 pytest du service, sweep de seuils + verification manuelle contre le corpus reel en local (services Python, sans Postgres) et en CI. La suite Mocha complete reste a confirmer sur ce commit (executee en CI, pas localement — pas de Postgres disponible dans cet environnement). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): entraine le textcat plus longtemps pour une confiance reelle Cause racine du dernier test Mocha en echec (getAuditBatch flaguait "Faire mijoter a feu doux" comme peu fiable malgre une ancre NER claire) : avec seulement 30 iterations/dropout 0.2, le textcat retournait le bon intent (argmax correct) mais avec une confiance tres basse et compressee (0.2-0.7 sur l'ensemble du corpus reel, y compris des cas evidents) — un vrai probleme de qualite d'entrainement, pas seulement de seuil. 150 iterations / lot de 16 / dropout 0.1 (mesure localement contre le vrai corpus, sans Postgres) : melt ~0.95, preheat ~0.90, jusqu'a ~0.51 pour le cas le plus faible observe (bake), bruit hors-vocabulaire toujours ~0.05. ~110s d'entrainement par locale (~220s pour fr+en au warm-up) — compromis assume et documente (README du service, commentaires du code), contrairement a l'entrainement quasi instantane de node-nlp. Root hook Mocha (mocha-root-hooks.ts) et sa doc mis a jour avec un timeout de 600s pour couvrir cette duree avec marge. Verifie : 27/27 pytest, lint + build complets du monorepo. Suite Mocha a confirmer sur ce commit via CI (source du diagnostic qui a mene a ce fix). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(recipes): journalise chaque input/output du pipeline NLP Ajoute un logging JSON structure (meme convention que LoggerService cote apps/api) a services/tech-step-intent-service : chaque appel POST /v1/process journalise locale/texte en entree et entites/intent/score en sortie, chaque POST /v1/train journalise les uid entraines et les compteurs resultants. Chatter interne de spaCy mis a WARNING pour ne pas noyer ces lignes. Bug trouve et corrige en verifiant les octets bruts d'un log reel (pas juste son affichage terminal) : l'encodage par defaut de sys.stdout sur Windows produisait de vrais octets UTF-8 invalides pour tout texte accentue journalise (le francais des etapes de recette) — corrige par sys.stdout.reconfigure(encoding="utf-8") au demarrage. LOG_LEVEL configurable (INFO par defaut), documente dans le README du service et .env.example. Verifie : 30/30 pytest (3 nouveaux tests sur le formateur JSON), smoke test HTTP reel confirmant au niveau des octets que les caracteres accentues sont preserves, lint complet du monorepo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(recipes): rapatrie le corpus NLP cote Python et l'enrichit de 48 techniques Changement d'architecture demande par l'utilisateur : le dataset d'entrainement (TECH_STEP_TRAINING_DATA) quitte apps/api pour vivre entierement dans services/tech-step-intent-service (intent_service/training_data.py). Ce service est desormais autonome : il s'entraine lui-meme une seule fois, a son propre demarrage (PipelineRegistry.initialize, dans le lifespan FastAPI), sans plus dependre d'un POST /v1/train pousse par apps/api (route supprimee). apps/api ne connait plus aucune technique/synonyme, uniquement le resultat de POST /v1/process. Corpus enrichi avec les 48 techniques du lexique fourni (Arroser, Appertiser, Braiser, Caraméliser, Confire, Julienne/Brunoise/Mirepoix/ Paysanne, Cuire à blanc/au bain-marie/à l'étouffée, Déglacer variantes, Emulsionner, Glacer, Pocher, Réduire, Suer, Zester, etc.), soit 74 techniques au total (26 + 48). Integration complete bout en bout : - reference-seed-data.ts : 48 nouvelles entrees TECH_STEPS - apps/web/locales/fr/translation.json : libelles francais correspondants - "Mitonner" fondu comme synonyme de simmer (pas une technique distincte, sa propre definition le dit) - "Blanchir un oeuf" (whiskPale) distingue de "Blanchir un legume" (blanch, existant) via des synonymes en phrase complete plutot qu'au mot nu — filter_spans (deja en place) resout la collision par specificite Impact performance mesure : le corpus elargi (74 classes vs 26) rend l'entrainement bien plus lent a nombre d'iterations egal (150 iterations depassait 17 minutes par run de test) — reduit a 40 iterations apres mesures repetees en local (~200s/locale, ~400s pour fr+en combines). docker-compose.yml (healthcheck start_period 600s), CI (timeout curl 600s) et le README du service documentent ce nouveau temps de demarrage. CONFIDENCE_THRESHOLD recalibre a 0.2 par verification manuelle (0.75 puis 0.45 ne tenaient plus compte tenu du nombre de classes) — marque explicitement comme placeholder en attendant une vraie repasse de calibrate-tech-step-threshold.ts (necessite Postgres, indisponible dans cet environnement). Verifie : 28/28 tests pytest du service (suite complete re-ecrite pour s'entrainer une seule fois par session sur le vrai corpus, fixture partagee dans conftest.py), lint + build complets du monorepo. La suite Mocha d'apps/api reste a confirmer via CI (le root hook mocha n'attend plus l'entrainement, seulement CI's propre attente sur /health). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): corrige l'assertion de taille du catalogue TechStep en dur test/reference.test.ts attendait exactement 26 techniques (l'ancien catalogue) au lieu de deriver la longueur attendue de TECH_STEPS (reference-seed-data.ts) — trouve par la CI apres l'ajout des 48 nouvelles techniques (74 au total). Seul echec du run CI precedent, le service Python (nouveau corpus, self-training) a lui demarre et repondu correctement dans le nouveau delai imparti. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): entraine le textcat plus longtemps pour une confiance reelle Suite a une revue de code sur locale_pipeline.py, trois ameliorations implementees et verifiees contre le vrai corpus (74 techniques) : - spacy.util.fix_random_seed(_TRAINING_SEED) avant nlp.initialize() — random.Random() ne graine que l'ordre de melange des exemples, pas l'init des poids/dropout internes de thinc. - _DiacriticsNormalizer deplace au-dessus de sa factory @Language.factory — plus d'annotation de type en chaine. - Log explicite (logger.warning) quand train() recoit moins de 2 labels et saute la creation du textcat, plus une clarification de la docstring de process() sur les deux cas menant a intent=None. - Early stopping avec suivi de la perte par epoque, _TRAINING_ITERATIONS restant le plafond. Mesure sur le vrai corpus : ne se declenche jamais dans le budget actuel de 40 iterations (la perte continue de baisser significativement jusqu'au bout) — documente honnetement comme filet de securite pour un futur relevement du plafond, pas un gain de temps aujourd'hui. Deux suggestions de la revue examinees et non retenues, avec justification en commentaire : le risque de desalignement pattern/texte via normalize_text (normalize_text opere par token deja tokenise, jamais sur la chaine brute — pas de risque de segmentation differente) ; passer a attr="LOWER" aurait au contraire regresse l'insensibilite aux accents que attr="NORM" fournit deliberement. Verifie : 28/28 pytest (dont le vrai corpus complet via la fixture partagee), lint du monorepo. Temps d'entrainement mesure stable (~200-230s/locale, dans la marge de bruit deja documentee). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): entraine le textcat sur les synonymes en plus des utterances Suite a une suggestion de revue de code : le textcat n'apprenait jusqu'ici que sur entry.utterances, jamais sur entry.synonyms (deja utilises pour le PhraseMatcher). Ajouter le mot-cle isole comme exemple positif de sa propre technique ameliore radicalement la confiance sur les cas ancres sans paraphrase entrainee. Mesures sur le vrai corpus (74 techniques) : - 40 iterations + synonymes (749 exemples vs 286 avant) : gain de confiance massif (simmer 0.25->0.60, cook 0.33->0.60, bake 0.34->0.86) mais temps d'entrainement multiplie par 2.6 (~535s/locale, ~17min combine pour fr+en — inacceptable). - 15 iterations + synonymes : retour a un temps raisonnable (~205s) mais qualite pire qu'avant (simmer/cook repassent sous le seuil de confiance) — les exemples supplementaires ne compensent pas la perte d'epoques a ce point. - 25 iterations + synonymes (retenu) : ~336s/locale (~670s combine), meilleur compromis — tous les cas mesures s'ameliorent par rapport a la config precedente (simmer 0.25->0.31, cook 0.33->0.38, bake 0.34->0.62, zest 0.64->0.66, julienne 0.56->0.76, compote 0.76->0.78), bruit hors-vocabulaire toujours negligeable (~0.02). CONFIDENCE_THRESHOLD releve de 0.2 a 0.25 (le cas le plus faible mesure est maintenant 0.31, avec plus de marge qu'avant). docker-compose.yml (start_period 900s) et la CI (timeout 900s) ajustes pour le nouveau temps de demarrage (~11 min pour fr+en combines, contre ~7 min avant). Deux autres pistes de la meme revue examinees et non retenues avec justification : classe __OTHER__/negatifs hors-domaine (le bruit mesure est deja bas, ~0.02, sans le symptome que cette classe corrige) et boost de score post-traitement si le NER confirme l'intention predite (casserait la garantie "score brut, jamais corrige par l'ancre" que services/tech-step-llm-worker's audit de faible confiance depend explicitement d'avoir, voir le commentaire de TechStepClauseClassification dans tech-step-matcher.ts). Verifie : 28/28 pytest (dont le vrai corpus complet, ~10.5 min pour la suite complete), lint + build du monorepo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
519 lines
19 KiB
TypeScript
519 lines
19 KiB
TypeScript
import { expect } from "chai";
|
|
import { prisma } from "../../src/db/prisma.js";
|
|
import type {
|
|
IngredientMatchEntry,
|
|
UnitMatchEntry,
|
|
} from "../../src/lib/recipe-matching/ingredient-matcher.js";
|
|
import {
|
|
mergeDuplicateIngredients,
|
|
type TranslatedRecipeIngredient,
|
|
translateRecipe,
|
|
translateRecipeIngredients,
|
|
translateRecipeSteps,
|
|
type UnitConversionEntry,
|
|
} from "../../src/lib/recipe-matching/recipe-translation.js";
|
|
import type {
|
|
ParsedRecipe,
|
|
ParsedRecipeIngredient,
|
|
} from "../../src/lib/recipe-sources/recipe-source-adapter.js";
|
|
import { resetDatabase } from "../../test-support/reset-db.js";
|
|
|
|
/** A minimal fixture `ParsedRecipe` — only `steps` (built from `descriptions`) matters for most tests here, the rest is filler to prove it survives translation untouched. */
|
|
function buildParsedRecipe(descriptions: string[]): ParsedRecipe {
|
|
return {
|
|
name: "Test Recipe",
|
|
description: "A recipe for testing",
|
|
picture: "https://example.test/recipe.jpg",
|
|
portions: 4,
|
|
sourceUrl: "https://example.test/recipes/1",
|
|
ingredients: [{ rawText: "1 egg", quantity: null, unit: null, name: "egg" }],
|
|
steps: descriptions.map((description, i) => ({
|
|
description,
|
|
picture: i === 0 ? "https://example.test/step1.jpg" : null,
|
|
})),
|
|
};
|
|
}
|
|
|
|
describe("recipe-translation", () => {
|
|
// `translateRecipeSteps` now goes through `techStepClassifier` (a
|
|
// trained model, not a pure regex test against a caller-supplied
|
|
// mapping list — see `tech-step-matcher.ts`), so these tests exercise
|
|
// the real training corpus (`services/tech-step-intent-service`'s
|
|
// `training_data.py`) against a real `TechStep` catalog rather than
|
|
// synthetic fixtures — same posture
|
|
// `tech-step-matcher.test.ts`'s own `techStepClassifier` describe block
|
|
// takes, for the same reason.
|
|
describe("translateRecipeSteps", () => {
|
|
let simmerId: number;
|
|
let preheatId: number;
|
|
let meltId: number;
|
|
|
|
beforeEach(async () => {
|
|
await resetDatabase();
|
|
simmerId = (await prisma.techStep.findFirstOrThrow({ where: { key: "simmer" } })).id;
|
|
preheatId = (await prisma.techStep.findFirstOrThrow({ where: { key: "preheat" } })).id;
|
|
meltId = (await prisma.techStep.findFirstOrThrow({ where: { key: "melt" } })).id;
|
|
});
|
|
|
|
after(async () => {
|
|
await prisma.$disconnect();
|
|
});
|
|
|
|
it("declares each step's technique sequence, preserving order", async () => {
|
|
const recipe = buildParsedRecipe([
|
|
"Préchauffer la poêle, puis faire fondre le beurre",
|
|
"Servir immédiatement",
|
|
"Faire mijoter à feu doux",
|
|
]);
|
|
|
|
const translated = await translateRecipeSteps(recipe, "fr");
|
|
|
|
expect(translated.steps.map((step) => step.techStepIds)).to.deep.equal([
|
|
[preheatId, meltId],
|
|
[],
|
|
[simmerId],
|
|
]);
|
|
});
|
|
|
|
it("leaves description/picture untouched on each step", async () => {
|
|
const recipe = buildParsedRecipe(["Faire mijoter à feu doux", "Servir immédiatement"]);
|
|
|
|
const translated = await translateRecipeSteps(recipe, "fr");
|
|
|
|
expect(translated.steps[0]).to.deep.equal({
|
|
description: "Faire mijoter à feu doux",
|
|
picture: "https://example.test/step1.jpg",
|
|
techStepIds: [simmerId],
|
|
});
|
|
expect(translated.steps[1]).to.deep.equal({
|
|
description: "Servir immédiatement",
|
|
picture: null,
|
|
techStepIds: [],
|
|
});
|
|
});
|
|
|
|
it("passes every other field through unchanged", async () => {
|
|
const recipe = buildParsedRecipe(["Servir immédiatement"]);
|
|
|
|
const translated = await translateRecipeSteps(recipe, "fr");
|
|
|
|
expect(translated.name).to.equal(recipe.name);
|
|
expect(translated.description).to.equal(recipe.description);
|
|
expect(translated.picture).to.equal(recipe.picture);
|
|
expect(translated.portions).to.equal(recipe.portions);
|
|
expect(translated.sourceUrl).to.equal(recipe.sourceUrl);
|
|
});
|
|
|
|
it("stubs every ingredient's ingredientId/unitId to null, leaving the rest of it untouched — actual ingredient matching is translateRecipeIngredients' job", async () => {
|
|
const recipe = buildParsedRecipe(["Servir immédiatement"]);
|
|
|
|
const translated = await translateRecipeSteps(recipe, "fr");
|
|
|
|
expect(translated.ingredients).to.deep.equal([
|
|
{ ...recipe.ingredients[0], ingredientId: null, unitId: null },
|
|
]);
|
|
});
|
|
|
|
it("gives every step an empty sequence when nothing in it means a known technique", async () => {
|
|
const recipe = buildParsedRecipe([
|
|
"Servir immédiatement",
|
|
"Ranger les couverts dans le tiroir",
|
|
]);
|
|
|
|
const translated = await translateRecipeSteps(recipe, "fr");
|
|
|
|
expect(translated.steps.map((step) => step.techStepIds)).to.deep.equal([[], []]);
|
|
});
|
|
|
|
it("handles a recipe with no steps without error", async () => {
|
|
const recipe = buildParsedRecipe([]);
|
|
|
|
const translated = await translateRecipeSteps(recipe, "fr");
|
|
|
|
expect(translated.steps).to.deep.equal([]);
|
|
});
|
|
});
|
|
|
|
describe("translateRecipeIngredients", () => {
|
|
const tomato: IngredientMatchEntry = { ingredientId: 1, label: "Tomato" };
|
|
const chicken: IngredientMatchEntry = { ingredientId: 2, label: "Chicken" };
|
|
const chickenBreast: IngredientMatchEntry = { ingredientId: 3, label: "Chicken breast" };
|
|
const onion: IngredientMatchEntry = { ingredientId: 4, label: "Onion" };
|
|
|
|
const gram: UnitMatchEntry = { unitId: 10, synonyms: ["g", "gram", "grams"] };
|
|
const cup: UnitMatchEntry = { unitId: 11, synonyms: ["cup", "cups"] };
|
|
|
|
function buildIngredient(
|
|
overrides: Partial<ParsedRecipeIngredient> & { rawText: string; name: string },
|
|
): ParsedRecipeIngredient {
|
|
return { quantity: null, unit: null, ...overrides };
|
|
}
|
|
|
|
it("resolves ingredientId from free-text name, tolerating extra descriptive words and plurals", () => {
|
|
const translated = translateRecipeIngredients(
|
|
[
|
|
buildIngredient({
|
|
rawText: "2 large diced yellow onions",
|
|
name: "large diced yellow onions",
|
|
}),
|
|
],
|
|
[tomato, chicken, chickenBreast, onion],
|
|
[],
|
|
);
|
|
|
|
expect(translated[0].ingredientId).to.equal(onion.ingredientId);
|
|
});
|
|
|
|
it("prefers the more specific multi-word label over a shorter one it contains", () => {
|
|
const translated = translateRecipeIngredients(
|
|
[
|
|
buildIngredient({
|
|
rawText: "2 boneless chicken breasts",
|
|
name: "boneless chicken breasts",
|
|
}),
|
|
],
|
|
[tomato, chicken, chickenBreast, onion],
|
|
[],
|
|
);
|
|
|
|
expect(translated[0].ingredientId).to.equal(chickenBreast.ingredientId);
|
|
});
|
|
|
|
it("returns a null ingredientId when nothing in the catalog matches", () => {
|
|
const translated = translateRecipeIngredients(
|
|
[buildIngredient({ rawText: "1 mango", name: "mango" })],
|
|
[tomato, chicken, chickenBreast, onion],
|
|
[],
|
|
);
|
|
|
|
expect(translated[0].ingredientId).to.equal(null);
|
|
});
|
|
|
|
it("extracts a mixed-number quantity and unit from rawText when the source left them null", () => {
|
|
const translated = translateRecipeIngredients(
|
|
[buildIngredient({ rawText: "1 1/2 cups chicken breast", name: "chicken breast" })],
|
|
[chickenBreast],
|
|
[cup],
|
|
);
|
|
|
|
expect(translated[0].quantity).to.equal(1.5);
|
|
expect(translated[0].unitId).to.equal(cup.unitId);
|
|
});
|
|
|
|
it("trusts the source's own quantity/unit over re-deriving them from rawText", () => {
|
|
const translated = translateRecipeIngredients(
|
|
[
|
|
buildIngredient({
|
|
rawText: "some raw text that happens to mention cups",
|
|
name: "tomato",
|
|
quantity: 3,
|
|
unit: "g",
|
|
}),
|
|
],
|
|
[tomato],
|
|
[gram, cup],
|
|
);
|
|
|
|
expect(translated[0].quantity).to.equal(3);
|
|
expect(translated[0].unitId).to.equal(gram.unitId);
|
|
});
|
|
|
|
it("falls back to the generic 'piece' unit when a quantity was found but no unit word was (issue #53)", () => {
|
|
const piece: UnitMatchEntry = { unitId: 12, synonyms: ["piece", "pieces", "pc", "pcs"] };
|
|
|
|
const translated = translateRecipeIngredients(
|
|
[buildIngredient({ rawText: "4 Egg Yolks", name: "Egg Yolks" })],
|
|
[],
|
|
[gram, cup, piece],
|
|
);
|
|
|
|
expect(translated[0].quantity).to.equal(4);
|
|
expect(translated[0].unitId).to.equal(piece.unitId);
|
|
});
|
|
|
|
it("does not fall back to 'piece' when there's no quantity at all to count", () => {
|
|
const piece: UnitMatchEntry = { unitId: 12, synonyms: ["piece", "pieces", "pc", "pcs"] };
|
|
|
|
const translated = translateRecipeIngredients(
|
|
[buildIngredient({ rawText: "salt to taste", name: "salt" })],
|
|
[],
|
|
[piece],
|
|
);
|
|
|
|
expect(translated[0].quantity).to.equal(null);
|
|
expect(translated[0].unitId).to.equal(null);
|
|
});
|
|
|
|
it("leaves quantity/unitId null when rawText has neither a leading number nor a recognizable unit", () => {
|
|
const translated = translateRecipeIngredients(
|
|
[buildIngredient({ rawText: "salt to taste", name: "salt" })],
|
|
[],
|
|
[],
|
|
);
|
|
|
|
expect(translated[0].quantity).to.equal(null);
|
|
expect(translated[0].unitId).to.equal(null);
|
|
});
|
|
|
|
it("leaves rawText/name/description untouched", () => {
|
|
const ingredient = buildIngredient({ rawText: "1 cup onions", name: "onions" });
|
|
|
|
const translated = translateRecipeIngredients([ingredient], [onion], [cup]);
|
|
|
|
expect(translated[0].rawText).to.equal(ingredient.rawText);
|
|
expect(translated[0].name).to.equal(ingredient.name);
|
|
});
|
|
});
|
|
|
|
describe("mergeDuplicateIngredients", () => {
|
|
const gram: UnitConversionEntry = { id: 1, type: "MASS", toBaseFactor: 1 };
|
|
const kilogram: UnitConversionEntry = { id: 2, type: "MASS", toBaseFactor: 1000 };
|
|
const milliliter: UnitConversionEntry = { id: 3, type: "VOLUME", toBaseFactor: 1 };
|
|
const piece: UnitConversionEntry = { id: 4, type: "COUNT", toBaseFactor: 1 };
|
|
const slice: UnitConversionEntry = { id: 5, type: "COUNT", toBaseFactor: 1 };
|
|
|
|
function buildLine(
|
|
overrides: Partial<TranslatedRecipeIngredient> & { rawText: string },
|
|
): TranslatedRecipeIngredient {
|
|
return {
|
|
name: overrides.rawText,
|
|
quantity: null,
|
|
unit: null,
|
|
ingredientId: null,
|
|
unitId: null,
|
|
...overrides,
|
|
};
|
|
}
|
|
|
|
it("sums the quantity of two lines resolving to the same ingredient, same unit (issue #53 follow-up)", () => {
|
|
const merged = mergeDuplicateIngredients(
|
|
[
|
|
buildLine({ rawText: "100g Sugar", ingredientId: 1, quantity: 100, unitId: gram.id }),
|
|
buildLine({ rawText: "45g Sugar", ingredientId: 1, quantity: 45, unitId: gram.id }),
|
|
],
|
|
[gram, kilogram, milliliter, piece, slice],
|
|
);
|
|
|
|
expect(merged).to.have.length(1);
|
|
expect(merged[0].quantity).to.equal(145);
|
|
expect(merged[0].unitId).to.equal(gram.id);
|
|
expect(merged[0].rawText).to.equal("100g Sugar + 45g Sugar");
|
|
});
|
|
|
|
it("converts through toBaseFactor when the duplicate uses a different unit of the same type", () => {
|
|
const merged = mergeDuplicateIngredients(
|
|
[
|
|
buildLine({ rawText: "500g Flour", ingredientId: 1, quantity: 500, unitId: gram.id }),
|
|
buildLine({
|
|
rawText: "0.5kg Flour",
|
|
ingredientId: 1,
|
|
quantity: 0.5,
|
|
unitId: kilogram.id,
|
|
}),
|
|
],
|
|
[gram, kilogram, milliliter, piece, slice],
|
|
);
|
|
|
|
expect(merged).to.have.length(1);
|
|
expect(merged[0].quantity).to.equal(1000);
|
|
expect(merged[0].unitId).to.equal(gram.id);
|
|
});
|
|
|
|
it("keeps duplicate COUNT-unit lines separate rather than guessing — a slice isn't a piece", () => {
|
|
const merged = mergeDuplicateIngredients(
|
|
[
|
|
buildLine({ rawText: "2 piece Bread", ingredientId: 1, quantity: 2, unitId: piece.id }),
|
|
buildLine({ rawText: "3 slice Bread", ingredientId: 1, quantity: 3, unitId: slice.id }),
|
|
],
|
|
[gram, kilogram, milliliter, piece, slice],
|
|
);
|
|
|
|
expect(merged).to.have.length(2);
|
|
});
|
|
|
|
it("keeps duplicate lines with incompatible unit types separate (MASS vs VOLUME)", () => {
|
|
const merged = mergeDuplicateIngredients(
|
|
[
|
|
buildLine({ rawText: "200g Milk", ingredientId: 1, quantity: 200, unitId: gram.id }),
|
|
buildLine({
|
|
rawText: "200ml Milk",
|
|
ingredientId: 1,
|
|
quantity: 200,
|
|
unitId: milliliter.id,
|
|
}),
|
|
],
|
|
[gram, kilogram, milliliter, piece, slice],
|
|
);
|
|
|
|
expect(merged).to.have.length(2);
|
|
});
|
|
|
|
it("never merges two unresolved lines (ingredientId: null) together", () => {
|
|
const merged = mergeDuplicateIngredients(
|
|
[
|
|
buildLine({ rawText: "1 vanilla pod", quantity: 1 }),
|
|
buildLine({ rawText: "1 vanilla pod", quantity: 1 }),
|
|
],
|
|
[gram, kilogram, milliliter, piece, slice],
|
|
);
|
|
|
|
expect(merged).to.have.length(2);
|
|
});
|
|
|
|
it("leaves non-duplicate lines untouched and preserves order", () => {
|
|
const sugar = buildLine({ rawText: "Sugar", ingredientId: 1, quantity: 1, unitId: gram.id });
|
|
const salt = buildLine({ rawText: "Salt", ingredientId: 2, quantity: 1, unitId: gram.id });
|
|
|
|
const merged = mergeDuplicateIngredients([sugar, salt], [gram, kilogram, milliliter]);
|
|
|
|
expect(merged).to.deep.equal([sugar, salt]);
|
|
});
|
|
});
|
|
|
|
describe("translateRecipe", () => {
|
|
beforeEach(async () => {
|
|
await resetDatabase();
|
|
});
|
|
|
|
after(async () => {
|
|
await prisma.$disconnect();
|
|
});
|
|
|
|
it("resolves real TechStep ids from the seeded French catalog", async () => {
|
|
const simmer = await prisma.techStep.findFirstOrThrow({ where: { key: "simmer" } });
|
|
const chop = await prisma.techStep.findFirstOrThrow({ where: { key: "chop" } });
|
|
const recipe = buildParsedRecipe(["Hacher les oignons", "Faire mijoter à feu doux"]);
|
|
|
|
const translated = await translateRecipe(recipe, "fr");
|
|
|
|
expect(translated.steps.map((step) => step.techStepIds)).to.deep.equal([
|
|
[chop.id],
|
|
[simmer.id],
|
|
]);
|
|
});
|
|
|
|
it("finds nothing for English text against the French catalog — locales are separate rule sets, never mixed", async () => {
|
|
// A step lifted verbatim from a real TheMealDB recipe.
|
|
const recipe = buildParsedRecipe([
|
|
"Bring a large saucepan of salted water to the boil",
|
|
"Chop the onions finely",
|
|
]);
|
|
|
|
const translated = await translateRecipe(recipe, "fr");
|
|
|
|
expect(translated.steps.map((step) => step.techStepIds)).to.deep.equal([[], []]);
|
|
});
|
|
|
|
it("resolves real TechStep ids from the seeded English catalog", async () => {
|
|
const boil = await prisma.techStep.findFirstOrThrow({ where: { key: "boil" } });
|
|
const chop = await prisma.techStep.findFirstOrThrow({ where: { key: "chop" } });
|
|
// Same two steps as the French/English mismatch test above, this
|
|
// time matched against the matching-language catalog.
|
|
const recipe = buildParsedRecipe([
|
|
"Bring a large saucepan of salted water to the boil",
|
|
"Chop the onions finely",
|
|
]);
|
|
|
|
const translated = await translateRecipe(recipe, "en");
|
|
|
|
expect(translated.steps.map((step) => step.techStepIds)).to.deep.equal([
|
|
[boil.id],
|
|
[chop.id],
|
|
]);
|
|
});
|
|
|
|
it("finds nothing for a locale with no mappings at all", async () => {
|
|
const recipe = buildParsedRecipe(["Faire mijoter à feu doux"]);
|
|
|
|
const translated = await translateRecipe(recipe, "de");
|
|
|
|
expect(translated.steps.map((step) => step.techStepIds)).to.deep.equal([[]]);
|
|
});
|
|
|
|
it("resolves real Ingredient/Unit ids from the seeded English catalog for an 'en' translation", async () => {
|
|
const onion = await prisma.ingredient.findFirstOrThrow({ where: { key: "onion" } });
|
|
const cup = await prisma.unit.findFirstOrThrow({ where: { key: "cup" } });
|
|
const recipe: ParsedRecipe = {
|
|
...buildParsedRecipe(["Chop the onions finely"]),
|
|
ingredients: [
|
|
{ rawText: "1 cup onions, chopped", quantity: null, unit: null, name: "onions" },
|
|
],
|
|
};
|
|
|
|
const translated = await translateRecipe(recipe, "en");
|
|
|
|
expect(translated.ingredients).to.deep.equal([
|
|
{
|
|
rawText: "1 cup onions, chopped",
|
|
quantity: 1,
|
|
unit: null,
|
|
name: "onions",
|
|
ingredientId: onion.id,
|
|
unitId: cup.id,
|
|
},
|
|
]);
|
|
});
|
|
|
|
it("resolves a real Ingredient id from the seeded French catalog, tolerating a regular French plural", async () => {
|
|
const carrot = await prisma.ingredient.findFirstOrThrow({ where: { key: "carrot" } });
|
|
const recipe: ParsedRecipe = {
|
|
...buildParsedRecipe(["Faire mijoter à feu doux"]),
|
|
ingredients: [{ rawText: "3 carottes", quantity: null, unit: null, name: "carottes" }],
|
|
};
|
|
|
|
const translated = await translateRecipe(recipe, "fr");
|
|
|
|
expect(translated.ingredients[0]?.ingredientId).to.equal(carrot.id);
|
|
expect(translated.ingredients[0]?.quantity).to.equal(3);
|
|
});
|
|
|
|
it("resolves a real multi-word Unit id from the seeded French catalog (issue: matchUnit used to only ever compare a single word)", async () => {
|
|
const wheatFlour = await prisma.ingredient.findFirstOrThrow({ where: { key: "wheatFlour" } });
|
|
const tablespoon = await prisma.unit.findFirstOrThrow({ where: { key: "tablespoon" } });
|
|
const recipe: ParsedRecipe = {
|
|
...buildParsedRecipe(["Faire mijoter à feu doux"]),
|
|
ingredients: [
|
|
{
|
|
rawText: "2 cuillères à soupe de farine de blé",
|
|
quantity: null,
|
|
unit: null,
|
|
name: "farine de blé",
|
|
},
|
|
],
|
|
};
|
|
|
|
const translated = await translateRecipe(recipe, "fr");
|
|
|
|
expect(translated.ingredients[0]).to.deep.equal({
|
|
rawText: "2 cuillères à soupe de farine de blé",
|
|
quantity: 2,
|
|
unit: null,
|
|
name: "farine de blé",
|
|
ingredientId: wheatFlour.id,
|
|
unitId: tablespoon.id,
|
|
});
|
|
});
|
|
|
|
it("still extracts a locale-agnostic quantity even for a locale with no ingredient/unit matching data at all, leaving only the ids null", async () => {
|
|
const recipe: ParsedRecipe = {
|
|
...buildParsedRecipe(["Faire mijoter à feu doux"]),
|
|
ingredients: [
|
|
{ rawText: "1 cup onions, chopped", quantity: null, unit: null, name: "onions" },
|
|
],
|
|
};
|
|
|
|
const translated = await translateRecipe(recipe, "de");
|
|
|
|
expect(translated.ingredients).to.deep.equal([
|
|
{
|
|
rawText: "1 cup onions, chopped",
|
|
quantity: 1,
|
|
unit: null,
|
|
name: "onions",
|
|
ingredientId: null,
|
|
unitId: null,
|
|
},
|
|
]);
|
|
});
|
|
});
|
|
});
|