Release 0.6.2

0.6.2 - Fix skCondition type narrowing when combined with filter

Bug Fix

skCondition now correctly intersects with filter-based type narrowing instead of being overridden by it.

Before (broken)

const vendorInsights = await Vendor.query(vendorId, {
  skCondition: { $beginsWith: 'Insight' },
  filter: { status: 'active' },
});
// Result type: (EntityAttributesInstance<Insight> | EntityAttributesInstance<VendorProfile>)[]
// ❌ VendorProfile included because it also has a `status` attribute

After (fixed)

const vendorInsights = await Vendor.query(vendorId, {
  skCondition: { $beginsWith: 'Insight' },
  filter: { status: 'active' },
});
// Result type: EntityAttributesInstance<Insight>[]
// ✅ skCondition constrains the result to Insight only

What changed

skCondition is a DynamoDB key condition that physically limits which items are scanned, unlike filter expressions which are applied post-scan. Previously, skCondition was only used for return type narrowing as a fallback — when no filter-based narrowing applied. Now it is intersected with all other narrowing signals (top-level type, filter keys, and $or blocks) at every level of the type inference chain.

When skCondition and filter narrowing are disjoint (e.g., SK targets Order but filter type targets PaymentMethod), the return type correctly resolves to never[], reflecting that no DynamoDB record can satisfy both conditions.

Types modified

• Added IntersectWithSK and StrictIntersectWithSK utility types
• Updated IntersectKeysWithOr, IntersectTypeWithOr, and FallbackToOrBlocks to thread SK through and intersect at each level