There are many cases where a library will have multiple variants of its components and a user should be able to choose
icons frequently come in both solid and outlined sizes. This is currently handled in the registry for heroicons by combining them into heart-solid and heart-outlined suffixes for every icon, which works but is less than ideal
utility function libraries like Just have variants for ESM and CJS module formats
shadcn/ui has "default" and "new york" styles for its components, and Draft UI and Jolly UI could benefit from similar capacities to choose
Proposal
Add a --variant flag to the CLI that will allow the user to choose. This will be reflected as a field in the sly.json config for that library to allow users to omit the flag from their commands.
Interactively, when a user first adds a library they should be prompted to choose which variants they want to add. When there is only one variant, we could force them to choose every time (an extra enter press) or skip the selection screen. This would be similar to when you run sly add and you are prompted to choose one of your configured libraries, with an option to add/config new ones.
Risks
This model works as long as users are always choosing between variants, but fails if users need to combine variants. Adding the ability to choose fine-grained variant combinations, such as an "esm, non-rsc, dark mode only" button component would be neat, but that sounds very challenging to maintain and there's no real precedent for it. I think the single-variant approach plus allowing users to provide their own transformers for other changes solves most practical use-cases here.
Context
There are many cases where a library will have multiple variants of its components and a user should be able to choose
Proposal
Add a
--variant
flag to the CLI that will allow the user to choose. This will be reflected as a field in the sly.json config for that library to allow users to omit the flag from their commands.Interactively, when a user first adds a library they should be prompted to choose which variants they want to add. When there is only one variant, we could force them to choose every time (an extra enter press) or skip the selection screen. This would be similar to when you run
sly add
and you are prompted to choose one of your configured libraries, with an option to add/config new ones.Risks
This model works as long as users are always choosing between variants, but fails if users need to combine variants. Adding the ability to choose fine-grained variant combinations, such as an "esm, non-rsc, dark mode only" button component would be neat, but that sounds very challenging to maintain and there's no real precedent for it. I think the single-variant approach plus allowing users to provide their own transformers for other changes solves most practical use-cases here.