From a DX review of the constraints this repo holds deliberately.
Thesis #1 is not what needs revisiting — the missing tool is. "One process, one runtime" deletes a whole class of design problem (no shared drain deadline, no question of whose failure takes the process down) and matches how Kubernetes wants to scale things. Keep it.
What it costs is the local loop. An application with an API, a consumer and a worker is three deployments, and today that means three terminals and three commands. nest start --watch and ace serve --watch are one.
The kernel was designed for this and the tool was never built. Thesis #4 says so in as many words:
This is what makes the kernel embeddable: a dev runner booting two applications side by side, or a test file booting a dozen.
Every primitive it needs already exists and is already exercised:
start returns a RunningApp and never calls process.exit — the reason given for that is exactly embeddability.@btravstack/testing's bootFixture already boots several apps in one process and stops each on every exit path; the test suites are a dev runner in miniature.runMain is the boundary that turns one app into a process exit code, so anything that does not use it stays composable.
The design questions worth settling in the issue rather than in code: what happens when one app fails to start (does the runner exit, or keep the others up and report?); whether SIGINT drains all of them concurrently or in sequence; whether the probe server can be shared or must be disabled for all but one; and how env differences between apps are expressed without a config file format nobody asked for.
A caution. The value of thesis #1 is that a deployment is one runtime. A dev runner must not become a supported production shape by accident — otherwise it re-introduces the shared-deadline question through the back door. Whatever ships should say plainly that it is a development tool.
Acceptance
- One command boots an application's several deployments in one process, with interleaved, per-app-labelled output.
- A failure in one app is visible and does not silently take down the others without saying so.
- SIGINT drains every app through the kernel's normal three beats — not
process.exit.
- The tool documents that it is for development, and that a production deployment is still one runtime per process.
From a DX review of the constraints this repo holds deliberately.
Thesis #1 is not what needs revisiting — the missing tool is. "One process, one runtime" deletes a whole class of design problem (no shared drain deadline, no question of whose failure takes the process down) and matches how Kubernetes wants to scale things. Keep it.
What it costs is the local loop. An application with an API, a consumer and a worker is three deployments, and today that means three terminals and three commands.
nest start --watchandace serve --watchare one.The kernel was designed for this and the tool was never built. Thesis #4 says so in as many words:
Every primitive it needs already exists and is already exercised:
startreturns aRunningAppand never callsprocess.exit— the reason given for that is exactly embeddability.@btravstack/testing'sbootFixturealready boots several apps in one process and stops each on every exit path; the test suites are a dev runner in miniature.runMainis the boundary that turns one app into a process exit code, so anything that does not use it stays composable.The design questions worth settling in the issue rather than in code: what happens when one app fails to start (does the runner exit, or keep the others up and report?); whether SIGINT drains all of them concurrently or in sequence; whether the probe server can be shared or must be disabled for all but one; and how
envdifferences between apps are expressed without a config file format nobody asked for.A caution. The value of thesis #1 is that a deployment is one runtime. A dev runner must not become a supported production shape by accident — otherwise it re-introduces the shared-deadline question through the back door. Whatever ships should say plainly that it is a development tool.
Acceptance
process.exit.