Skip to content

Clean up dispatchkit public surface: separate SDK types from CLI internals #28

@MehmetSecgin

Description

@MehmetSecgin

Problem

dispatchkit currently exports everything — both the module authoring SDK that external module authors need, and internal CLI plumbing that belongs inside dispatch itself. This creates two problems:

  1. Module authors see and can accidentally depend on internal types that have no stable contract
  2. Any change to CLI internals forces a dispatchkit version bump even when the authoring API is unchanged

What should stay in dispatchkit (module authors need these)

These are the types and functions a module author genuinely codes against:

  • defineModule, defineAction — the authoring API
  • ActionContext, ActionResult — what every handler is written against
  • ModuleAction, DispatchModule — for type annotations
  • HttpTransport, HttpResponse, HttpMethod, HttpRequestOptions — the ctx.http surface
  • ResolvedAction — returned by ctx.resolve(), valid handler pattern
  • JobStep, RuntimeContext — needed to understand ctx.step and ctx.runtime

What should move out (CLI internals currently leaking)

RunArtifacts class

Module authors only ever call ctx.artifacts.appendActivity(line). The rest of the class — runId, runDir, callsDir, nextIndex, requestPath, responsePath, appendCallLog — is runner plumbing.

Fix: replace the exported RunArtifacts class in ActionContext with a lean interface:

interface Artifacts {
  appendActivity(line: string): void;
}

The full RunArtifacts implementation stays inside dispatch, never exported from dispatchkit.

HttpPoolRegistry and HttpPoolOptions

Dispatch constructs and manages connection pools internally. Module authors never instantiate or configure these. Currently exported from dispatchkit and referenced in HttpTransportOptions.

Fix: remove from dispatchkit exports entirely. Keep internally in dispatch.

HttpTransportOptions

Dispatch constructs HttpTransport from job config — module authors never construct it. It's exposed in dispatchkit but has no use in module authoring.

Fix: remove from dispatchkit exports. Keep internally in dispatch.

ModuleDefinition, ModuleLayer, ModuleJobDefinition, ModuleJobKind

These are registry and loader types — what dispatch uses internally after loading modules. Module authors don't need to know what layer they're in or how jobs are discovered at runtime.

Fix: remove from dispatchkit exports. Move to dispatch internals.

ActionHandler

A TypeScript bivariance hack used internally to make handler typing ergonomic. Not part of the public authoring surface.

Fix: keep as an internal type in dispatchkit source if needed, but do not export it.

The clean dispatchkit export surface after this change

// Authoring API
export { defineModule, defineAction }

// Handler contract
export type { ActionContext, ActionResult }

// Module shape
export type { DispatchModule, ModuleAction }

// HTTP surface (ctx.http)
export { HttpTransport }
export type { HttpResponse, HttpMethod, HttpRequestOptions }

// Supporting types for ctx.resolve() and ctx.runtime
export type { ResolvedAction, JobStep, RuntimeContext }

// Artifacts interface (replaces RunArtifacts class)
export type { Artifacts }

Migration impact

  • ActionContext.artifacts type changes from RunArtifacts to Artifacts
  • Module authors who correctly only call appendActivity need zero changes
  • Anyone who accessed internal fields like artifacts.runId was depending on undocumented internals — this is a breaking change but justified

Version bump

This is a breaking change to the public type surface. Ship as a minor version bump (0.1.0) to signal intentional cleanup.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions