devops
6be8dd409c
Instala @rokmohar/medusa-plugin-meilisearch@^1.4.1 (linea v1, la unica compatible con nuestro Medusa 2.18.0 exacto -- confirmado contra peerDependencies reales de npm: @medusajs/* ^2.15.2, satisfecho por 2.18.0). Conectado via un array `plugins:` nuevo en medusa-config.ts (primer uso en este repo, no `modules:`), env vars leidos con `?? ""` en vez de required() -- si Meilisearch esta caido o mal configurado, el plugin se degrada solo en vez de tumbar el arranque de Medusa entero. No se escribe un subscriber propio: se verifico contra el codigo fuente real del paquete (descargado el tarball exacto de npm, inspeccionado en /app/node_modules dentro de una imagen Docker de verdad) que trae sus propios subscribers de product/category/ collection/variant/etc, descubiertos por Medusa en runtime desde dentro del propio paquete -- confirmado que sobreviven a `npm prune --omit=dev` y llegan intactos a la imagen final. Tambien trae un job de indexado inicial de una sola corrida al boot (numberOfExecutions: 1, no un cron recurrente -- no viola la restriccion del ADR de "nunca cron"). Nueva ruta Store API propia (src/api/store/search/route.ts): las rutas /store/meilisearch/* que trae el plugin no devuelven facetDistribution (verificado leyendo su codigo fuente), asi que esta ruta pide facets explicitamente via additionalOptions.facets, y despues re-hidrata los productos via query.graph (mismos campos que ya usa el storefront) en vez de confiar en precios/inventario indexados -- mismo patron "safe path" que ya usa la ruta oficial del plugin para /store/meilisearch/products. Transformer custom en medusa-config.ts que espeja mapProduct() del storefront (category/collection/brand/ageRange desde metadata, disponibilidad desde la primera variante) para que el documento indexado sea exactamente lo que el storefront ya muestra. Validado en vivo: build completo de Docker (target builder) corre limpio -- npm ci, medusa build (typecheck + compile backend/frontend), npm prune -- cero errores. package-lock.json regenerado con un contenedor node:22.18.0-bookworm-slim real (mismo base image que el Dockerfile), no a mano. Dockerfile: dummy MEILISEARCH_HOST/MEILISEARCH_API_KEY en el stage de build (insurance barata, no son required() asi que no eran estrictamente necesarios para que el build pasara, y de hecho paso sin ellos en la prueba -- se dejan de todas formas por consistencia con el resto de dummies de esa capa).