feat(cli): add config files and examples in docs

[Princezhm]

what this pr adds:

• the capability to add config files and setup different configurations to avoid/skip some steps
• allow the user to define entry points for files that will be used on some components and you have to change by hand

also noticing that different people added different kinds of versions of this, I wanted to go with the prettier approach, which is basically add Cosmiconfig which natively allows you to define a lot of entry points, I decided to name the entry point of configuration as shadcn-ui but we can change it, basically all the entry points allowed are:

1. "shadcn-ui" key in your package.json file.
2. .shadcn-uirc file written in JSON or YAML.
3. .shadcn-uirc.json, .shadcn-uirc.yml, .shadcn-uirc.yaml or .shadcn-uirc.json5 file.
4. .shadcn-uirc.js, .shadcn-uirc.cjs, shadcn-ui.config.js or shadcn-ui.config.cjs file that exports an object using module.exports.
5. .shadcn-uirc.toml file.

also edited the CLI entry of the documentation to show some explanation and examples:

I think this will solve also the cases provided by:

#244 by @Rawnly

#240 by @JohnDaly

could fix https://github.com/shadcn/ui/issues/207 could fix https://github.com/shadcn/ui/issues/236

[vercel[bot]]

@Princezhm is attempting to deploy a commit to the shadcn-pro Team on Vercel.

A member of the Team first needs to authorize it.

[rawnly]

Looking forward for this! 😍

[shadcn]

Woah! Incredible work! This saves me a lot of time. I'll review and we can merge.

I think we should consider a different name for the config file. Maybe .componentrc something like this...

[Princezhm]

yeah, I can do it, if you can review it and if you need me to move things around let me know. also @Rawnly you had worked on things like this before, if you have ideas of things to add, they would help a lot.

[rawnly]

LGTM! The naming is up to @shadcn. Honestly I think that "shadcn-ui" or something similar would be more clear.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
next-template	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 27, 2023 11:26am
ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 27, 2023 11:26am

[Princezhm]

Hi @shadcn any news on this pull request? should we merge it or do you want to do some changes? I'm open to help in whatever you need/think.

[shadcn]

@Princezhm Yes. This is definitely going on. I'm going to focus on this and get it merge this weekend. (Sorry been busy with the day job).

[ttmachado]

This looks great! The default behavior of the settings that require the user to provide paths could be improved by looking through the project's folders for a preset of common names (ex.: src/components/ui/, components/).

There should be restrictions to ensure that the function only runs inside the project's root folder, does not look inside hidden folders (who stores components inside these? :eyes:) and has a maximum search depth.

Does this sound like a good improvement or is it too much?

[Princezhm]

This looks great! The default behavior of the settings that require the user to provide paths could be improved by looking through the project's folders for a preset of common names (ex.: src/components/ui/, components/).

There should be restrictions to ensure that the function only runs inside the project's root folder, does not look inside hidden folders (who stores components inside these? 👀) and has a maximum search depth.

Does this sound like a good improvement or is it too much?

actually @tomas-machado If I understand correctly, you want to change the inner imports of the utils/other components, right? if that is the case, I already took care of it on https://github.com/shadcn/ui/pull/245/files#diff-2fb448d11702324cc59d657d5945d59cd325540eb87b71f2e66a5bc01ada834cR173-R182 where all the imports that the components are using matches with the new folder structure predefined by the user.

on the other hand, if what you want is to automagically look for a folder that matches something like */**/components/, I don't think is the best idea, mostly because it will try to install the components on that folder but probably you don't want them there.

for example I leave my own components inside src/client/components/* but I leave the shadcn-ui components inside src/ui/* so I can have everything grouped in different paths, what I want to point with this, is that not always following the */components/* search can lead to the right path.

anyways, if I miss understood you, let me know, there is always something to add 🥇

[ttmachado]

on the other hand, if what you want is to automagically look for a folder that matches something like */**/components/, I don't think is the best idea, mostly because it will try to install the components on that folder but probably you don't want them there.

for example I leave my own components inside src/client/components/* but I leave the shadcn-ui components inside src/ui/* so I can have everything grouped in different paths, what I want to point with this, is that not always following the */components/* search can lead to the right path.

anyways, if I miss understood you, let me know, there is always something to add 1st_place_medal

:wave: @Princezhm

After looking through the project's files and finding a match, it should be presented as a suggestion that the user can accept (the same behavior that is already being used). It should not be used as the final value without prompting for an action. Once the user accepts the suggestion it could be used and saved inside a config file.

If a user has already defined the path they would like to use inside their config, this process should be ignored.

Let me know if this addresses your concerns.

[ttmachado]

After looking through the project's files and finding a match, it should be presented as a suggestion that the user can accept (the same behavior that is already being used). It should not be used as the final value without prompting for an action.

I thought about this a bit more and it is probably better not to implement this. Asking the user for the path once is ok.

Once the user accepts the suggestion it could be used and saved inside a config file.

After asking for the path, the user can be prompted to choose if they would like to save it inside a config file.

[Princezhm]

After looking through the project's files and finding a match, it should be presented as a suggestion that the user can accept (the same behavior that is already being used). It should not be used as the final value without prompting for an action.

I thought about this a bit more and it is probably better not to implement this. Asking the user for the path once is ok.

Once the user accepts the suggestion it could be used and saved inside a config file.

After asking for the path, the user can be prompted to choose if they would like to save it inside a config file.

that would be possible, you mean like creating a default configuration file, I would go for the .shadcn-uirc, in this weekend I could implement something similar among other improvements that I was thinking.

[ttmachado]

that would be possible, you mean like creating a default configuration file, I would go for the .shadcn-uirc, in this weekend I could implement something similar among other improvements that I was thinking.

This is how I thought about it:

1. Prompt the user to provide the path they would like to use.
2. Ask if it should be saved in a config file for future reference (skip next steps if false).
3. Provide a list of the supported config locations (ex.: package.json, .shadcn-uirc, etc) and let the user choose one.
4. Create the entry inside the chosen location and let the user know if everything was done successfully.
5. Provide a link to the CLI Config section of the documentation.

Let me know what you think and if you need some help implementing it :+1: