Project Information

Every Tauri project includes a Cargo.toml file inside the src-tauri directory. This file is the manifest that tells the Rust toolchain what your program is, how to build it, and which crates it depends on. The [package] section sits at the top of that file and defines the identity of your Rust binary — who made it, what version it is, and what license it carries.

For a Tauri app, this metadata is not just a formality. The package name becomes the default binary name, the version flows into your app’s window title and update checks, and the edition controls which Rust language features are available. Getting these fields right from the start avoids confusion later when you are distributing releases or integrating plugins.

Package Name

The name field is the identifier Cargo uses for your Rust package. It becomes the name of the generated executable binary (unless overridden by [[bin]] sections) and, if you ever publish the crate to a registry, it must be unique across the entire registry.

In a Tauri project created with create-tauri-app, this field defaults to the project name you entered — for example, tauri-app. You can change it at any time, but keep these constraints in mind:

• Only alphanumeric characters, hyphens, and underscores are allowed.
• The name must start with a letter.
• Cargo replaces hyphens with underscores when generating the crate’s module name internally.

Below is how it appears in a typical Tauri Cargo.toml:

[package]
name = "tauri-app"
version = "0.1.0"
edition = "2021"

The name here will be used as the default application identifier if you do not explicitly set one in tauri.conf.json. Tauri derives the identifier by inverting the package name (for example, tauri-app becomes com.tauri-app.dev during development). Explicitly setting an identifier in the Tauri configuration is still recommended for production apps.

Version

The version field declares the current version of your Rust package using Semantic Versioning — a major.minor.patch scheme.

For Tauri applications, the version in Cargo.toml is the source of truth for the app’s internal version number. The Tauri runtime reads it and exposes it via the app.getVersion() API on the frontend. If you use the updater plugin, the version here is compared against the server’s latest release to decide whether an update is available.

[package]
name = "tauri-app"
version = "1.2.3"
edition = "2021"

A few practical points:

• Pre-releases like 1.0.0-alpha.1 are valid and fully supported by Cargo.
• The tauri build command automatically injects the version into the app’s metadata, so you do not need to duplicate it elsewhere.
• If you maintain a separate version in tauri.conf.json, it is your responsibility to keep them aligned. Many teams script this alignment in their CI pipeline.

Edition

The edition field specifies which Rust language edition your crate uses. It controls syntax compatibility and a few compiler behaviors, not the Rust compiler version itself.

For all new Tauri v2 projects, you should set:

edition = "2021"

Rust editions are released roughly every three years and are always backward‑compatible with existing code. Choosing 2021 means you can use features like async blocks in more places, the TryInto and TryFrom implementations for arrays, and the newer resolver.

Authors

The authors field is an optional list of people or organizations that contributed to the project. It is purely informational — Cargo does not enforce it, and it is not required for building or running the app.

In a Tauri project, the scaffolding tool leaves the authors field as an empty list, which you can fill with a string like "Your Name <you@example.com>":

authors = ["Your Name <you@example.com>"]

License

The license field declares the open‑source license under which your Rust crate is distributed. While Cargo does not require it for local development, it becomes critical if you ever publish the crate or distribute compiled binaries.

Use a valid SPDX license identifier. For Tauri apps, the two most common choices are:

license = "MIT"

or

license = "Apache-2.0"

If your project uses both licenses, you can separate them with OR:

license = "MIT OR Apache-2.0"

If you want to withhold granting rights entirely, you can omit this field — but that means “all rights reserved,” and nobody can legally use, modify, or redistribute your code.

Additional Metadata Fields

Beyond the core fields, Cargo supports several optional keys that add useful context, especially when your source is hosted publicly or you are building a team project. These fields are not required by Tauri, but they appear in documentation, registry listings, and tooling output.

[package]
name = "tauri-app"
version = "0.1.0"
edition = "2021"
authors = ["Your Name <you@example.com>"]
license = "MIT"
description = "A desktop productivity tool built with Tauri"
repository = "https://github.com/your-org/tauri-app"
homepage = "https://your-app-website.com"
documentation = "https://docs.your-app.com"
keywords = ["tauri", "productivity", "desktop"]
categories = ["gui"]

• description — A short sentence explaining what the app does. It is displayed by cargo search and on crates.io.
• repository, homepage, documentation — URLs that point to the code, the main website, and documentation respectively. These make your project easier to navigate.
• keywords and categories — Used for discoverability on crate registries. keywords is a list of up to five terms; categories must be chosen from the official Cargo category list.

None of these fields affect the compiled Tauri binary, but they improve the developer experience for anyone reading or depending on your code.

Putting It All Together

Here is a complete, minimal Cargo.toml for a Tauri v2 app with a React + Vite frontend. The [package] section carries all essential project information, while the rest of the file (covered in later sections) handles dependencies and build configuration.

[package]
name = "my-tauri-app"
version = "0.1.0"
edition = "2021"
authors = ["Your Name <you@example.com>"]
license = "MIT"
description = "A sample Tauri desktop application"
repository = "https://github.com/your-org/my-tauri-app"
[build-dependencies]
tauri-build = { version = "2", features = [] }
[dependencies]
tauri = { version = "2", features = [] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"

When you run cargo build inside src-tauri, Cargo reads this [package] information and uses it to name the binary, set the version, and validate the code against the declared edition. The frontend (React + Vite) does not directly consume these values — it receives version and name information through Tauri’s APIs, which pull them from the compiled binary.

If your Tauri config (tauri.conf.json) does not specify a product name, Tauri falls back to the package name from Cargo.toml. Keeping both consistent reduces confusion, but knowing that they are independent gives you flexibility when the developer‑facing crate name and the user‑facing app name should differ.

Summary

The [package] section in Cargo.toml is the identification card of your Tauri app’s Rust core. The name and version drive the app’s runtime identity and update logic; edition gates language features; authors and license clarify ownership and usage rights. Getting these fields correct takes only a few minutes, but it prevents versioning bugs, license misunderstandings, and awkward build failures.