Found while implementing #613 (forecast seed identity). Filed unassigned, not fixed there — out of that issue's scope.
The problem
scripts/check-source-hygiene.mjs enforces MAX_FILE_BYTES = 100 * 1024 (102400) with the message "split the file — oversized modules defeat review". pnpm hygiene is part of pnpm verify, so this is a hard gate.
On origin/main (0f72853) src/data/index.ts is 99,656 bytes — 2,744 bytes of headroom, i.e. the file is at 97.3% of the cap.
#613 added ~3.1KB of seed records plus an explanatory comment and pushed the file to 102,782 bytes, failing the gate:
✗ no source file over 100KB — 1 violation(s)
src/data/index.ts:0 100KB
→ split the file — oversized modules defeat review
I got under the cap by relocating most of the rationale comment onto the field declaration in src/objects/forecast.object.ts, which is arguably where it belonged anyway. That leaves the file at 100,858 bytes — 1,542 bytes of headroom.
Why it matters
That is roughly one seed record of headroom. The next person to add a demo account, a knowledge article, or a few opportunity lines trips a failure whose message ("split the file") describes a refactor far larger than the change that triggered it — and the natural way out under time pressure is to delete explanatory comments from a 2,200-line fixture file, which is the opposite of what the cap is for.
It is also a bad interaction with the file's own nature: src/data/index.ts is a fixtures file. Its growth is expected and roughly linear in demo coverage, so it will keep re-approaching any fixed byte cap.
Suggested direction
Roughly in order of preference:
- Split
src/data/index.ts by object family, keeping CrmSeedData as the aggregating export — e.g. src/data/sales.seed.ts (accounts / contacts / leads / opportunities / line items), src/data/service.seed.ts (cases / knowledge), src/data/marketing.seed.ts (campaigns / members), src/data/revenue.seed.ts (quotes / contracts / forecasts), with src/data/index.ts reduced to imports plus the exported array. This is what the hygiene message actually asks for, and it makes the seed file reviewable per domain. Note the shared helpers (celDaysAgo, the forecast* date math, closedPeriod, lineItemRecords, the product catalogue) would need a src/data/_shared.ts.
- Exempt fixture files from the byte cap (an allowlist in
check-source-hygiene.mjs), on the argument that the cap targets logic modules and a flat data file is legitimately long. Cheaper, but it removes the pressure that keeps the file from becoming unreviewable, and the rule's own wording says the concern is review.
- Raise
MAX_FILE_BYTES. Least preferred — it just moves the wall and silently weakens the cap for every other file.
Option 1 is a mechanical but wide diff that touches a file several in-flight PRs edit, so it wants to land on a quiet day rather than riding along with a feature change.
Found while implementing #613 (forecast seed identity). Filed unassigned, not fixed there — out of that issue's scope.
The problem
scripts/check-source-hygiene.mjsenforcesMAX_FILE_BYTES = 100 * 1024(102400) with the message "split the file — oversized modules defeat review".pnpm hygieneis part ofpnpm verify, so this is a hard gate.On
origin/main(0f72853)src/data/index.tsis 99,656 bytes — 2,744 bytes of headroom, i.e. the file is at 97.3% of the cap.#613 added ~3.1KB of seed records plus an explanatory comment and pushed the file to 102,782 bytes, failing the gate:
I got under the cap by relocating most of the rationale comment onto the field declaration in
src/objects/forecast.object.ts, which is arguably where it belonged anyway. That leaves the file at 100,858 bytes — 1,542 bytes of headroom.Why it matters
That is roughly one seed record of headroom. The next person to add a demo account, a knowledge article, or a few opportunity lines trips a failure whose message ("split the file") describes a refactor far larger than the change that triggered it — and the natural way out under time pressure is to delete explanatory comments from a 2,200-line fixture file, which is the opposite of what the cap is for.
It is also a bad interaction with the file's own nature:
src/data/index.tsis a fixtures file. Its growth is expected and roughly linear in demo coverage, so it will keep re-approaching any fixed byte cap.Suggested direction
Roughly in order of preference:
src/data/index.tsby object family, keepingCrmSeedDataas the aggregating export — e.g.src/data/sales.seed.ts(accounts / contacts / leads / opportunities / line items),src/data/service.seed.ts(cases / knowledge),src/data/marketing.seed.ts(campaigns / members),src/data/revenue.seed.ts(quotes / contracts / forecasts), withsrc/data/index.tsreduced to imports plus the exported array. This is what the hygiene message actually asks for, and it makes the seed file reviewable per domain. Note the shared helpers (celDaysAgo, theforecast*date math,closedPeriod,lineItemRecords, the product catalogue) would need asrc/data/_shared.ts.check-source-hygiene.mjs), on the argument that the cap targets logic modules and a flat data file is legitimately long. Cheaper, but it removes the pressure that keeps the file from becoming unreviewable, and the rule's own wording says the concern is review.MAX_FILE_BYTES. Least preferred — it just moves the wall and silently weakens the cap for every other file.Option 1 is a mechanical but wide diff that touches a file several in-flight PRs edit, so it wants to land on a quiet day rather than riding along with a feature change.