Observation-class finding, filed unassigned for triage. Found while implementing #4919 (retire MobileOverrides); not fixed in PR #5941 — it is a different type and the #4919 ruling does not cover it.
Mechanism
packages/types/src/mobile.ts declares MobileComponentConfig, and it is published twice — packages/types/src/index.ts and packages/mobile/src/index.ts both re-export it, so consumers of @object-ui/types and @object-ui/mobile can both write it.
Measured on main at ed35c23bb, the type has exactly four mentions repo-wide, and not one of them is a mount point or a read:
packages/types/src/index.ts:598 barrel re-export
packages/types/src/mobile.ts:50 a doc-comment cross-reference ({@link MobileComponentConfig})
packages/types/src/mobile.ts:279 the declaration itself
packages/mobile/src/index.ts:69 barrel re-export
Nothing mounts it as a property on any other type, and no renderer, hook or adapter resolves it. It is a free-floating published interface.
Its remaining members are responsive, gestures, pullToRefresh and infiniteScroll (mobileOverrides is removed by PR #5941). Whether those are individually read has not been measured here — this finding is only about the container type having no mount point and no consumer, which makes the question worth asking as one piece of work rather than four.
Relationship to #4919
Same family (the "declared surface with no consumption path" lineage: #3818 / #3829 / #3985 / #4919), different type. #4919's ruling names MobileOverrides, its mobileOverrides? mount point, and its two barrel re-exports — all now handled. MobileComponentConfig is the type that used to host the mount point; it survives PR #5941 minus that one property.
Deliberately filed as a separate card rather than widened into PR #5941: retiring or keeping a whole published container type is a product call of the same kind #4919 needed a maintainer ruling for, and the implementing agent should not pick one on the way past.
Reachability, stated honestly
In-repo victims: 0 — nothing in packages/, apps/ or examples/ authors it, and the objectstack sibling checkout has zero hits. The only people who could be affected today are external consumers reading the .d.ts. Observation-class, so finding and no pm:queue; severity is triage's call, not mine.
Note on the duplicate check
The pre-file search this repo's discipline calls for could not be run — the GitHub search and issue-list endpoints were returning API rate limit already exceeded at filing time. If a card for this already exists, please close this one as a duplicate.
Observation-class finding, filed unassigned for triage. Found while implementing #4919 (retire
MobileOverrides); not fixed in PR #5941 — it is a different type and the #4919 ruling does not cover it.Mechanism
packages/types/src/mobile.tsdeclaresMobileComponentConfig, and it is published twice —packages/types/src/index.tsandpackages/mobile/src/index.tsboth re-export it, so consumers of@object-ui/typesand@object-ui/mobilecan both write it.Measured on
mainated35c23bb, the type has exactly four mentions repo-wide, and not one of them is a mount point or a read:Nothing mounts it as a property on any other type, and no renderer, hook or adapter resolves it. It is a free-floating published interface.
Its remaining members are
responsive,gestures,pullToRefreshandinfiniteScroll(mobileOverridesis removed by PR #5941). Whether those are individually read has not been measured here — this finding is only about the container type having no mount point and no consumer, which makes the question worth asking as one piece of work rather than four.Relationship to #4919
Same family (the "declared surface with no consumption path" lineage: #3818 / #3829 / #3985 / #4919), different type. #4919's ruling names
MobileOverrides, itsmobileOverrides?mount point, and its two barrel re-exports — all now handled.MobileComponentConfigis the type that used to host the mount point; it survives PR #5941 minus that one property.Deliberately filed as a separate card rather than widened into PR #5941: retiring or keeping a whole published container type is a product call of the same kind #4919 needed a maintainer ruling for, and the implementing agent should not pick one on the way past.
Reachability, stated honestly
In-repo victims: 0 — nothing in
packages/,apps/orexamples/authors it, and theobjectstacksibling checkout has zero hits. The only people who could be affected today are external consumers reading the.d.ts. Observation-class, sofindingand nopm:queue; severity is triage's call, not mine.Note on the duplicate check
The pre-file search this repo's discipline calls for could not be run — the GitHub search and issue-list endpoints were returning
API rate limit already exceededat filing time. If a card for this already exists, please close this one as a duplicate.