@nest-batch/core 0.2.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 easdkr
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,368 @@
+# `@nest-batch/core`
+
+A lightweight, NestJS-coupled batch processing core modelled after Spring
+Batch. `@nest-batch/core` owns the **batch engine**: Job/Step/Chunk/Tasklet
+semantics, checkpoint, restart, skip, chunk transaction, and business retry.
+It does not own persistence, transport, or scheduling. Those live in
+[sibling packages](#what-is-not-in-core).
+
+The package is dependency-light on purpose. It only pulls in
+`@nestjs/common`, `@nestjs/core`, and `reflect-metadata`. Anything
+specific to a database, a queue, or a scheduler is injected through
+tokens at the DI boundary, so a host app can swap persistence and
+transport without touching the core.
+
+---
+
+## Install
+
+```bash
+pnpm add @nest-batch/core
+```
+
+Peer dependencies are pulled in by the host app:
+
+| Package            | Range     |
+| ------------------ | --------- |
+| `@nestjs/common`   | `^11.0.0` |
+| `@nestjs/core`     | `^11.0.0` |
+| `reflect-metadata` | `^0.2.2`  |
+
+Core supports Nest 10 and 11.
+
+---
+
+## Conceptual model
+
+The model is a direct port of Spring Batch's mental model. If you've
+written a Spring Batch job, you already know 80% of this.
+
+```
+Job
+└── Step (one or more)
+    ├── Chunk step  (read → process → write in fixed-size chunks)
+    │   ├── ItemReader<T>
+    │   ├── ItemProcessor<T, R>
+    │   └── ItemWriter<R>
+    └── Tasklet       (single-method work unit, no chunking)
+```
+
+### Job
+
+A named unit of work. The host app declares one with the `@Jobable`
+decorator or the `BatchBuilder` fluent API. A job has:
+
+- a unique `id`
+- an ordered list of `Step`s
+- a `JobParameters` shape (the params that pin a `JobInstance`)
+
+### Step
+
+A step is either a **chunk step** or a **tasklet step**. The compiler
+decides which one based on which handler method you provide. Each step
+runs inside a `StepExecution` row in the batch meta schema, and the
+`StepExecution.id` is the unit of restart/checkpoint.
+
+### Chunk step
+
+A chunk step reads `chunkSize` items, processes them, writes them, and
+repeats until the reader is exhausted. The chunk is the unit of
+transaction: if any item in the chunk fails, the whole chunk rolls
+back. This is the model Spring Batch uses, and we keep it.
+
+The reader, processor, and writer are plain Nest providers. You can
+declare them with `@ItemReader`, `@ItemProcessor`, `@ItemWriter` (under
+the `BatchDecorators` namespace) or with method references on the job
+class itself. Three reference kinds are accepted:
+
+- `BuilderLambda` — a function value captured by the builder.
+- `Method` — a method on the job class.
+- `ProviderToken` — a Nest DI token resolved at runtime.
+
+### Tasklet step
+
+A single method that runs to completion. Useful for one-off work that
+doesn't fit the read/process/write shape (e.g. "run this SQL and
+move on"). A tasklet is the right answer when you don't need chunking,
+skip, or restart.
+
+### Listeners
+
+Listeners fire around every transition in the engine. You tag a method
+on your provider with one of the listener decorators, and the engine
+calls it at the right moment. The full set:
+
+| Decorator         | Fires                                         |
+| ----------------- | --------------------------------------------- |
+| `@BeforeJob`      | Before a job execution starts.                |
+| `@AfterJob`       | After a job execution finishes (any status).  |
+| `@BeforeStep`     | Before a step execution starts.               |
+| `@AfterStep`      | After a step execution finishes (any status). |
+| `@BeforeChunk`    | Before each chunk (read-process-write cycle). |
+| `@AfterChunk`     | After each chunk finishes successfully.       |
+| `@OnChunkError`   | When a chunk throws.                          |
+| `@BeforeRead`     | Before each item is read.                     |
+| `@AfterRead`      | After each item is read.                      |
+| `@OnReadError`    | When the reader throws.                       |
+| `@BeforeProcess`  | Before each item is processed.                |
+| `@AfterProcess`   | After each item is processed.                 |
+| `@OnProcessError` | When the processor throws.                    |
+| `@BeforeWrite`    | Before the writer receives a chunk.           |
+| `@AfterWrite`     | After the writer finishes a chunk.            |
+| `@OnWriteError`   | When the writer throws.                       |
+| `@OnSkipRead`     | When a read is skipped by the skip policy.    |
+| `@OnSkipProcess`  | When a processed item is skipped.             |
+| `@OnSkipWrite`    | When a write is skipped.                      |
+
+You can mark a listener as `nonCritical: true` via
+`@BeforeJob({ nonCritical: true })` if the engine should swallow
+exceptions from it. A critical listener that throws fails the
+execution.
+
+### Skip and retry policies
+
+Skip and retry are Batch Core concerns, not transport concerns. The
+default policy is "fail on first error", and you can swap in:
+
+- `LimitSkipPolicy` — skip up to N items of a given kind
+  (read/process/write), then fail.
+- `ClassifySkipPolicy` — skip based on the exception class.
+- `ExponentialBackoffRetryPolicy` — retry with exponential backoff.
+- `FixedDelayRetryPolicy` — retry with a fixed delay.
+
+The BullMQ package reuses these policies. It does **not** reimplement
+them. See "what is NOT in core" below.
+
+---
+
+## Polymorphic `JobLauncher`
+
+`JobLauncher` is the public entry point for starting a job. Its
+signature is:
+
+```ts
+launch(jobId: string, params: JobParameters = {}): Promise<JobExecution>
+```
+
+The launcher does:
+
+1. Look up the `JobDefinition` from the registry. Missing → `JobNotFoundError`.
+2. Canonicalize `params` into a stable `jobKey` hash. Object key
+   order, `null/undefined` omission, `Date → ISO` are all normalized
+   so semantically-identical params yield the same key.
+3. `createExecutionAtomic(jobId, jobKey, params)` — atomic
+   get-or-create instance + `SELECT ... FOR UPDATE SKIP LOCKED` to
+   serialize concurrent launches + running-execution check + insert.
+4. Delegate to whatever `IExecutionStrategy` is bound to the
+   `EXECUTION_STRATEGY` token. The default is the in-process strategy;
+   `@nest-batch/bullmq` overrides it with a transport strategy.
+
+`IExecutionStrategy` is the polymorphism seam:
+
+```ts
+export interface IExecutionStrategy {
+  readonly name: string;
+  launch(
+    job: JobDefinition,
+    params: JobParameters,
+    ctx: ExecutionStrategyContext,
+  ): Promise<LaunchResult>;
+}
+```
+
+`LaunchResult` is a discriminated union:
+
+- `{ kind: 'completed', status }` — the strategy ran to a terminal
+  state in-process. The launcher resolves the persisted
+  `JobExecution` and returns it.
+- `{ kind: 'enqueued', queueJobId }` — the strategy handed off to a
+  transport. The launcher still resolves the latest persisted
+  `JobExecution` (which is in `STARTING` / `STARTED` because the
+  executor has not run yet on the launcher process).
+
+The `JobLauncher.launch` API is intentionally stable. Strategies
+change; the public surface does not.
+
+---
+
+## Module wiring
+
+```ts
+import { Module } from '@nestjs/common';
+import {
+  NestBatchModule,
+  JobRepository,
+  TransactionManager,
+  InProcessExecutionStrategy,
+  IN_PROCESS_EXECUTION_STRATEGY_PROVIDER,
+} from '@nest-batch/core';
+import { MikroORMJobRepository, MikroORMTransactionManager } from '@nest-batch/mikro-orm';
+import { MikroOrmModule } from '@mikro-orm/nestjs';
+import { BATCH_META_ENTITIES } from '@nest-batch/mikro-orm';
+import { ProductEntity } from './entities/product.entity';
+
+@Module({
+  imports: [
+    MikroOrmModule.forRoot({
+      entities: [ProductEntity, ...BATCH_META_ENTITIES],
+      // ...
+    }),
+    NestBatchModule.forRoot(),
+  ],
+  providers: [
+    { provide: JobRepository, useClass: MikroORMJobRepository },
+    { provide: TransactionManager, useClass: MikroORMTransactionManager },
+    InProcessExecutionStrategy,
+    IN_PROCESS_EXECUTION_STRATEGY_PROVIDER,
+  ],
+})
+export class AppModule {}
+```
+
+`NestBatchModule` is `global: true`, so sub-modules don't have to
+import it again. The module exports `JobRegistry`, `DefinitionCompiler`,
+`BatchExplorer`, `FlowEvaluator`, and `BatchScheduleRegistry` so
+consumers can inject them from outside.
+
+`forRootAsync` is also available when the repository/strategy bindings
+need to come from a config service or another async source:
+
+```ts
+NestBatchModule.forRootAsync({
+  imports: [ConfigModule],
+  inject: [ConfigService],
+  useFactory: (cfg: ConfigService) => ({
+    repository: {
+      provide: JOB_REPOSITORY_TOKEN,
+      useClass: cfg.get<Type<JobRepository>>('BATCH_REPOSITORY'),
+    },
+  }),
+});
+```
+
+---
+
+## Listener resolver
+
+Listeners are discovered by walking every `@Jobable` class the
+`BatchExplorer` finds, reading the `BATCH_LISTENER_METADATA` slot from
+each method, and building a per-job, per-step resolver map. The map
+is populated once at `OnApplicationBootstrap` (see
+`BatchBootstrapper`) and is read on every transition.
+
+Critical vs non-critical semantics:
+
+- A **critical** listener that throws fails the execution. The
+  executor records the failure and the listener exception is part of
+  the failure context.
+- A **non-critical** listener that throws is logged and contained. The
+  execution continues.
+
+The two paths are separated on purpose. Critical listener failures
+should be loud, non-critical ones should not poison the run.
+
+---
+
+## Contract suite
+
+`@nest-batch/core` ships a contract suite that the adapter packages
+use to prove they implement the repository and transaction
+contracts correctly. It is exposed at
+`@nest-batch/core/test-contracts`:
+
+```ts
+import {
+  runJobRepositoryContract,
+  runTransactionManagerContract,
+} from '@nest-batch/core/test-contracts';
+```
+
+The contract covers:
+
+- `getOrCreateJobInstance` — idempotency, concurrent creation.
+- `createExecutionAtomic` — atomicity, lock semantics, running-execution guard.
+- `updateJobExecution` / `getJobExecution` — round-trip integrity.
+- `createStepExecution` / `updateStepExecution` / `getStepExecution` — same for step rows.
+- `getExecutionContext` / `saveExecutionContext` — versioning, optimistic concurrency.
+- `findLatestStepExecution` — restart/checkpoint lookup; must return
+  the most recent `StepExecution` for `(jobExecutionId, stepName)`.
+- `TransactionManager` — wrap / commit / rollback / nested.
+
+`@nest-batch/mikro-orm` and `@nest-batch/typeorm` both run this suite
+against their implementations. The in-memory reference implementation
+in core also passes it. If you write a custom adapter, the suite is
+how you prove it satisfies the contract.
+
+---
+
+## Public API surface
+
+Everything in `@nest-batch/core` is reachable from the package root.
+The barrel re-exports:
+
+- `./core` — IR (`JobDefinition`, `StepDefinition`, ...), errors, status, execution context, item interfaces, repository/transaction contracts.
+- `./compiler` — turns discovered jobs into compiled IR.
+- `./registry` — `JobRegistry` and friends.
+- `./execution` — `JobLauncher`, `JobExecutor`, `InProcessExecutionStrategy`, `IExecutionStrategy`, `EXECUTION_STRATEGY`, `ChunkStepExecutor`, `TaskletStepExecutor`, `ListenerInvoker`, `RefResolver`.
+- `./transaction` — `TransactionManager` token and contract.
+- `./repository` — `JobRepository` token, contract, in-memory reference, ID generators.
+- `./decorators` — under the `BatchDecorators` namespace (`@Jobable`, `@ItemReader`, `@ItemProcessor`, `@ItemWriter`, `@Tasklet`, listener decorators, `@BatchScheduled`).
+- `./module` — `NestBatchModule`, tokens, options.
+- `./builder` — fluent `BatchBuilder`, `JobBuilder`, `StepBuilder`, `FlowBuilder`.
+- `./explorer` — `BatchExplorer` (the metadata scanner).
+- `./listeners` — built-in `LoggingListener`, `MetricsListener`, `TimingListener` reference implementations.
+- `./policies` — `LimitSkipPolicy`, `ClassifySkipPolicy`, retry policies, backoff helpers.
+- `./flow` — `FlowEvaluator` for the `on` / `from` / `end` flow DSL.
+- `./observability` — `BatchObserver` contract, `BATCH_EVENT` constants, `NoopBatchObserver` default.
+
+Decorator names collide with interface names (e.g. `Tasklet` is both a
+decorator and an interface). Decorators are re-exported under
+`BatchDecorators`; interfaces are reachable as bare names from
+`./core/item`. This is intentional.
+
+---
+
+## What is NOT in core
+
+Core is the engine. The following live in sibling packages and are
+injected at the DI boundary:
+
+| Concern                       | Package                 | Why                                                               |
+| ----------------------------- | ----------------------- | ----------------------------------------------------------------- |
+| **Persistence (PostgreSQL)**  | `@nest-batch/mikro-orm` | Ships the 6 batch meta tables, entities, and migrations.          |
+| **Persistence (TypeORM 1.0)** | `@nest-batch/typeorm`   | Ships the same 6 tables as TypeORM 1.0.0 entities + migration.    |
+| **Transport (BullMQ)**        | `@nest-batch/bullmq`    | The Redis-backed execution strategy. Owns Queue/Worker lifecycle. |
+| **Drizzle**                   | _not in this release_   | Explicitly excluded and deferred. See `MIGRATION.md`.             |
+
+Core itself does **not** ship:
+
+- A default `JobRepository` (the choice of DB is the host's).
+- A default `TransactionManager` (same).
+- A default transport (in-process is the default; siblings override).
+- An admin UI.
+- A metrics backend (Prometheus, OpenTelemetry, ...).
+- A tracing backend.
+- A webhook or notification system.
+- A job visualization dashboard.
+- Multi-tenant routing.
+
+These are out of scope by design. If you need one, write a
+`BatchObserver` adapter that hooks into the event stream, or open an
+issue if you think it belongs in core.
+
+---
+
+## Scripts
+
+```bash
+pnpm --filter @nest-batch/core build      # SWC transpile + tsc declarations
+pnpm --filter @nest-batch/core test       # vitest run
+pnpm --filter @nest-batch/core test:watch # vitest watch
+pnpm --filter @nest-batch/core test:e2e   # vitest e2e (requires Postgres/Redis)
+pnpm --filter @nest-batch/core typecheck  # tsc --noEmit
+```
+
+The boundary test (`tests/core/boundary/no-forbidden-imports.test.ts`)
+guards core's dependency-light promise. It fails the build if any
+forbidden package (`bullmq`, `mikro-orm`, `typeorm`, `drizzle-orm`,
+`cron`) shows up as a core import.

package/dist/src/adapters/in-process.adapter.d.ts

@@ -0,0 +1,140 @@
+import type { BatchAdapter } from '../module/adapter';
+/**
+ * Empty Nest module class that owns the in-process execution-strategy
+ * providers.
+ *
+ * The class has no body on purpose: it is purely a `DynamicModule`
+ * carrier for the `forRoot()` factory below. Nest's module system
+ * requires *some* class to identify the module — the empty class is
+ * the minimum possible surface and keeps the runtime allocation at
+ * one class (no decorators, no lifecycle hooks, no metadata).
+ */
+export declare class InProcessModule {
+}
+/**
+ * `InProcessAdapter` — the default transport adapter for
+ * `@nest-batch/core`.
+ *
+ * This is the **no-Redis** transport: jobs run synchronously inside
+ * the launching process via `JobExecutor.execute(...)`, on the same
+ * event loop that called `JobLauncher.launch(...)`. There is no
+ * queue, no worker, no Redis connection, no AOF / Lua scripts /
+ * stream events. The whole point of this adapter is to be the
+ * "no transport runtime at all" option.
+ *
+ * Use it when:
+ *
+ *   - You do not need horizontal scale-out (one process, one
+ *     launcher, jobs run inline).
+ *   - You want the cheapest possible deployment — no extra
+ *     infrastructure, no extra process to supervise.
+ *   - You are building a library / dev-time harness and the queue
+ *     runtime would be in the way.
+ *   - You are migrating an existing batch app and want to validate
+ *     the engine end-to-end before turning on a real transport.
+ *
+ * Switch to `@nest-batch/bullmq` (or a future transport) when you
+ * need cross-process work distribution, technical retry at the
+ * transport layer, or a queue-backed backpressure model. The
+ * `IExecutionStrategy` polymorphism means the application code does
+ * not change — only the `transport` slot in `adapters: { ... }` does.
+ *
+ * ## Why a dedicated adapter (and not a built-in default)?
+ *
+ * The new factory-pattern API takes `adapters: { persistence,
+ * transport }` and both slots are *required* (see
+ * `BatchAdaptersConfig`). Shipping the in-process transport as a
+ * dedicated `BatchAdapter` rather than a hidden implicit default
+ * keeps the `AppModule` wiring explicit at the call site — you can
+ * read the host's `imports` array and see exactly which transport is
+ * active. That pays off the first time you debug a "why is this
+ * running inline?" question and need to grep for the transport.
+ *
+ * ## Wiring
+ *
+ * ```ts
+ * import { Module } from '@nestjs/common';
+ * import { NestBatchModule, InProcessAdapter } from '@nest-batch/core';
+ * import { MikroOrmAdapter } from '@nest-batch/mikro-orm';
+ *
+ * @Module({
+ *   imports: [
+ *     NestBatchModule.forRoot({
+ *       adapters: {
+ *         persistence: MikroOrmAdapter,
+ *         transport: InProcessAdapter,
+ *       },
+ *     }),
+ *   ],
+ * })
+ * class AppModule {}
+ * ```
+ *
+ * `InProcessAdapter.forRoot()` takes no options — the in-process
+ * transport has no connection params, no credentials, no knobs to
+ * tune. If you find yourself reaching for a `useFactory` to plumb
+ * some "config" into it, you almost certainly want a real transport
+ * adapter instead.
+ *
+ * ## DI scope
+ *
+ * The module is `global: true` and exports both the strategy class
+ * and the `EXECUTION_STRATEGY` token. Three reasons for the `global`
+ * flag:
+ *
+ *   1. `JobLauncher` (registered by `NestBatchModule`) is `@Inject(
+ *      EXECUTION_STRATEGY )` — it needs the token visible at the
+ *      application level, not just inside the adapter's own module.
+ *   2. The host application is the only place that may want to
+ *      inspect the strategy at runtime (e.g. for a `/healthz`
+ *      endpoint reporting which transport is active). The `global`
+ *      flag makes that work without forcing the host to re-import
+ *      this module from every sub-module.
+ *   3. Mirroring `NestBatchModule`'s own `global: true` keeps the
+ *      pattern uniform across the engine and its adapters — the host
+ *      author only needs to learn one module-visibility model.
+ *
+ * ## Why `globalProviders` is omitted
+ *
+ * The `BatchAdapter` interface allows a `globalProviders` field for
+ * runtime classes (e.g. `JobExecutor`, `InProcessExecutionStrategy`)
+ * that the adapter's *own* module needs to inject but that the host
+ * should also be able to inject. The recommended path is to list
+ * them in the adapter's own `DynamicModule.exports` — which is what
+ * this adapter does. `JobLauncher` (registered by `NestBatchModule`,
+ * not by this adapter) injects the strategy by the `EXECUTION_STRATEGY`
+ * token, which is exported here, so the runtime resolution chain
+ * works without the core module having to know which adapter is
+ * active.
+ *
+ * If a future in-process feature needs to expose a new provider to
+ * the host (e.g. an inline scheduler), prefer adding it to
+ * `exports` and updating the `BatchAdapter.globalProviders` decision
+ * — do not push it onto the host app's `providers` array.
+ *
+ * ## Concurrency
+ *
+ * The default in-process strategy runs jobs on the caller's event
+ * loop. A long-running step will block the launching process. This
+ * is the contract: no concurrency, no parallelism, no out-of-band
+ * execution. If you need concurrency, switch transports.
+ */
+export declare class InProcessAdapter {
+    /**
+     * Build the `BatchAdapter` value the new factory-pattern
+     * `NestBatchModule.forRoot({ adapters: { transport, ... } })`
+     * expects.
+     *
+     * No options are accepted on purpose — the in-process transport
+     * has nothing to configure. The method is static so the adapter
+     * can be referenced as a value (`adapters: { transport:
+     * InProcessAdapter }`) without needing an instance, mirroring
+     * the shape of the sibling adapter packages' own factories.
+     *
+     * @returns A `BatchAdapter` whose `module` is a `global: true`
+     *   `DynamicModule` exposing `InProcessExecutionStrategy` and the
+     *   `EXECUTION_STRATEGY` token to the host application.
+     */
+    static forRoot(): BatchAdapter;
+}
+//# sourceMappingURL=in-process.adapter.d.ts.map

package/dist/src/adapters/in-process.adapter.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"in-process.adapter.d.ts","sourceRoot":"","sources":["../../../src/adapters/in-process.adapter.ts"],"names":[],"mappings":"AAEA,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,mBAAmB,CAAC;AAOtD;;;;;;;;;GASG;AACH,qBACa,eAAe;CAAG;AAE/B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2GG;AACH,qBAAa,gBAAgB;IAC3B;;;;;;;;;;;;;;OAcG;IACH,MAAM,CAAC,OAAO,IAAI,YAAY;CAU/B"}

package/dist/src/adapters/in-process.adapter.js

@@ -0,0 +1,86 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", {
+    value: true
+});
+function _export(target, all) {
+    for(var name in all)Object.defineProperty(target, name, {
+        enumerable: true,
+        get: Object.getOwnPropertyDescriptor(all, name).get
+    });
+}
+_export(exports, {
+    get InProcessAdapter () {
+        return InProcessAdapter;
+    },
+    get InProcessModule () {
+        return InProcessModule;
+    }
+});
+const _common = require("@nestjs/common");
+const _inprocessexecutionstrategy = require("../execution/in-process-execution-strategy");
+function _ts_decorate(decorators, target, key, desc) {
+    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+    else for(var i = decorators.length - 1; i >= 0; i--)if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+    return c > 3 && r && Object.defineProperty(target, key, r), r;
+}
+let InProcessModule = class InProcessModule {
+};
+InProcessModule = _ts_decorate([
+    (0, _common.Module)({})
+], InProcessModule);
+let InProcessAdapter = class InProcessAdapter {
+    /**
+   * Build the `BatchAdapter` value the new factory-pattern
+   * `NestBatchModule.forRoot({ adapters: { transport, ... } })`
+   * expects.
+   *
+   * No options are accepted on purpose — the in-process transport
+   * has nothing to configure. The method is static so the adapter
+   * can be referenced as a value (`adapters: { transport:
+   * InProcessAdapter }`) without needing an instance, mirroring
+   * the shape of the sibling adapter packages' own factories.
+   *
+   * @returns A `BatchAdapter` whose `module` is a `global: true`
+   *   `DynamicModule` exposing `InProcessExecutionStrategy` and the
+   *   `EXECUTION_STRATEGY` token to the host application.
+   */ static forRoot() {
+        return {
+            name: 'in-process',
+            module: buildInProcessDynamicModule(),
+            globalProviders: [
+                _inprocessexecutionstrategy.InProcessExecutionStrategy,
+                _inprocessexecutionstrategy.IN_PROCESS_EXECUTION_STRATEGY_PROVIDER
+            ]
+        };
+    }
+};
+/**
+ * Build the `DynamicModule` payload for the in-process transport.
+ *
+ * Extracted from `InProcessAdapter.forRoot()` so the provider /
+ * export list lives in one place — easier to read, easier to keep
+ * the two arrays in sync if a new provider is ever added.
+ *
+ * The `EXECUTION_STRATEGY` token is exported (not just listed in
+ * `providers`) so that host code can resolve the strategy directly
+ * via `moduleRef.get(EXECUTION_STRATEGY)` — useful for `/healthz`
+ * endpoints that need to report which transport is wired up.
+ *
+ * `InProcessExecutionStrategy` is also exported so host code can
+ * inject the concrete class (not just the token) when type-strict
+ * consumers prefer the class form.
+ */ function buildInProcessDynamicModule() {
+    return {
+        module: InProcessModule,
+        global: true,
+        providers: [
+            _inprocessexecutionstrategy.IN_PROCESS_EXECUTION_STRATEGY_PROVIDER
+        ],
+        exports: [
+            _inprocessexecutionstrategy.IN_PROCESS_EXECUTION_STRATEGY_PROVIDER
+        ]
+    };
+}
+
+//# sourceMappingURL=in-process.adapter.js.map

