RFC: create-tauri-app Rewrite

[lorenzolewis]

The purpose of the create-tauri-app rebuild is to create a single entry-point for any user coming from any background or project setup and enable them to quickly get started with Tauri.

This should be implemented in a way that can run on any system without dependencies (i.e. Node, Rust) being setup and with the goal of including the work @chippers is working on around prerequisites.

Note: This is currently just in the stage where we request comments on the USER FLOW. The actual technical implementations and details can be hashed out during development.

---

Personas

These are the different types of users and the paths they could take when getting started with Tauri.

Benny: New Node Project User

• Familiar with Node
• Wants to stay in the Node ecosystem/tooling

Jannett: New Rust Project User

• Familiar with Cargo/Rust
• Wants to stay in the Rust ecosystem/tooling

Jose: New to Both Ecosystems

• "I don't have a preference on which tool I use"
• Could be new to development or coming from a Java or similar background

Matéo: Existing Node Project User

• Already has a Node project setup and just wants to add Tauri to it

Ginevra: Existing Rust Project User

• Already has a Rust project setup and just wants to add Tauri to it

Flows

Benny: New Node Project User

1. npm create tauri-app
   • Executes a native node add-on, similar to how we do with @tauri-apps/cli (thanks, Amr!)
2. Skip forward to Common Flow...

Jannett: New Rust Project User

1. cargo install create-tauri-app
   • Builds create-tauri-app binary
2. Execute cargo create-tauri-app or create-tauri-app
3. Skip forward to Common Flow...

Jose: New to Both Ecosystems

1. Run curl create.tauri.app | sh that downloads and executes create-tauri-app Rust Engine
2. Skip forward to Common Flow...

Matéo: Existing Node Project User

1. npm create tauri-app
   • Runs shell script curl create.tauri.app | sh that downloads and executes create-tauri-app Rust Engine
2. Skip forward to Common Flow...

Ginevra: Existing Rust Project User

1. cargo install create-tauri-app
   • Builds create-tauri-app binary
2. Execute cargo create-tauri-app or create-tauri-app
3. Skip forward to Common Flow...

Common Flow

0. ❓ Check if prerequisites are met...
   • Need check with @chippers on what he's building and how it could be integrated
1. If setup initiated through shell script directly (not via Node)...
   • If a Node project exists...
     • Go to "If setup initiated via Node" step
   • If a cargo project exists...
     • Go to "If setup initiated via cargo..." step
   • Else ask user if they'd like to use Node or cargo
     • Fall through to relevant step based on choice
2. If setup initiated via Node
   • If there is already a Node project...
     • Add Tauri as dependency
     • Run tauri init prompting for these questions:
       • (Would be good to link to a Getting Started guide that explains each of these commands a bit better before/during being prompted)
       • (Dynamically parse out the project name from package.json)
       1. Before Dev Command
          - ❗️ Would need to be added to tauri init upstream
       2. Dev Path
       3. Before Build Command
          - ❗️ Would need to be added to tauri init upstream
       4. Dist Dir
   • Else set up a new Node project...
     • Ask them which package manager they want to use (yarn, npm, etc.)
     • Ask which frontend template they want to use (vanilla, Svelte, React, etc.)
     • Setup relevant template
3. If setup initiated via cargo...
   • If there is already a cargo project...
     • Add Tauri to dependencies
     • Ask which frontend template they want to use (vanilla, yew, dominator, etc.)
   • Else setup a new cargo project bootstrapped with the HTML template
4. Link to the Getting Started Guides

Technical Implementation

Shell Script

Only responsible for downloading and executing the compiled create-tauri-app Rust Engine

Node

Only responsible for downloading and running the shell script (or directly downloading and executing the create-tauri-app Rust Engine)

create-tauri-app Rust Engine

TBD

Templating System

Have some way to have centralised styles and assets to 1) minimise bundle size and 2) centralise styles if we want to update them later.

TBD

Prerequisites Checker

TBD, need to check with @chippers on this and see how we can implement it.

CC @amrbashir @JonasKruckenberg @chippers @FabianLars

[amrbashir]

I like it overall but I think there is two places that could be improved:

Matéo: Existing Node Project User
npm create tauri-app
Runs shell script curl create.tauri.app | sh that downloads and executes create-tauri-app Rust Engine

for this use-case, we could build create-tauri-app as a native node addon, same as how we do with @tauri-apps/cli nowadays

If there is already a cargo project...
Add Tauri to dependencies
❓ Do we want to bootstrap an HTML template here?
❓ Do we want to have an file with an example of the Tauri stuff in Rust here?
Else setup a new cargo project bootstrapped with the HTML template

This should be the same flow as if there is already a Node project

[lorenzolewis]

for this use-case, we could build create-tauri-app as a native node addon, same as how we do with @tauri-apps/cli nowadays

Yeah, whichever implementation for that is easiest and least duplication of work sounds perfect! I think the important bit would be to still allow a user to run something like npm create tauri-app

This should be the same flow as if there is already a Node project

So this would prompt them to choose which template they want? Wouldn't that require bootstrapping a Node project if they choose anything except the basic HTML one?

[amrbashir]

for this use-case, we could build create-tauri-app as a native node addon, same as how we do with @tauri-apps/cli nowadays

Yeah, whichever implementation for that is easiest and least duplication of work sounds perfect! I think the important bit would be to still allow a user to run something like npm create tauri-app

I agree

This should be the same flow as if there is already a Node project

So this would prompt them to choose which template they want? Wouldn't that require bootstrapping a Node project if they choose anything except the basic HTML one?

