feat: Add Trunk, Next.js, Nuxt Frontend Guides

[simonhyll]

Technically this might've spiraled out of control into more of a "framework configuration" PR but I started it as a PR for mobile configuration so damn it that's what the branch is gonna be for!

Currently looking for some input on whether this is a desired format. I kinda think these sort of framework configurations fit better into a section about project creation but I'm not sure.

Currently only the Next.js article is anywhere close to finished, the rest have yet to be written.

[netlify]

✅ Deploy Preview for tauri-docs-starlight ready!

Name	Link
🔨 Latest commit	8ce192a
🔍 Latest deploy log	https://app.netlify.com/sites/tauri-docs-starlight/deploys/64f38896e3d66800083f4c5c
😎 Deploy Preview	https://deploy-preview-1405--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.

[lorenzolewis]

Note to self from Discord https://discord.com/channels/616186924390023171/662624589037436928/1141394287901290657:

• Nice checklist CSS? Is that something that's exposed in Starlight that I can steal?
• Think through page structure and where this would slot in the best in the page hierarchy.

@FabianLars if you have any feedback on this (level of detail and technical content in particular) then would love to get your input as well.

[lorenzolewis]

Thinking of the flow, this would make the most sense for a person to read right after https://beta.tauri.app/2/guide/create/, right? I'd imagine this would be useful to surface very visibly and maybe put directly under the "Quick Start" sidebar category? And then shift the stuff in guide/develop to something like guide/framework/index?

I started thinking this weekend about an end to end DX/QA pass on 2.0 and I might ask the dev team if they'd be up to a challenge to see how much of that could be automated into the Tauri CLI when the audit kicks off (which could mean one less page in the sidebar 🥳 )

[lorenzolewis]

How accurate are all of these guides? If the next.js one is the only one near finished could we wrap that one up and then use the <Stub /> component (and include any notes you have) on the other pages and ask the community to contribute?

[FabianLars]

@FabianLars if you have any feedback on this (level of detail and technical content in particular) then would love to get your input as well.

So far it looks exactly like what i've had in mind (minus the everything on one page part but that may not work nicely anyway)

I started thinking this weekend about an end to end DX/QA pass on 2.0 and I might ask the dev team if they'd be up to a challenge to see how much of that could be automated into the Tauri CLI when the audit kicks off (which could mean one less page in the sidebar 🥳 )

Stop 😂 srsly tho, this is not something i'd like to outsource/upstream into the cli especially since some frontends like to change small things all the time and it would feed into the "tauri supports these frameworks, but no more" even more than just having guides imo.

[lorenzolewis]

@FabianLars that was more about the prerequisites (Xcode, Rust, etc., similar to how CTA does it now), not the per-framework setup. But yes, point taken 😉

[FabianLars]

Funnily the first draft of the message was about that. But yeah, it still applies to that too, realistically we could only autoinstall the deps on Windows if there's no visual studio installation and on Linux we'd have to cover 100 diff distros. No idea how reliably we can work with Android studio. Xcode I think is possible? It should be possible to install store apps from the cli 🤔
But yeah, that's something we talked about many times and for v1 chip even worked on something

[lorenzolewis]

Hope you don't mind but did a bit of re-work on this one to get it closer to the finish line:

• Moved intro section that was in guide/develop.mdx into guide/framework/index.mdx and referenced to that in guide/frontend/index.mdx
• Changed recommended CTA setup to Vanilla instead of Solid.js in guide/create/index.mdx
• Rephrased some things to try to be a bit more succinct.

A few points on feedback:

• You said that currently only the Next.js guide is complete. Can we remove the content from all the others and instead use a <Stub /> component (with any relevant notes inside that should be incorporated)?
• What do you think about moving any mobile-specific things into their own heading? That way it's very clear what's required for a desktop app vs. what's an extra step that's needed for mobile

I think we could easily look at making a few components/fragments for the sake of DRY across the guides, but let's get a single guide out and then see what we can refactor into components as we add more in.

[simonhyll]

So much activity while I've been at work 👀

The Next.js and Nuxt ones are more or less good as they are afaik and could be merged. Some of the others (mainly Rust based ones) also have some useful info in them, so not sure we want to remove them. Maybe add a stub thingie on top with something like "Needs updates"? Idk just dont want that "hard earned knowledge" to get lost. I can sit and update them a bit during the weekend possibly when I'm not studying for certificates.

I liked the frontend agnostic separate page. Sad panda is sad. But I also have no good argument against your approach of putting it straight on the page.

I think it being moved to where it is makes more sense indeed, right after creating a project.

Really like the big purple box saying the frameworks arent officially supported and unlisted stuff might be good to go as well.

I dont think we should make mobile its own section since the setup works for both, it makes little sense to give people a config that works 100% for desktop but only 70% for mobile, I'd rather everyone just configure their project to be 100% compatible for both straight away, less risk of people making mistakes while developing in case some feature of some framework doesnt work when they later make their project mobile capable and suddenly have to rethink a bunch of their setup.

[lorenzolewis]

Alright, this one is sooooooo close! 🥳 Just a few more details:

• Confirm feat: Add Trunk, Next.js, Nuxt Frontend Guides #1405 (comment)
• Does the adjustment for the trunk fork stuff look okay?
• feat: Add Trunk, Next.js, Nuxt Frontend Guides #1405 (comment) If this can lead to broken builds/dev by not being there then let's keep it
• feat: Add Trunk, Next.js, Nuxt Frontend Guides #1405 (comment) Advice from you experts on bininstall and if it's something we should mention or if we leave it to the reader to pull in if they're aware of it (we could also add a note to the top to point them to the documentation instead of using tabs here as an alternative)
• Ports: Do we want to hard-code all the ports as 1420 in the guides to match CTA? This might be one of the "not required but will improve support" things I'm okay with. If so, what port do we want do we want to use for cases like this to also be consistent:

  tauri-docs/src/content/docs/2/guide/frontend/nuxt.mdx

  Line 91 in 42807bb

  port: 5183,

• Renamed the svelte doc from sveltekit.mdx to svelte.mdx to give us some flexibility to change the title to whatever we want in the future without affecting the slug (can handle that convo later on).
• feat: Add Trunk, Next.js, Nuxt Frontend Guides #1405 (comment) fun telemetry convo 🙃

[lorenzolewis]

Alright, last thing is on ports: do we want to put 1420 on all the guides?

[amrbashir]

I'd recommend sticking with the framework's defaults, so users won't have to configure the framework server.

[lorenzolewis]

Cool, only one that needed updated was Trunk based off of https://github.com/thedodd/trunk/blob/7a27876ad1e38684ceb78239023a421dc1f46e84/Trunk.toml#L27

@amrbashir do you think it would make sense to update CTA eventually to make it all match the guide as well?

@simonhyll how does this all look to you? Are you alright to merge as-is in the current state (and if so then feel free to hit that big green merge button)?

---

On a complete side note: One idea I'd love to explore in the future is some sort of adaptor model for us to get as close to zero-config as possible with frameworks. I know we explored this a bit with SvelteKit. If we do that then we can in theory have CTA driven off of that, just point to an adaptor in docs, and then for manual setups just point to the code where the adaptor is applying the config. But just food for thought right now 🥘

[amrbashir]

do you think it would make sense to update CTA eventually to make it all match the guide as well?

Do you mean the ports? probably no, for CTA, I think it is better to add fixed ports, to stay clear from other projects potentially occupying the port.

[simonhyll]

Looks good to me 😄