package/dist/src/adapters/in-process.adapter.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../../src/adapters/in-process.adapter.ts"],"sourcesContent":["import { Module, type DynamicModule } from '@nestjs/common';\n\nimport type { BatchAdapter } from '../module/adapter';\nimport { EXECUTION_STRATEGY } from '../execution/execution-strategy';\nimport {\n  IN_PROCESS_EXECUTION_STRATEGY_PROVIDER,\n  InProcessExecutionStrategy,\n} from '../execution/in-process-execution-strategy';\n\n/**\n * Empty Nest module class that owns the in-process execution-strategy\n * providers.\n *\n * The class has no body on purpose: it is purely a `DynamicModule`\n * carrier for the `forRoot()` factory below. Nest's module system\n * requires *some* class to identify the module — the empty class is\n * the minimum possible surface and keeps the runtime allocation at\n * one class (no decorators, no lifecycle hooks, no metadata).\n */\n@Module({})\nexport class InProcessModule {}\n\n/**\n * `InProcessAdapter` — the default transport adapter for\n * `@nest-batch/core`.\n *\n * This is the **no-Redis** transport: jobs run synchronously inside\n * the launching process via `JobExecutor.execute(...)`, on the same\n * event loop that called `JobLauncher.launch(...)`. There is no\n * queue, no worker, no Redis connection, no AOF / Lua scripts /\n * stream events. The whole point of this adapter is to be the\n * \"no transport runtime at all\" option.\n *\n * Use it when:\n *\n *   - You do not need horizontal scale-out (one process, one\n *     launcher, jobs run inline).\n *   - You want the cheapest possible deployment — no extra\n *     infrastructure, no extra process to supervise.\n *   - You are building a library / dev-time harness and the queue\n *     runtime would be in the way.\n *   - You are migrating an existing batch app and want to validate\n *     the engine end-to-end before turning on a real transport.\n *\n * Switch to `@nest-batch/bullmq` (or a future transport) when you\n * need cross-process work distribution, technical retry at the\n * transport layer, or a queue-backed backpressure model. The\n * `IExecutionStrategy` polymorphism means the application code does\n * not change — only the `transport` slot in `adapters: { ... }` does.\n *\n * ## Why a dedicated adapter (and not a built-in default)?\n *\n * The new factory-pattern API takes `adapters: { persistence,\n * transport }` and both slots are *required* (see\n * `BatchAdaptersConfig`). Shipping the in-process transport as a\n * dedicated `BatchAdapter` rather than a hidden implicit default\n * keeps the `AppModule` wiring explicit at the call site — you can\n * read the host's `imports` array and see exactly which transport is\n * active. That pays off the first time you debug a \"why is this\n * running inline?\" question and need to grep for the transport.\n *\n * ## Wiring\n *\n * ```ts\n * import { Module } from '@nestjs/common';\n * import { NestBatchModule, InProcessAdapter } from '@nest-batch/core';\n * import { MikroOrmAdapter } from '@nest-batch/mikro-orm';\n *\n * @Module({\n *   imports: [\n *     NestBatchModule.forRoot({\n *       adapters: {\n *         persistence: MikroOrmAdapter,\n *         transport: InProcessAdapter,\n *       },\n *     }),\n *   ],\n * })\n * class AppModule {}\n * ```\n *\n * `InProcessAdapter.forRoot()` takes no options — the in-process\n * transport has no connection params, no credentials, no knobs to\n * tune. If you find yourself reaching for a `useFactory` to plumb\n * some \"config\" into it, you almost certainly want a real transport\n * adapter instead.\n *\n * ## DI scope\n *\n * The module is `global: true` and exports both the strategy class\n * and the `EXECUTION_STRATEGY` token. Three reasons for the `global`\n * flag:\n *\n *   1. `JobLauncher` (registered by `NestBatchModule`) is `@Inject(\n *      EXECUTION_STRATEGY )` — it needs the token visible at the\n *      application level, not just inside the adapter's own module.\n *   2. The host application is the only place that may want to\n *      inspect the strategy at runtime (e.g. for a `/healthz`\n *      endpoint reporting which transport is active). The `global`\n *      flag makes that work without forcing the host to re-import\n *      this module from every sub-module.\n *   3. Mirroring `NestBatchModule`'s own `global: true` keeps the\n *      pattern uniform across the engine and its adapters — the host\n *      author only needs to learn one module-visibility model.\n *\n * ## Why `globalProviders` is omitted\n *\n * The `BatchAdapter` interface allows a `globalProviders` field for\n * runtime classes (e.g. `JobExecutor`, `InProcessExecutionStrategy`)\n * that the adapter's *own* module needs to inject but that the host\n * should also be able to inject. The recommended path is to list\n * them in the adapter's own `DynamicModule.exports` — which is what\n * this adapter does. `JobLauncher` (registered by `NestBatchModule`,\n * not by this adapter) injects the strategy by the `EXECUTION_STRATEGY`\n * token, which is exported here, so the runtime resolution chain\n * works without the core module having to know which adapter is\n * active.\n *\n * If a future in-process feature needs to expose a new provider to\n * the host (e.g. an inline scheduler), prefer adding it to\n * `exports` and updating the `BatchAdapter.globalProviders` decision\n * — do not push it onto the host app's `providers` array.\n *\n * ## Concurrency\n *\n * The default in-process strategy runs jobs on the caller's event\n * loop. A long-running step will block the launching process. This\n * is the contract: no concurrency, no parallelism, no out-of-band\n * execution. If you need concurrency, switch transports.\n */\nexport class InProcessAdapter {\n  /**\n   * Build the `BatchAdapter` value the new factory-pattern\n   * `NestBatchModule.forRoot({ adapters: { transport, ... } })`\n   * expects.\n   *\n   * No options are accepted on purpose — the in-process transport\n   * has nothing to configure. The method is static so the adapter\n   * can be referenced as a value (`adapters: { transport:\n   * InProcessAdapter }`) without needing an instance, mirroring\n   * the shape of the sibling adapter packages' own factories.\n   *\n   * @returns A `BatchAdapter` whose `module` is a `global: true`\n   *   `DynamicModule` exposing `InProcessExecutionStrategy` and the\n   *   `EXECUTION_STRATEGY` token to the host application.\n   */\n  static forRoot(): BatchAdapter {\n    return {\n      name: 'in-process',\n      module: buildInProcessDynamicModule(),\n      globalProviders: [\n        InProcessExecutionStrategy,\n        IN_PROCESS_EXECUTION_STRATEGY_PROVIDER,\n      ],\n    };\n  }\n}\n\n/**\n * Build the `DynamicModule` payload for the in-process transport.\n *\n * Extracted from `InProcessAdapter.forRoot()` so the provider /\n * export list lives in one place — easier to read, easier to keep\n * the two arrays in sync if a new provider is ever added.\n *\n * The `EXECUTION_STRATEGY` token is exported (not just listed in\n * `providers`) so that host code can resolve the strategy directly\n * via `moduleRef.get(EXECUTION_STRATEGY)` — useful for `/healthz`\n * endpoints that need to report which transport is wired up.\n *\n * `InProcessExecutionStrategy` is also exported so host code can\n * inject the concrete class (not just the token) when type-strict\n * consumers prefer the class form.\n */\nfunction buildInProcessDynamicModule(): DynamicModule {\n  return {\n    module: InProcessModule,\n    global: true,\n    providers: [IN_PROCESS_EXECUTION_STRATEGY_PROVIDER],\n    exports: [IN_PROCESS_EXECUTION_STRATEGY_PROVIDER],\n  };\n}\n"],"names":["InProcessAdapter","InProcessModule","forRoot","name","module","buildInProcessDynamicModule","globalProviders","InProcessExecutionStrategy","IN_PROCESS_EXECUTION_STRATEGY_PROVIDER","global","providers","exports"],"mappings":";;;;;;;;;;;QAkIaA;eAAAA;;QA9GAC;eAAAA;;;wBApB8B;4CAOpC;;;;;;;AAaA,IAAA,AAAMA,kBAAN,MAAMA;AAAiB;;;;AA8GvB,IAAA,AAAMD,mBAAN,MAAMA;IACX;;;;;;;;;;;;;;GAcC,GACD,OAAOE,UAAwB;QAC7B,OAAO;YACLC,MAAM;YACNC,QAAQC;YACRC,iBAAiB;gBACfC,sDAA0B;gBAC1BC,kEAAsC;aACvC;QACH;IACF;AACF;AAEA;;;;;;;;;;;;;;;CAeC,GACD,SAASH;IACP,OAAO;QACLD,QAAQH;QACRQ,QAAQ;QACRC,WAAW;YAACF,kEAAsC;SAAC;QACnDG,SAAS;YAACH,kEAAsC;SAAC;IACnD;AACF"}

package/dist/src/adapters/index.d.ts

@@ -0,0 +1,18 @@
+/**
+ * Public surface for the `adapters/` package directory.
+ *
+ * Re-exports the in-process transport adapter so consumers can
+ * import it via `@nest-batch/core` (the root barrel pulls this file
+ * in) without having to know the internal directory layout.
+ *
+ * Future sibling adapters that *live inside* core (none are planned
+ * at the moment) would be re-exported from here too. The persistence
+ * and remote-transport adapters live in their own sibling packages
+ * (`@nest-batch/mikro-orm`, `@nest-batch/typeorm`, `@nest-batch/bullmq`,
+ * ...) — those are not re-exported from this barrel because the
+ * whole point of splitting the engine into sibling packages is to
+ * keep the dependency graph one-way (core never depends on an
+ * adapter package).
+ */
+export * from './in-process.adapter';
+//# sourceMappingURL=index.d.ts.map

package/dist/src/adapters/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../src/adapters/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AACH,cAAc,sBAAsB,CAAC"}