✅ Deploy Preview for tauri-docs-starlight ready!

Name	Link
🔨 Latest commit	25b086e
🔍 Latest deploy log	https://app.netlify.com/sites/tauri-docs-starlight/deploys/64d35c1a8f60c700086ac22e
😎 Deploy Preview	https://deploy-preview-1365--tauri-docs-starlight.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Continuing the conversation from #1363 ...

I copied the v1 approach into here so we can have something to look for this question.

Awesome, thank you! <3

I'm a bit unsure how we want to handle sub commands. I don't think the approach used in v1 is the best fit but i can't think of anything much better. For example tauri android looks fine as is imo, so one section for all sub commands but the plugins commands i think are better suited to have a section each beacuse a) they are all pretty different to a point i feel like it's weird that they are in one, like plugin add vs all the rest basically (the "rest" is about modifying the current plugin project while plugin add is about adding a plugin to the current non-plugin project) and b) because some of these subcommands have subcommands

Maybe this is an upstream question... but why do we have tauri plugin ios vs tauri ios plus tauri plugin android vs tauri android? I can see this being super confusing from a DX perspective.

Also i'm a bit unsure about the wanted level of verbosity, do we want to keep it fairly simple as it is now, though i'd like to convert it into tables like here https://vitejs.dev/guide/cli.html, or do we want it a bit more text-like and split-up like how astro does it https://docs.astro.build/en/reference/cli-reference/

I think I prefer the current, non-table format. We can work on adjusting the formatting (because right now it's a ton of code blocks and inline code which can be tough to glance through), but I think this is a really solid foundation.

Two more points:

• One place I'd consider a table is at the top of a breakdown of each command and then the one-line description of what it's for/does.
• On the completions I think it'd be better to not break out the Bash, Zsh, etc. sections and instead any of that relevant helper text should be in the CLI itself. Makes it to where if upstream changes anything there that we don't get doc mis-matches either.

Thanks for being amazing @FabianLars <3

Also, in addition to the table I mentioned, I think a quick tabbed code block of how to install the CLI would be amazing up at the top.

One final thing: upstream is working on some fancy stuff that we can do in code blocks, so that might help the walls of code blocks be a bit more formatted once it's in: withastro/starlight#461 (comment)

(I really should just let my replies sit for a few minutes before I hit comment so I don't post back to back replies 😅 )

Notes that I'll open a tracking issue upstream for:

• Competitions instructions should be inline in the CLI and not something in the docs
• plugin add should be renamed to add
• Any additional information (like in the info and dev commands) should be added directly the the CLI upstream

If/when those are resolved then we can come back and revise this.

Does everything else look alright to a second pair of eyes?

Do we want to make all section use tabs for commands in this pr or later when #1366 is resolved?

otherwise looks good ig

Ahh good point, I read that but missed it on the current pass. That component should be super simple to make so it might be better to just whip it up and do it right the first time.

Closes #1366

Looks good now, going to merge it in 💪