-
-
Notifications
You must be signed in to change notification settings - Fork 336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: --nodep or similar flag for init CLI command #1196
Comments
I'm cool with adding a Implementing that would make sense if each version of |
That seems like a good compromise the only issue is that users would need to understand what dependencies each component requires since they wouldn't be added with the -nodeps flag enabled. Not sure if that would be worth adding documentation for. Maybe a (next steps) prompt or something could be useful in that case to say install this this and this. But I also understand that's a pretty narrow use case anyways and it probably isn't too big of a deal to look through the code and find them. |
It's actually in the docs and can be found under the Manual Installation section for each component If you want to access them programmatically, you could always fetch them from this endpoint as well: https://shadcn-svelte.com/registry/index.json |
Oops sorry I didn't know that yeah that would be perfect then we will just need to add a similar section when we add the flag for init |
I can put together a PR for this tomorrow |
Describe the feature
There is already a
--nodep
flag on the add command which prevents adding and installing dependencies.In some cases it would be nice to be able to not install dependencies (such as in automated tasks) but while still adding dependencies.
Ideally we could split the flag into
--no-install
and--no-add
or something along those lines that allows users to optionally install dependencies by using the flag.New Init:
New Add:
This would require us to add dependencies in a new way something like this could work:
This would require us to version the dependent packages (which may be nice to do anyways)
If this is something that you'd be open to including I can of course open a PR for it!
The text was updated successfully, but these errors were encountered: