Proposal / question
The leaf packages under packages/* each keep their entire implementation in a single large src/index.ts:
| package |
src/index.ts LOC |
platform |
~1111 |
download |
~1051 |
sidecar-proto |
~933 |
sidecar |
~800 |
host |
~674 (2-file) |
These are cohesive, well-tested, and low-churn — not god-files — but the single-file shape makes them harder to navigate and review than they need to be. I'd like to split each into a few concern-focused sibling modules with index.ts kept as a pure barrel that re-exports the exact same public surface (byte-identical function bodies; only import-path rewrites). No behavior change, no dependency change, export surface identical before/after.
This is deliberately a lightweight file-split, not the full apps/daemon/src/design-systems capability-barrel machinery — packages/* aren't in the check-barrel-imports guard registry (that guard is daemon-scoped), so this wouldn't touch guard infrastructure.
Why
Maintainability/reviewability of the shared substrate. platform's process/proxy/fs/stamp helpers, for example, are five unrelated concerns in one 1.1k-line file.
What users see
Nothing — internal refactor, public API and runtime behavior unchanged.
Plan
Land platform as a pilot PR first so the shape can be reviewed on one package, then replicate for download / sidecar / sidecar-proto / host if the pilot is accepted.
Before I invest in all five — is this kind of maintainability refactor welcome for these packages, or do you prefer the single-file shape for the leaf substrate? Happy to close if it's unwanted churn.
Proposal / question
The leaf packages under
packages/*each keep their entire implementation in a single largesrc/index.ts:src/index.tsLOCplatformdownloadsidecar-protosidecarhostThese are cohesive, well-tested, and low-churn — not god-files — but the single-file shape makes them harder to navigate and review than they need to be. I'd like to split each into a few concern-focused sibling modules with
index.tskept as a pure barrel that re-exports the exact same public surface (byte-identical function bodies; only import-path rewrites). No behavior change, no dependency change, export surface identical before/after.This is deliberately a lightweight file-split, not the full
apps/daemon/src/design-systemscapability-barrel machinery —packages/*aren't in thecheck-barrel-importsguard registry (that guard is daemon-scoped), so this wouldn't touch guard infrastructure.Why
Maintainability/reviewability of the shared substrate.
platform's process/proxy/fs/stamp helpers, for example, are five unrelated concerns in one 1.1k-line file.What users see
Nothing — internal refactor, public API and runtime behavior unchanged.
Plan
Land
platformas a pilot PR first so the shape can be reviewed on one package, then replicate fordownload/sidecar/sidecar-proto/hostif the pilot is accepted.Before I invest in all five — is this kind of maintainability refactor welcome for these packages, or do you prefer the single-file shape for the leaf substrate? Happy to close if it's unwanted churn.