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
{{ message }}
Repository navigation
Docs: union sources document a per-source index: key that FindManyUnionSource does not have (TS2353) #385
The pagination docs show a per-source index: { name, range } key inside union() sources. FindManyUnionSource has no such key — it exposes only where. Copying the documented example fails typecheck with TS2353.
www/content/docs/orm/queries/pagination.mdx:139 and :145
packages/kitcn/skills/kitcn/references/features/orm.md:569 and :575
Both render a union source containing an index: block.
Impact
A user following the documented example gets TS2353: Object literal may only specify known properties, and 'index' does not exist in type 'FindManyUnionSource'.
The error is at least loud — the type system rejects it rather than silently ignoring it at runtime — so this is a documentation defect, not a data-correctness hazard.
The two doc surfaces are required to stay in sync (AGENTS.md: docs sync), so both need the same edit.
Suggested fix
Two options, and the choice depends on planned work:
Correct the docs now — remove the index: block from both examples so they describe the shipped API.
Implement the documented shape — add per-source index: { name, range } to FindManyUnionSource and honour it in _buildUnionSourceStream.
Option 2 is separately desirable (union sources currently cannot be index-anchored at all, so each source re-walks the shared index), but it is a larger change. If it is not imminent, do option 1 now rather than leaving the docs wrong.
Copy the example above against a table with a two-field index. It should typecheck — no TS2353.
Run it. Each source reads only its own index range; rows outside both ranges are never read.
Sources may name different indexes, as long as each pins its leading fields with eq so both end up ordered by the interleaveBy fields.
A source with no index still falls back to a chain-level .withIndex(...), so existing where-only unions are unchanged.
One thing worth flagging beyond the report: the other documented union form — a shared .withIndex(...) plus a per-source where — threw at runtime whenever interleaveBy listed fewer fields than the index. Those examples have been corrected too.
Activity
MikeyZhang75 commentedon Aug 21, 2026
Fixed in #394.
Union sources now take a per-source
index, so the documented example works as written:To verify:
eqso both end up ordered by theinterleaveByfields.indexstill falls back to a chain-level.withIndex(...), so existingwhere-only unions are unchanged.One thing worth flagging beyond the report: the other documented union form — a shared
.withIndex(...)plus a per-sourcewhere— threw at runtime wheneverinterleaveBylisted fewer fields than the index. Those examples have been corrected too.fix(orm): let union sources anchor their own index range (udecode#394)