-
-
Notifications
You must be signed in to change notification settings - Fork 37
feat: specify add-on options in command args #543
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
base: main
Are you sure you want to change the base?
Conversation
|
commit: |
Ah, interesting catch on the paraglide add-on. The only other option I can think of is to do what CSV does when there's a comma and wrap that value in quotes:
|
That's an interesting idea that could work! Another idea that might work would be to eliminate the ambiguity of specifying options which would act as it's own separator as well: sv add paraglide=languageTags:en,es,de,demo:no
sv add drizzle=database:postgres,client:postgres.js,docker:yes However, it's a bit more verbose and can get awkward around the |
Adding the option name in there does make things clearer. Though it's still a little hard to read since
|
Sadly the quotes method ( You can view this in action by running
Good point! Using a edit: Using a |
I've updated the PR to now use the |
Generally, this seems like the perfect solution. We should have found that way earlier. It's way more descriptive and more clear what you are actually trying to achieve. Also the first tests seemed pretty successful. But this currently fails for me
Probably because it does not know if the comma should separate an option or an option value (like for tailwind forms). Alternatively, this might be on of those things that's only happening on windows. The same goes for this one:
Alternatively, I'm just not aware of the correct syntax.
I wouldn't necessarily deem this as obligatory. Based on the docs Ben drafted, this should be pretty clear how to use them. |
Running this line works perfectly for me on linux, so I'm going to guess it's Windows 🙃. Will take a closer look in a few. |
Here is a stack trace if you want:
The second paraglide option actually installs the demo, even though it's explicitly set to no. But this one does not throw an error |
As discussed on discord and partially in #533 the issue I was encountering did only happen on Windows while using PowerShell (others were able to reproduce this as well). The best / most simple workaround is to qoute all option args like this I would suggest that we go forward with this and update the recently introduced docs. Also, we should probably quote all add-on option values in the docs to avoid future confusion for windows users. |
Is that what the command ended up being? Or is a semi-colon between
I was going to say that I'd hate to make non-Windows users do that, but maybe it doesn't actually matter since I imagine very few people will be specifying long strings of options except inside scripts, so that's probably fine actually |
Currently it's commas everywhere.
Yeah, I do think this only affects a very small minority, so I'm not super concerned as well. And the quotes shouldn't break anything on *nix systems |
|
Unfortunately using an sv add paraglide="languageTags:en,de&demo:no" |
darn. I'd feared that. Quotes aren't the worst option though. I wonder if
|
Ooh, |
I think some of the new docs I added in https://github.com/sveltejs/cli/tree/main/documentation/docs/30-add-ons will need to be updated, but otherwise this is looking pretty good |
So it looks like the Adding quotes should only be necessary for add-on options that use arbitrary strings or lists (like typical usage (no quotes required, should work on Windows without issue): sv add drizzle=database:postgresql+client:postgres.js+docker:yes
sv add lucia=demo:yes
sv add sveltekit-adapter=adapter:node
sv add tailwind=plugins:none # `sv add tailwind=` is also the equivalent quotes required for arbitrary strings or multiselect prompts: sv add paraglide="languageTags:en,de+demo:no"
sv add tailwind="plugins:typography,forms" I wonder if should we just default to not using quotes in the docs until it's necessary? or should we just always wrap them for the sake of consistency? |
I think we could probably include quotes only where needed. But we should just be careful that if it's a place you could include a comma that we demonstrate it that way and don't use a simpler example |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can confirm everything is working correctly for me, as you already expected.
I agree with the decision regarding the docs, i think that makes sense
``` | ||
|
||
### demo | ||
|
||
Whether to generate an optional demo page showing how to use paraglide. | ||
|
||
```bash | ||
npx sv add --paraglide=demo | ||
npx sv add paraglide="demo:yes" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
npx sv add paraglide="demo:yes" | |
npx sv add paraglide=demo:yes |
@@ -27,5 +27,5 @@ Which plugin to use: | |||
- `forms` — [`@tailwindcss/forms`](https://github.com/tailwindlabs/tailwindcss-forms) | |||
|
|||
```bash | |||
npx sv add --tailwindcss=typography | |||
npx sv add tailwindcss="plugins:typography" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
npx sv add tailwindcss="plugins:typography" | |
npx sv add tailwindcss=plugins:typography |
// need to transform the boolean back to `no-{id}` or `{id}` | ||
existingOption = existingOption ? questionId : `no-${questionId}`; | ||
// need to transform the boolean back to `yes` or `no` | ||
existingOption = existingOption ? 'yes' : `no`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
existingOption = existingOption ? 'yes' : `no`; | |
existingOption = existingOption ? 'yes' : 'no'; |
partially implements #528 (although i'm moreso playing around with this idea atm)
While similar to #528, there's a minor difference when it comes to bailing/defaults:
I also had to configure our own
formatHelp
method to add a new help field that nicely displays the add-on options:It would also be nice to have an example on how to apply them (e.g.
Usage: sv add drizzle=database:postgresql,client:postgres.js,docker:yes
), but I'm not exactly sure where that should go in the help text just yet.Issues
Note
This has been resolved by requiring options to be listed with the
<name>:<value>
format (e.g.sv add addon=option:value
)I didn't notice this before, but the
paraglide
add-on is a bit of a nuisance when it comes to specifying its options. This is because one of its options prompts for arbitrary user input.For example, how do we parse this?
Since add-on options are delimited by
,
's andparaglide
uses a,
to delimit its own user input, how should we parse this? I'm not exactly sure yet, but this is an issue that occurs to this day with our current add-on option flags format:--paraglide=en,de,demo
. I guess one option would be to choose a new delimiter for theparaglide
add-on. Alternatively, we could change it to a;
for the add-on args (e.g.sv add paraglide=en,de;no-demo
).