Server Package Extraction
Practical reference for a future packages/server split after the opencode
server moved to the Effect HttpApi backend.
Current State
- The server still lives in
packages/opencode. - The runtime and app layer are centralized in
src/effect/app-runtime.tsandsrc/effect/run-service.ts. - The route tree lives under
src/server/routes/instance/httpapiand is hosted fromsrc/server/server.ts. - OpenAPI generation is based on the HttpApi contract plus compatibility
translation in
src/server/routes/instance/httpapi/public.ts. - There is no standalone
packages/serverworkspace yet.
Future State
Target package layout:
packages/core- shared domain services and schemaspackages/server- HTTP contracts, handlers, OpenAPI generation, and an embeddable server APIpackages/cli- TUI and CLI entrypointspackages/sdk- generated from the server OpenAPI specpackages/plugin- plugin authoring surface
Extraction Rule
Do not create a package cycle.
Until enough shared service code lives outside packages/opencode, a future
packages/server should either:
- own pure HttpApi contracts only, or
- accept host-provided services/layers/callbacks from
packages/opencode
It should not import packages/opencode services while packages/opencode
imports it to host routes.
Suggested PR Sequence
- Keep shrinking OpenAPI compatibility shims in
httpapi/public.ts. - Move stable domain schemas into shared packages only when they no longer depend on opencode-local runtime modules.
- Extract pure HttpApi contract modules into
packages/serveronce the contract can compile without importingpackages/opencodeimplementation details. - Extract handler factories after their service dependencies can be supplied by a host layer instead of imported directly.
- Move server hosting last, after package ownership is clear.
Non-Goals
- Do not revive the old dual-backend migration shape.
- Do not split server hosting before service dependencies have a clean package boundary.
- Do not switch SDK generation to a new package until generated output is known to remain compatible.