The author-time warning printer in @objectstack/cli 17.1.0 emits a fixed 50 detailed entries and then stops. The summary line still counts every warning, so the two numbers disagree — and nothing in the output says the list was cut. A repo past 50 warnings therefore carries diagnostics that are counted but never shown, and an author who reads the output and sees their file is clean has read a truncated list.
Measured
Two objectstack build runs on objectstack-ai/hotcrm, before and after a five-warning fix (hotcrm#1248), same tree otherwise:
run detailed entries printed summary line
before 50 ⚠ 80 author-time warning(s) — see above
after 50 ⚠ 75 author-time warning(s) — see above
Both runs produced output of exactly 184 lines and exactly 52 ⚠ lines. Removing five warnings did not shorten the printed list — it made room, and five warnings that had never been printed before appeared in the second run:
⚠ view "views[12]" · form: … absolute colSpan 2 …
rule: absolute-colspan-discouraged
ℹ flow "opportunity_approval_on_create" · node "manager_review": …
approval-approvers-may-resolve-empty (×4)
Those five were present in the tree on both runs. They were simply past the cut on the first one. objectstack validate prints the same truncated set.
Why it matters
The truncation is silent — there is no …and 30 more line — so the output is not merely incomplete, it is indistinguishable from complete. Three consequences, in order of cost:
- A defect below the cut has no symptom at all. The one that prompted this issue was found by reading the props schema, not by reading the build output.
- The visible set is ordered by surface (pages, then views, then flows), so an entire surface can sit permanently below the cut on a repo whose page warnings alone exceed 50. On hotcrm today, every
view and flow warning was invisible until a page warning was fixed. - Fixing warnings makes new ones appear, which reads as a regression introduced by the fix.
Neither the exit code nor the artifact is affected: both runs exit 0 and write dist/objectstack.json, as designed for advisory rules.
What would resolve it
Anything that keeps the printed set honest about its own truncation, in rough order of preference:
- print all of them (the count is already known — the summary computes it);
- keep a cap and print
…and N more author-time warning(s) — rerun with --all naming the exact remainder; - keep a cap but make it per-surface, so no surface can be starved by another.
A silent cap is the one behaviour that should not survive, whatever the limit ends up being.
Found while fixing hotcrm#1248 (three record:related_list filters authored in shapes the component drops). Not fixed there: that repo consumes the CLI, it does not ship it.
The author-time warning printer in
@objectstack/cli17.1.0 emits a fixed 50 detailed entries and then stops. The summary line still counts every warning, so the two numbers disagree — and nothing in the output says the list was cut. A repo past 50 warnings therefore carries diagnostics that are counted but never shown, and an author who reads the output and sees their file is clean has read a truncated list.Measured
Two
objectstack buildruns onobjectstack-ai/hotcrm, before and after a five-warning fix (hotcrm#1248), same tree otherwise:Both runs produced output of exactly 184 lines and exactly 52
⚠lines. Removing five warnings did not shorten the printed list — it made room, and five warnings that had never been printed before appeared in the second run:Those five were present in the tree on both runs. They were simply past the cut on the first one.
objectstack validateprints the same truncated set.Why it matters
The truncation is silent — there is no
…and 30 moreline — so the output is not merely incomplete, it is indistinguishable from complete. Three consequences, in order of cost:viewandflowwarning was invisible until a page warning was fixed.Neither the exit code nor the artifact is affected: both runs exit 0 and write
dist/objectstack.json, as designed for advisory rules.What would resolve it
Anything that keeps the printed set honest about its own truncation, in rough order of preference:
…and N more author-time warning(s) — rerun with --allnaming the exact remainder;A silent cap is the one behaviour that should not survive, whatever the limit ends up being.
Found while fixing hotcrm#1248 (three
record:related_listfilters authored in shapes the component drops). Not fixed there: that repo consumes the CLI, it does not ship it.