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:
- Module authors see and can accidentally depend on internal types that have no stable contract
- 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.
Problem
dispatchkitcurrently 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: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 APIActionContext,ActionResult— what every handler is written againstModuleAction,DispatchModule— for type annotationsHttpTransport,HttpResponse,HttpMethod,HttpRequestOptions— thectx.httpsurfaceResolvedAction— returned byctx.resolve(), valid handler patternJobStep,RuntimeContext— needed to understandctx.stepandctx.runtimeWhat should move out (CLI internals currently leaking)
RunArtifactsclassModule 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
RunArtifactsclass inActionContextwith a lean interface:The full
RunArtifactsimplementation stays inside dispatch, never exported from dispatchkit.HttpPoolRegistryandHttpPoolOptionsDispatch 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.
HttpTransportOptionsDispatch constructs
HttpTransportfrom 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,ModuleJobKindThese 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.
ActionHandlerA 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
dispatchkitexport surface after this changeMigration impact
ActionContext.artifactstype changes fromRunArtifactstoArtifactsappendActivityneed zero changesartifacts.runIdwas depending on undocumented internals — this is a breaking change but justifiedVersion bump
This is a breaking change to the public type surface. Ship as a minor version bump (
0.1.0) to signal intentional cleanup.