[feat] tauri version subcommand to sync versions across all config files

[CBx0-dev]

Describe the problem

Bumping the app version in a Tauri project requires manually editing multiple files that must stay in sync:

• tauri.conf.json
• package.json + package-lock.json
• src-tauri/Cargo.toml + Cargo.lock

There is no built-in command to do this automatically, which is error-prone and slows down both local development and CI/CD pipelines (e.g., automated release workflows that need a single version bump step).

Describe the solution you'd like

Add a tauri version subcommand to the Tauri CLI, similar to npm version:

# sets exact version
npm run tauri version 2.1.0

# bumps patch (1.2.3 → 1.2.4)
npm run tauri version patch

# bumps minor (1.2.3 → 1.3.0)
npm run tauri version minor

# bumps major (1.2.3 → 2.0.0)
npm run tauri version major

The command should update all version fields atomically:

• version in tauri.conf.json
• version in package.json and package-lock.json
• version in src-tauri/Cargo.toml and src-tauri/Cargo.lock

Alternatives considered

No response

Additional context

No response

[sftse]

Versioning can be quite different depending on the project, for me only the one in tauri.conf.json is changing, as it is relevant to app users. Why would one need the versions of the others to change?

[CBx0-dev]

Yes, for small projects, changing only the version in tauri.conf.json is enough, but there are cases where keeping them in sync matters:

Consistency & tooling
Many tools read the version from package.json or Cargo.toml. If those diverge from tauri.conf.json, automated workflows can break or produce misleading release artifacts.

JS frontend as a published package
If the frontend is structured as an npm package, for example when exposing a JavaScript API for communication between the core app and its plugins, the version in package.json has semantic meaning beyond just the app itself. A version mismatch would mean that compatibility cannot be managed via SemVer automatically.

Cargo.toml
Rust crates in src-tauri can also be published or referenced by other workspace members. Again, version drift here can cause real issues.

---

Currently, such things can only be managed by third-party tools on the Rust, npm, etc. side. This makes it hard to write CI/CD pipelines. For myself, I increment version numbers with jq and sed, which is tedious and very error-prone.

About the different project layouts, this could be fixed by requiring the exact path and type of the config file, or by falling back to the underlying package manager's own version command (npm version, cargo set-version).

[sftse]

If the project is housed in a monorepo, version numbers are not used that often, the whole state of the repo is determined by the commit. In such a case automatically bumping versions other than tauri.conf.json is a disadvantage, it forces us to automate updating even more version numbers.

Which is to say, depending on the project there are different versioning requirements. As I recall this was the same conclusion of cargo when there was a discussion how to automate releases.

[CBx0-dev]

I get your point. This can be fixed by following an explicit-over-implicit approach.

For example, by declaring the files to update as arguments (all optional):

tauri version patch 
  --config ./path/to/tauri.conf.json 
  --package-json ./path/to/package.json 
  --cargo ./path/to/Cargo.toml 
  --no-lock

This would also comply with monorepo setups, since what gets updated is completely defined and customizable and we don't have to touch config files in CI/CD manually.

[sftse]

Is the suggestion to add a command for this, even though custom code is needed as soon as it's part of a workspace?

[CBx0-dev]

Could you clarify what you mean by "custom code is needed"? With explicit flags, you'd just specify exactly which files to update, no scripting required. In a workspace context:

tauri version patch --config packages/my-app/tauri.conf.json

The Tauri CLI already touches most of these config files anyway, either directly or indirectly by delegating to npm, yarn, cargo, etc.. A dedicated version command would just formalize that, improving DX and reliability instead of leaving it to custom scripts built around error-prone tools like jq or sed.

Is there a specific scenario you have in mind where that still wouldn't be sufficient?

[sftse]

Rust crates in src-tauri can also be published or referenced by other workspace members. Again, version drift here can cause real issues.

If we are both in a workspace and want to publish packages, we need to bump all mentions of the target crate in Cargo.tomls. This could be done by other means than custom code. We could delegate to cargo set-version but then have to assume it as a dependency, there's no package manager built-in way to do this.

The CLI to do this might look like this

tauri version patch 
  --config ./path/to/tauri.conf.json 
  --package-json ./path/to/package.json 
  --cargo
  --no-lock

Does this still need an explicit path to Cargo.toml? Probably yes, I don't know if there's a 1-to-1 association of tauri.conf.json with a Cargo.toml.
What would --no-lock do?