Distribución y consumo

Build

cd emafhir
npm install
npm run build       # tsup → dist/
npm test            # vitest

tsup genera ESM con types, splitting y treeshake activos. Configurado con 6 entry points (los 6 subpaths exportados):

dist/
├── index.{js,d.ts}
├── auth/index.{js,d.ts}
├── search/index.{js,d.ts}
├── types/index.{js,d.ts}
├── sdc/index.{js,d.ts}
└── validators/index.{js,d.ts}

Target: ES2022, ESM-only.

Versionado

Semver. Versión actual 0.6.0. Mantiene CHANGELOG.md desde 0.2.0. Cada bump corresponde a una serie de decisiones formales registradas en docs/decisions.md (formato F{NNN}).

Versión	Hito
0.2.x	35 tipos handcrafted + ResourceTypeMap
0.5.x	helpers (ref, transaction, search) + auth strategies
0.6.0	Wave 1: EmaFhirClient + ProfileResolver runtime + meta-inject + validators + opt-in $translate

Publicación

Hoy se distribuye como GitHub dependency consumida directamente desde github:emahealth/emafhir. El consumidor pin-ea el tag o branch en su package.json:

{
  "dependencies": {
    "emafhir": "github:emahealth/emafhir#v0.6.0"
  }
}

Nota

La publicación a npm registry está prevista pero no es bloqueante. Mientras tanto, GitHub dep funciona para todos los productos del ecosistema.

Consumidores

Producto	Estado	Cliente que usa
emaclinic	Migrado a Wave 1	createEmaClient({ tenant, supabase })
emalab	Pendiente Wave 3	createClient() legacy
emavault	Pendiente Wave 3	createClient() legacy
emawell	Pendiente Wave 3	createClient() legacy

Cuando un producto migra:

1. Bump de versión del SDK en su package.json.
2. Agregar peer dep @supabase/supabase-js >= 2.49.
3. Cambiar createClient(...) → createEmaClient({ tenant, supabase }).
4. Verificar tests con tenant context real.

Tests

npm test                 # unit tests (vitest, sin red)
npm run test:integration # smoke tests contra Aidbox edge (gated)

Los smoke tests requieren las siguientes env vars; si faltan, CI los omite silenciosamente:

TEST_AIDBOX_URL
TEST_AIDBOX_CLIENT_ID
TEST_AIDBOX_CLIENT_SECRET
TEST_TENANT_ID
TEST_TENANT_COUNTRY
TEST_SUPABASE_URL
TEST_SUPABASE_KEY

Precaución

CI nunca depende de Aidbox vivo. Los integration tests son optativos y se ejecutan localmente o en pipelines que tengan los secrets. Esto permite que el SDK se buildee y publique sin acoplarse a la disponibilidad del backend.

CI

GitHub Actions corre en cada PR:

• npm install
• npm run build (tsup)
• npm test (unit suite, sin red)

Los smoke tests Aidbox quedan en un job separado, gated por secrets disponibles solo en la rama main y en releases.

Coverage

Sin reportes formales hoy. Estimado ~70% basado en LOC test vs LOC src (10+ test files / 3K LOC core). Plan: agregar vitest --coverage a CI en una iteración futura.