Repository navigation
chore: two copies of parseDashboardTarget, one of them is load-bearing #101
Description
Found while auditing dashboard references in src/ (350 matches across 11
files). Neither copy is a mistake, and the duplication is the only reason the
TUI build stays small.
The two functions
| Location | Name | Used by |
|---|---|---|
src/dashboard.ts:301-304 |
parseDashboardTarget() |
the dashboard / dashboard.start tools |
src/tui.tsx:381-385 |
parseWebDashboardTarget() |
the TUI's own slash commands |
The comments at both sites explain the reason: src/dashboard.ts:11 inlines
dashboard/index.html into the server bundle via a text import, and having
src/tui.tsx import src/dashboard.ts would drag all 150 KB of that HTML
into dist/tui.js.
Why this needs an issue
The duplication is invisible from the code — nothing names the constraint. The
next person to see parseWebDashboardTarget() and parseDashboardTarget()
doing the same job with the same regex will read it as an oversight and DRY it.
Merging them re-inlines the HTML into the TUI bundle, and the cost lands at
build time, not in any test.
What would make this safe
- a comment at each site naming the other, and saying the split is load-bearing
- a test on the built artifact: assert
dist/tui.jsdoes not contain a
recognizable chunk ofdashboard/index.html. That is the property that
actually matters, and nothing currently asserts it - the two parsers have drifted, which is the usual first symptom. Worth a look
at whether they are still equivalent before assuming they are
Verified present in both files on 2.13.2.
Activity
serkanalgur commentedon Sep 28, 2026
Done in #102, though only the half that was actually open.
The duplication is not something to reconcile.
parseWebDashboardTargetinsrc/tui.tsx:381andparseDashboardTargetinsrc/dashboard.ts:301are two functions becausesrc/dashboard.ts:11inlinesdashboard/index.htmlwith a text import; importing that module from the TUI would put ~170 KB of page markup intodist/tui.js, which serves no dashboard. Both sites already carried a comment naming the other, andtest/dashboard-entrypoints.test.ts:917already pinned the two to agree on every input. That part was done and needed no change.The open half was one level down: nothing held the BUNDLES apart, and the bundle is the only place the constraint is observable. #102 adds three assertions on the built artifacts — the page is inlined into
dist/index.js, none of its markup appears indist/tui.js, and the TUI bundle is smaller than the page itself. 72 KB against 170 KB, where a bundle that had inlined the markup would be about 240 KB.Mutation-checked in all three directions: appending the page to
dist/tui.jsfails both the markup and the size assertion, and removing it fromdist/index.jsfails the server-side one.Also worth recording from the same session: the two functions were last checked for equivalence by a test, but never checked for separation, and a comment is not a test. If the constraint is ever relaxed — say the TUI grows its own renderer and a shared parser becomes worth the bytes — the size assertion is what will fail, and that is the moment to delete both copies rather than the moment to notice the bundle got big.