There will be more than one template for cargo, ideally we would have vanilla, yew, and dominator. The later two are rust-wasm based

[lorenzolewis]

There will be more than one template for cargo, ideally we would have vanilla, yew, and dominator. The later two are rust-wasm based

So for cargo path we'd still have the templating option, just to begin with it would be just vanilla. But the templates we offer to someone using cargo vs. node would be different, right?

[amrbashir]

correct

[lorenzolewis]

Awesome, updated that in the main body.

Btw, for "vanilla", we should probably align the terms used in the docs and here. "Vanilla" and "HTML/CSS/JS" are the same and could be a bit confusing.

[jbolda]

Pulling Thoughts From Discord.

This is a lovely compilation of information. The "Flows" will be especially helpful in designing the entry points. Note that we do have an RFC template with some questions that I think would be helpful to answer.

We had a few points of discussion in discord that I am summarizing here for clarity.

• Does it need to be dynamic?
  • It will likely still have user inputs.
  • Fills in, at minimum, the user app name (so some kind of templating is needed).
• What does the project include (some of this has been defined, vite + mirrors of their templates is one option)?
  • It sounds like we want to provide multiple templates.
  • On the Node side, vite seems to be the highly favored, and, at minimum, the only option.
  • On the Rust side, bundlers aren't a discussion point and make it less hierarchical. Seems vanilla, yew and dominator are likely options here.
• How can we scale if need be for ^?
  • The Rust side is likely built with a bit of "more than one template" in mind already.
  • The Node side, while at minimum using one bundler, we still have many templates. So we also are considering more than one template.
• Do we need to check for prereqs?
  • I think this is helpful, but has many potentional implementation options including within Tauri CLI proper? (This isn't just a greenfield consideration.)
• Do we need to install anything for the project?
  • I don't think this needs to be dictated upfront, but it can be flexible based on implementation.
• We need to consider connections / firewalls / rate limits (GitHub for instance)
• Consider the size.
• Have some way to test this.

Specific Comments Regarding Flows

2. [...] If there is already a Node project..

Originally this felt a bit odd to me as this isn't a typical feature of create-*-apps. Honestly though, it would probably make our documentation much easier to explain, and we are mostly falling back to tauri init here anyways. I would recommend this is a feature added after the initial implementation though (i.e. 2.1.0 feature).

2. [...] Ask them which package manager they want to use

We were originally using the package manager that they invoke the project with. Is there a reason we are walking back on this concept?

Specific Comments Regarding Initial Technical Implementation Ideas

I am not specifically against using Rust, in part or full, for many / all of these features. I think the ideas around the shell script may be a bit misplaced. We have already seen issues downloading assets in the past to execute, and now we are expecting that the user has specific shells installed and configured off of a create-*-app. I can understand this a bit more as part of project setup and prereqs if it is absolutely required, but I think this will lead to people running CTA and just giving up off unintelligible errors.

Moving Forward From Here

I would recommend that we go through the RFC questions as well. This content currently is more of a research / spike / research phase.

I think it is worth opening up a discussion (and the discussion board on CTA) to ask the community what was the positives and negatives of the current experience. We both want to improve on the current experience, and not regress unless there is a really pressing positive.

In my push for better management and documentation, I have a few documents that I want to kind of get together around our current architecture and why we are looking to change it now. This will also serve useful for considering future work.

[amrbashir]

[...] Ask them which package manager they want to use
We were originally using the package manager that they invoke the project with. Is there a reason we are walking back on this concept?

With the new method of installation curl create.tauri.app | sh, we can't detect the package manager, so we have to prompt for it. Other installations methods which include NPM pkg, and a crates.io crate will actively detect the package manager and skip the prompt or pre-select it for them.

I think the ideas around the shell script may be a bit misplaced.

why so? we are tryin to target more communities and when we make new bindings for tauri, new communities will need some templates of their own, and the most common tool between all developers no matter which community he is in, is a shell.

We have already seen issues downloading assets in the past to execute

I am hoping to find a solution for this.

now we are expecting that the user has specific shells installed and configured off of a create-*-app

We will require macOS and Linux to have, sh and wget or curl, nothing more and these are probably already installed on a developer system. On Windows, we will use powershell and its built-in APIs.

[chippers]

Need check with @chippers on what he's building and how it could be integrated

https://github.com/chippers/tauri-init

I haven't touched it in a few months, so far installing the system prerequisites only works on macOS.

I had made some progress on Windows, but never finished it. Along with stuff like "we need to download the Microsoft VS binaries at runtime to satisfy their license distribution policy," automatically finding and installing only what the user is missing turned out to be difficult (or tedious?). It seems like Rustup has it's own answer to the problem that looks similar to what I was working on, where it installs the Windows prerequisites for Rustup during install (https://internals.rust-lang.org/t/help-verify-rustup-1-25-0-release/16783). I think the correct move for Windows support is waiting for that Rustup version to release and rely on that. It will eventually end up being the most common configuration even if it is different (not that I've checked).

I haven't touched Linux, but I think it will be easier because we can support the most common distributions (mapping their version to the correct packages), and otherwise give a non-interactive prompt for the user with hints of where to look to find the correct packages and run their command to install it.

The tauri-init name is not set in stone, we have discussed other names like tauri-bootstrap. The goal is to install the bare minimum for a non-node project to work. Additionally, in the future we would want to optionally support platforms such as Node/NPM. I am also considering changing the license from MIT/Apache-2.0 to something more copy-left since this is a standalone tool that should always be open and available.