Closed as not planned. The register stays a per-file allow-list. Same reasoning as #87: this would be new machinery built for a metric rather than for a failure anyone has had.
What this proposed
Replacing KNOWN_NOISY_SPECS' per-file boolean with per-file message budgets, failing on stale entries, and reporting totals in CI — so a partial cleanup would show up as progress instead of nothing.
Why not
The premise held: the register really is all-or-nothing, and #512 halved the noise while removing one entry from 38. But #516 then did the work this issue was really about, and the register moved on its own:
|
entries |
tests logging |
messages |
| before #512 |
38 |
62 |
623 |
| after #512 |
37 |
56 |
366 |
| after #516 |
25 |
44 |
569 |
Twelve files went quiet, including the entire dialog family on the nuxt side. That came from attaching the hand-written mounts (#513), not from re-shaping the gate. The message count moved the other way because DropdownMenu and ContextMenu now really mount their menu content, so reka-ui's third-party textValue warning fires per item rather than per test — those two files stay registered either way, so nothing new gets through.
What is left in the register is 25 entries in four groups, each with a named cause: reka-ui's textValue and Presence (third-party), three composables calling lifecycle hooks outside setup() (ours, real), and twelve vue-project files whose fixtures navigate to routes the plain-Vue test router does not declare (fixture work). None of those needs a budget to be understood — they need the underlying thing fixed, and then the line deleted.
So the instrument was never what was holding the number up. Building a budget system now would add a mechanism whose only job is to display progress on work that is already visible in a one-line diff.
The one part with independent merit — failing on a stale entry, the way test/utils/indistinguishable-snapshots.spec.ts does for its own baseline — is not worth a change on its own: a register entry that has gone quiet costs nothing until someone re-measures, and re-measuring is a five-minute run whenever it matters (empty the set, run the suite, sum the logged N console message(s) lines).
If this comes back, the numbers above are the starting point. The trigger would be the register growing again rather than shrinking, or a real warning slipping through because a file was exempt for an unrelated reason.
Closed as not planned. The register stays a per-file allow-list. Same reasoning as #87: this would be new machinery built for a metric rather than for a failure anyone has had.
What this proposed
Replacing
KNOWN_NOISY_SPECS' per-file boolean with per-file message budgets, failing on stale entries, and reporting totals in CI — so a partial cleanup would show up as progress instead of nothing.Why not
The premise held: the register really is all-or-nothing, and #512 halved the noise while removing one entry from 38. But #516 then did the work this issue was really about, and the register moved on its own:
Twelve files went quiet, including the entire dialog family on the
nuxtside. That came from attaching the hand-written mounts (#513), not from re-shaping the gate. The message count moved the other way becauseDropdownMenuandContextMenunow really mount their menu content, so reka-ui's third-partytextValuewarning fires per item rather than per test — those two files stay registered either way, so nothing new gets through.What is left in the register is 25 entries in four groups, each with a named cause: reka-ui's
textValueandPresence(third-party), three composables calling lifecycle hooks outsidesetup()(ours, real), and twelvevue-project files whose fixtures navigate to routes the plain-Vue test router does not declare (fixture work). None of those needs a budget to be understood — they need the underlying thing fixed, and then the line deleted.So the instrument was never what was holding the number up. Building a budget system now would add a mechanism whose only job is to display progress on work that is already visible in a one-line diff.
The one part with independent merit — failing on a stale entry, the way
test/utils/indistinguishable-snapshots.spec.tsdoes for its own baseline — is not worth a change on its own: a register entry that has gone quiet costs nothing until someone re-measures, and re-measuring is a five-minute run whenever it matters (empty the set, run the suite, sum thelogged N console message(s)lines).If this comes back, the numbers above are the starting point. The trigger would be the register growing again rather than shrinking, or a real warning slipping through because a file was exempt for an unrelated reason.