Skip to content

refactor: split daemon-client.ts into lifecycle / transport / progress / artifacts modules (M2-1) #727

@thymikee

Description

@thymikee

Part of #722 (Milestone 2 — high leverage). Blocked by: #723, #724 (safety-net tests) and #726 (contracts extraction — overlapping import graphs, do not parallelize).

src/daemon-client.ts (1,801 LOC) mixes daemon discovery/spawn/lock-recovery, socket/HTTP transport selection and retries, progress-stream parsing, artifact upload/download, and lease RPC marshaling. Four functions are grandfathered complexity-critical in fallow-baselines/health.json. Maintainer-approved on the condition it improves maintainability and readability.

Approach — one seam per PR, in dependency order

  1. Artifacts (sendHttpRequest, downloadRemoteArtifact, materialization helpers) → daemon-artifacts.ts — most self-contained
  2. Progress streaming → merge with existing daemon-client-progress.ts
  3. Lifecycle (ensureDaemon, startLocalDaemon, lock/info handling, isReusableDaemonInfo) → daemon-lifecycle.ts
  4. Transport selection/retrydaemon-transport.ts

Keep daemon-client.ts as a façade re-exporting the current public surface so cli.ts, MCP, and the fallow entry graph see no change.

Gotchas

  • Module-level state (cached settings, shared in-flight spawn promise) must move intact — spawn dedup relies on a shared promise
  • rslib bundles .d.ts; verify declaration output unchanged
  • Update fallow-baselines/health.json keys (file-keyed) in each PR

Acceptance criteria (after the final PR)

Effort: XL (4 PRs). Risk: medium.

Metadata

Metadata

Assignees

Labels

in-progressWork is actively in progress

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions