cap-nodejs

Package Export Surface

CAP Node.js packages define stable public entry points through package root declarations and, where present, package exports maps. Treat those entry points as the supported application contract.

Package roots stay framework-neutral unless the package is itself a framework integration. Optional framework wrappers live behind explicit framework subpaths, such as /nest.

Stable Root Imports

Use package roots for framework-neutral APIs and for packages whose primary purpose is a framework integration:

import { CapEngine } from '@mikara89/cap-core';
import { createCapMessageEnvelope } from '@mikara89/cap-core';
import type { CapStorageCapabilities } from '@mikara89/cap-core';
import { CapModule, CapService, CapSubscribe } from '@mikara89/cap-nest';
import { createTestCapEngine } from '@mikara89/cap-testing';
import { createCapExpress } from '@mikara89/cap-express';
import { MikroPublishStorage } from '@mikara89/cap-storage-mikro-orm';
import { KnexPublishStorage } from '@mikara89/cap-storage-knex';
import { TypeOrmPublishStorage } from '@mikara89/cap-storage-typeorm';
import { PrismaPublishStorage } from '@mikara89/cap-storage-prisma';
import { ServiceBusPublisher } from '@mikara89/cap-transport-azure-servicebus';
import { NestjsMicroservicesTransportModule } from '@mikara89/cap-transport-nestjs-microservices';
import { KafkaPublisher, KafkaSubscriber } from '@mikara89/cap-transport-kafka';
import {
  AwsSnsPublisher,
  AwsSqsSubscriber,
} from '@mikara89/cap-transport-aws-sns-sqs';
import { CapDashboardModule } from '@mikara89/cap-dashboard-nest';
import { createCapDashboardRouter } from '@mikara89/cap-dashboard-express';

The supported package roots are:

@mikara89/cap-dashboard remains supported as a compatibility alias for the Nest dashboard package root.

@mikara89/cap-core exports the versioned envelope constants, types, creator, guard, decoder, and typed decode errors from its package root. @mikara89/cap-nest mirrors that envelope surface because it already mirrors core messaging types.

The v2.3 storage roots expose their complete framework-free APIs:

Package Public root surface
@mikara89/cap-storage-knex Schema initializer and options, publish/received storage classes, transaction manager, and capability helper
@mikara89/cap-storage-typeorm Schema initializer and options, publish/received storage classes, transaction manager, and capability helper
@mikara89/cap-storage-prisma Raw-SQL schema initializer and options, Prisma client/executor types, publish/received storage classes, transaction manager, and capability helper

These roots export no NestJS or Express integration and no test fixtures. The Prisma root works through raw SQL and does not require CAP models in the application Prisma schema. Their transaction contexts are Knex.Transaction, TypeORM EntityManager, and Prisma.TransactionClient, respectively.

Planned packages are not exported until they are implemented and released. Do not import future storage package names such as @mikara89/cap-storage-drizzle, and do not import future transport package names such as @mikara89/cap-transport-nats, unless those packages exist in the workspace and are listed here as supported package roots.

Nest Wrapper Imports

Adapter package roots do not export Nest wrappers. Import Nest integrations from explicit /nest subpaths:

import { MikroStorageModule } from '@mikara89/cap-storage-mikro-orm/nest';
import { KnexStorageModule } from '@mikara89/cap-storage-knex/nest';
import { TypeOrmStorageModule } from '@mikara89/cap-storage-typeorm/nest';
import { PrismaStorageModule } from '@mikara89/cap-storage-prisma/nest';
import { ServiceBusTransportModule } from '@mikara89/cap-transport-azure-servicebus/nest';

The supported Nest wrapper subpaths are:

Nest peer dependencies for adapter packages are required only when using these /nest exports.

Compatibility Subpaths

The module-specific Nest subpaths are intentional compatibility exports:

Keep these subpaths stable so existing Nest-facing consumers can migrate away from package-root wrapper imports without taking another breaking change.

Unsupported Deep Imports

Imports from package internals are not part of the public API:

// Avoid: internal path, not covered by compatibility guarantees.
import { CapService } from '@mikara89/cap-nest/dist/cap/cap.service';

Do not rely on dist/*, source-folder, or other implementation paths in application code. If an internal symbol is useful to applications, promote it through a documented package export before recommending it.

This site is open source. Improve this page.