You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
finding(components): a deprecated type's migration guidance is now stated twice — the console notice literal and deprecated.replacement — with nothing asserting they agree #6823
Found while implementing #6674 (the machine-readable deprecation declaration). Filed unassigned, recording only — not graded, no type. domain:* and grading are triage's to produce.
Measured on objectui branch claude/issue-6674-registry-deprecation-declaration @ eb852a052.
The fact
After #6674, the migration guidance for a deprecated component type is stated in two places that must agree and that nothing holds together:
the human-facing console notice — DIV_DEPRECATION_NOTICE / SPAN_DEPRECATION_NOTICE, string literals in packages/components/src/renderers/basic/{div,span}.tsx, and
Both say the same thing today, in different words, because the second was transcribed from the first by hand. Nothing asserts they still agree, so a reword of either leaves the other stale — and the stale one is the copy an automated gate reads and repeats to authors.
This is the shape #4580 ruled about for a type and #6067 / #5671 / #5893 executed three times since: a structural copy would reproduce the defect the moment either side moved. The unit here is a sentence rather than a type, but the failure mode is identical, and unlike those it fails silently — there is no tsc to notice.
Deliberately out of scope there, and the reason is a real cost, not a shrug: the notice text is pinned byte-for-byte by four existing tests —
packages/components/src/__tests__/div-deprecation-provenance.test.tsx (asserts "card", "flex", or semantic layout components and "container", "stack", or "grid" verbatim)
Those pins are correct and deliberate (#4000 records that the guidance is "byte-for-byte what it was"). Converging the two statements means moving them, which is its own judged change and does not belong on a card whose scope was the declaration.
Suggested disposition (not a decision)
Two shapes, both bounded, listed cheapest first:
Assert the agreement. One case per renderer: the notice contains the tokens deprecated.replacement names. Keeps both texts, catches the drift, costs no churn to the existing pins.
Derive the notice's guidance line from the declaration. One statement, the direction the rulings above all took. Costs a rewrite of the four pins, and the notice's two-bullet layout would have to survive the rewrite or be deliberately dropped.
⚠️ Not proposed here: touching the scope sentence in either notice. surfaces and the isHtmlTierNode exemption are already pinned to each other by #6674, so that half is covered.
Found while implementing #6674 (the machine-readable deprecation declaration). Filed unassigned, recording only — not graded, no type.
domain:*and grading are triage's to produce.Measured on
objectuibranchclaude/issue-6674-registry-deprecation-declaration@eb852a052.The fact
After #6674, the migration guidance for a deprecated component type is stated in two places that must agree and that nothing holds together:
DIV_DEPRECATION_NOTICE/SPAN_DEPRECATION_NOTICE, string literals inpackages/components/src/renderers/basic/{div,span}.tsx, anddeprecated.replacementon the same file's registration, which finding(registry): component deprecation is not declared anywhere machine-readable — the only statements of it are a console.warn literal and a human label, so no gate can ask "is this type deprecated?" #6674 added so a gate can tell an author what to write instead.Both say the same thing today, in different words, because the second was transcribed from the first by hand. Nothing asserts they still agree, so a reword of either leaves the other stale — and the stale one is the copy an automated gate reads and repeats to authors.
This is the shape #4580 ruled about for a type and #6067 / #5671 / #5893 executed three times since: a structural copy would reproduce the defect the moment either side moved. The unit here is a sentence rather than a type, but the failure mode is identical, and unlike those it fails silently — there is no
tscto notice.Why #6674 did not fix it
Deliberately out of scope there, and the reason is a real cost, not a shrug: the notice text is pinned byte-for-byte by four existing tests —
packages/components/src/__tests__/div-deprecation-provenance.test.tsx(asserts"card", "flex", or semantic layout componentsand"container", "stack", or "grid"verbatim)packages/components/src/__tests__/div-deprecation-warn-once.test.tsxpackages/components/src/__tests__/span-deprecation-provenance.test.tsxpackages/components/src/__tests__/span-deprecation-warn-once.test.tsxThose pins are correct and deliberate (#4000 records that the guidance is "byte-for-byte what it was"). Converging the two statements means moving them, which is its own judged change and does not belong on a card whose scope was the declaration.
Suggested disposition (not a decision)
Two shapes, both bounded, listed cheapest first:
deprecated.replacementnames. Keeps both texts, catches the drift, costs no churn to the existing pins.surfacesand theisHtmlTierNodeexemption are already pinned to each other by #6674, so that half is covered.Related
deprecated.replacement, i.e. created the second statementdiv的废弃警告会对kind: 'html'tier 自己解析出的节点开火 —— 作者无法消除,且意味着div结构上退不掉 #4000 — the ruling the notices' wording and scope come from@object-ui/core'sRegistry.tsis a THIRDComponentMetadeclaration, and it is missingtags/descriptiontoo — the same delta #5893 just closed inpackages/types#6067 — the "structural copy drifts the moment either side moves" ruling and one of its executionsGenerated by Claude Code