Skip to content
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

Adjust the opt-out behavior of CLI flags #350

Open
AdrianGonz97 opened this issue May 10, 2024 · 4 comments · May be fixed by #376
Open

Adjust the opt-out behavior of CLI flags #350

AdrianGonz97 opened this issue May 10, 2024 · 4 comments · May be fixed by #376
Labels
enhancement New feature or request

Comments

@AdrianGonz97
Copy link
Contributor

Topic

applies to all adders

Description

It would be preferable if the CLI flags were designed to be opt-in rather than opt-out.

One can imagine that when a couple of more plugins are added, it would quickly become cumbersome to add all of these opt-out flags just to avoid the CLI wizard:

npx @svelte-add/tailwindcss@latest --typography false --forms false --scrollbars false --other-plugin false --one-last-one false

Describe the solution you'd like

Instead, it should be the inverse, where adding the flag includes the addon/plugin:

npx @svelte-add/tailwindcss@latest --typography --forms

Alternative

An alternative could be to include a --none flag to preserve the default state of running through the CLI wizard, but also not having to add all of the flags to avoid it either:

npx @svelte-add/tailwindcss@latest --none
@AdrianGonz97 AdrianGonz97 added the enhancement New feature or request label May 10, 2024
@manuel3108
Copy link
Member

The problem I see with

npx @svelte-add/tailwindcss@latest --typography --forms

is that this

npx @svelte-add/tailwindcss@latest

would implicitly assume that all options are false / fallback to the default value and that this would not trigger the interactive cli.

That's why I would currently prefer the your suggested alternative, although I'm not sure if --none would represent the correct meaning. Maybe something like --default would be a better fit

@AdrianGonz97
Copy link
Contributor Author

Agreed, --default is definitely the better fitting name and solution.

@manuel3108
Copy link
Member

Please do not consider working on this until #368 is merged, as it was necessary to rewrite major amounts of the execute.ts file (not commited), which would cause massive merge conflicts and create unnecessary work.

@manuel3108
Copy link
Member

unblocked

@AdrianGonz97 AdrianGonz97 linked a pull request May 26, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants