evlog.
Shared packages

Shared packages overview

Package catalogs, drains, enrichers, and framework integrations as reusable npm libraries — same scaffolding pattern for each, type-level discoverability flows transitively to consumers.

evlog's extension surfaces are pure TypeScript: any plugin, drain, enricher, or catalog you can write in your own project, you can also publish as an npm package and import it from another project. This is how you scale evlog across many apps in your organization without copy-pasting code.

Same pattern for every type:

  1. Define the artifact (catalog, drain, enricher, integration) in src/
  2. Add a declare module 'evlog' augmentation when type-level discoverability is useful
  3. Build dual .mjs + .d.mts with tsdown (or any bundler that emits these)
  4. List evlog as a peerDependency

Pages here

WhatWhen
Catalogs as packagesPublish a typed error / audit catalogSeveral services share the same error vocabulary
Drains as packagesPublish a custom drain (a new provider, an internal API…)You ship the same destination from many apps
Enrichers as packagesPublish a custom enricher (geo, tenant, deploy id…)Multiple apps need the same derived context
Integration as packagePublish a custom framework integration (a new HTTP runtime, a queue worker…)You support runtime X and want others to benefit

Why bother

Three concrete wins :

  • Single source of truth — one repo owns the artifact; consumers bump a version
  • Type-level discoverability — declare module 'evlog' propagates to consumers via the published .d.mts
  • Documented intent — why, fix, severity, etc. ride along with the type, not in a wiki

Examples to ship

  • @my-org/evlog-stripe-errors — error catalog matching every Stripe API code
  • @my-org/evlog-tenant-enricher — pulls x-tenant-id from headers on every event
  • @my-org/evlog-fly-region — adds region: process.env.FLY_REGION to every event
  • @my-org/evlog-internal-loki — drain that ships to your internal Loki instance
  • @my-org/evlog-medusa — framework integration for Medusa.js

Cross-app error vocab

One `@my-org/evlog-errors` package every service depends on — same error codes, same `why` / `fix` strings, type-safe everywhere.

Catalogs as packages

Package an error catalog or audit catalog as a reusable npm module — `@my-org/evlog-stripe-errors`, `@my-org/evlog-aws-audit`, etc.