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
Commit 1d825ff
Browse filesBrowse the repository at this point in the historyBrowse files
fix(recipe): accept its own slots in a function generic over the slot recipe it composes
A function generic over the slot recipe that its slot recipe composes,
such as `withFooter<Base extends ComposableKindSlotRecipe<Style>>(base)`,
could not name the recipe's own slots in `base`, the variants, or the
compound variants: the config typed their keys with ComposedSlot, a
conditional type that TypeScript cannot reduce while Base is generic, so
it rejected every slot.
The config now types the slots of the composed recipes apart, as indexed
access, and checks a variant's slots against the recipe's own slots
first. Slot values are one mapped type, which TypeScript relates an
object to while some of its keys are generic; it is the same type as
before. A recipe that composes nothing, or concrete recipes, is checked
as it was.
Making library recipes composable advised ComposedSlot for the keys of
`base` and of compound variants, which gave a library the same bug. It
now advises the slots written out, as the engine types them.
Where I looked: the slot config of createSlotRecipeKind, sva in
class-recipe, createSlotStyleRecipe and the themed one in native-recipe
(each fixed in its own commit), the plain recipe config (not affected:
it has no slots), and the docs and skills (Making library recipes
composable, fixed here; the skills type no slots of a library). A
compound variant whose condition names the recipe's own variants is
still rejected in such a function; that is not fixed here.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
0 commit comments