Skip to content

Conversation

lucasfernog
Copy link
Member

check core plugin versions for incompatibilities between Cargo and NPM releases

a plugin NPM/cargo version is considered "incompatible" if their major or minor versions are not equal

on dev we show an warning
on build we error out (with a --ignore-incompatible-plugins flag to prevent that)

this is an idea from @oscartbeaumont
we've seen several plugin changes that require updates for both the cargo and the NPM releases of a plugin, and if they are not in sync, the functionality does not work e.g. tauri-apps/plugins-workspace#2573 where the change actually breaks the app updater if you miss the NPM update

check core plugin versions for incompatibilities between Cargo and NPM releases

a plugin NPM/cargo version is considered "incompatible" if their major or minor versions are not equal

on dev we show an warning
on build we error out (with a `--ignore-incompatible-plugins` flag to prevent that)

this is an idea from @oscartbeaumont
we've seen several plugin changes that require updates for both the cargo and the NPM releases of a plugin, and if they are not in sync, the functionality does not work
e.g. tauri-apps/plugins-workspace#2573 where the change actually breaks the app updater if you miss the NPM update
@lucasfernog lucasfernog requested a review from a team as a code owner August 12, 2025 20:04
@github-project-automation github-project-automation bot moved this to 📬Proposal in Roadmap Aug 12, 2025
@FabianLars
Copy link
Member

FabianLars commented Aug 12, 2025

We also talked about this briefly here #13960 (and in like a hundred discord threads 😂 )

tldr: Tony is mostly concerned about start up time. Similar for me, after all we removed the cli update check for that reason.

@FabianLars
Copy link
Member

oh and technically we sync plugins on patch versions at the moment. if we want the tool to only check minor then we need to make sure we don't have ipc breaking changes in patch releases (even if we consider it a fix). I don't mind either, we just need to agree on something and i guess document it somewhere.

@FabianLars
Copy link
Member

tldr: Tony is mostly concerned about start up time. Similar for me, after all we removed the cli update check for that reason.

Well, should have probably tested the PR first before that. At least from my testing this seems to be pretty much instant. Too fast to measure its impact x) Nice job! Let's wait for the critics ( @Legend-Master ) though.

@Legend-Master
Copy link
Contributor

Looks really good from a quick glance, offloading to a thread so we don't block startup and using rayon to parallelize the js package manager calls, I'll give it a try as well see if I notice the speed differences

@Legend-Master
Copy link
Contributor

Legend-Master commented Aug 13, 2025

After some testing, the bottle neck is at getting the javascript packages, npm, pnpm yarn, list all support querying multiple packages at once, so we can use it and remove rayon instead, current one takes around 9 seconds (100ms parsing Cargo.toml + Cargo.lock) when running inside the plugin-workspace (most extreme scenario with all official plugins)

I'll see if I could push a change here

Copy link
Contributor

github-actions bot commented Aug 13, 2025

Package Changes Through e66fbb3

There are 10 changes which include tauri with minor, tauri-cli with minor, @tauri-apps/cli with minor, tauri-utils with minor, tauri-bundler with minor, tauri-macos-sign with minor, tauri-runtime-wry with minor, tauri-runtime with minor, @tauri-apps/api with minor, tauri-plugin with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package current next
@tauri-apps/api 2.7.0 2.8.0
tauri-utils 2.6.0 2.7.0
tauri-macos-sign 2.1.0 2.2.0
tauri-bundler 2.5.2 2.6.0
tauri-runtime 2.7.1 2.8.0
tauri-runtime-wry 2.7.2 2.8.0
tauri-codegen 2.3.1 2.3.2
tauri-macros 2.3.2 2.3.3
tauri-plugin 2.3.1 2.4.0
tauri-build 2.3.1 2.3.2
tauri 2.7.0 2.8.0
@tauri-apps/cli 2.7.1 2.8.0
tauri-cli 2.7.1 2.8.0

Add another change file through the GitHub UI by following this link.


Read about change files or the docs at github.com/jbolda/covector

@Legend-Master
Copy link
Contributor

Legend-Master commented Aug 13, 2025

Pushed c6e63a0

I have tested this with npm and pnpm, and the time used reduced to <1s, I think this is acceptable now with it being on a separate thread

Edit: yarn needs special handling, it doesn't work right now added and tested

.and_then(|p| fs::read_to_string(p.join("Cargo.lock")).ok())
.and_then(|s| toml::from_str(&s).ok());

let know_plugins = helpers::plugins::known_plugins();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to also include @tauri-app/api here? And maybe also @tauri-app/cli

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well we do not have a good way to match those..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'd need to agree on whether to match the tauri package versions and which packages and patch or minor and then actually do that 🙃

sooner or later we'll probably have to tackle this.

Copy link
Contributor

@Legend-Master Legend-Master Aug 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tauri-app/api and tauri will need to match in minor versions at least

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

except that we failed with that multiple times (especially in v1 at the end). again, i'm not against it but if we add the check here we must start to take this serious.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think before we actually run the check, we should sync our versions for a while, otherwise we suddenly break most builds

let's sync tauri, api and cli
and maybe pin minors for inner dependencies too

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could at least add a check that checks the version of tauri and @tauri-app/api here?

}
}

pub fn current_package_versions(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably want to migrate the other ones to use this one as much as possible to speed things up, could push that to the future though

@FabianLars
Copy link
Member

With the intention being that we want to include tauri versions in the future as well we're a bit in a weird situation here because not checking the patch versions for plugins can be problematic since plugins are synced on the patch level. Some patch releases contained IPC sensitive changes.

We could take a step back and require patches to not make any ipc breaking changes (probably means that we mostly get js-only or rust-only PRs) but still keep syncing on patch releases anyway.

@Legend-Master
Copy link
Contributor

Legend-Master commented Aug 15, 2025

Personally, I think we should sync the versions for the tauri packages as well, like we're currently doing for the plugins, it is easier to understand, that if the versions exactly matches, it will definitely work (if you see the versions being different, your first reaction would be am I doing something wrong that they don't fully match? instead of knowing it's fine as long as they're on the same minor version)

For the check and IPC breaking changes though, I think we should keep them in minors only (except for cases where the last minor broke the IPC in some ways and it's for fixing that), so if people want (like if they rely on the window.__TAURI_INTERNALS__.invoke directly 1), they could pin the version range to minors (~ instead of ^)

Technically, if we do IPC breaking changes in tauri, plugin's global init script (api-iife.js) will break, in that case we should pin plugins' tauri version to a minor range, and release a new version on every tauri minor, the downsides being we'll need to release plugins a lot more frequently even with no code change at all (and if we don't sync the version of plugins with tauri, it could also be a bit hard to understand, but if we do sync them, we'll need to delay all the minor changes to be released with tauri)

Footnotes

  1. A reference of people might be doing it: https://github.com/tauri-apps/plugins-workspace/pull/2897#discussion_r2255624382

@lucasfernog
Copy link
Member Author

I agree with what you said overall.
But syncing tauri->plugins is a bit more complicated.. we can pull if off but it is harder to manage indeed, having to delay a particular plugin feature because tauri is not getting a minor release for a while..

@lucasfernog
Copy link
Member Author

can I merge this? I kinda want to release tauri soon

@Legend-Master
Copy link
Contributor

But syncing tauri->plugins is a bit more complicated.. we can pull if off but it is harder to manage indeed, having to delay a particular plugin feature because tauri is not getting a minor release for a while..

Yeah, same thoughts, we could leave this one for now

can I merge this? I kinda want to release tauri soon

Yeah sure, I just want to also add the tauri <-> @tauri-app/api check here, or maybe that could be for another day

@FabianLars
Copy link
Member

FabianLars commented Aug 16, 2025

having to delay a particular plugin feature because tauri is not getting a minor release for a while..

we pulled out the core stuff into plugins to get around exactly that lol

edit: i think i misunderstood what you said, just act like i'm not here :)

@Legend-Master
Copy link
Contributor

Legend-Master commented Aug 16, 2025

Yeah sure, I just want to also add the tauri <-> @tauri-app/api check here, or maybe that could be for another day

Added in cac22e4, and LOL, found out we got a mismatch in plugin-workspace while trying it 😂

if let Err(error) = check_mismatched_packages(frontend_dir(), tauri_path) {
log::error!("{error}");
if !ignore_version_mismatches {
std::process::exit(1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to stop the spawned processes (e.g. vite, cargo) though, feels like a pain to deal with 😂

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah right.. no easy way to deal with this unless we go with tokio tasks, easier to have graceful shutdown :/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's either that or get back to sync (which is ok imo, build isn't run as often - and let's not forget cargo takes 500s while our check takes just 1 😂 )

Copy link
Contributor

@Legend-Master Legend-Master Aug 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's either that or get back to sync (which is ok imo, build isn't run as often - and let's not forget cargo takes 500s while our check takes just 1 😂 )

Yeah, ~1 second is acceptable, let's use the sync version for now, sigh, I wish the cargo build doesn't take that long 😂

Just for the reference time with release build, it took around 500ms to check in plugins-workspace and ~700ms to check in my own project (with npm list taking up almost all the time) on my machine with an 11th gen i5 11400

I honestly don't know why those js package managers are so slow (maybe because the js file sizes are too big so parsing them could take a while?), pnpm --version takes 300-400ms, similar numbers for npm, with our cli, tauri --version takes only 20-50ms

Legend-Master
Legend-Master previously approved these changes Aug 17, 2025
@lucasfernog lucasfernog merged commit bc4afe7 into dev Aug 17, 2025
19 of 20 checks passed
@github-project-automation github-project-automation bot moved this from 📬Proposal to 🔎 In audit in Roadmap Aug 17, 2025
@lucasfernog lucasfernog deleted the feat/check-plugin-versions branch August 17, 2025 15:24
@oscartbeaumont
Copy link
Member

Thank you everyone for getting this through! So happy to know it's going to be much less likely anyone is going to end up in the same unfortunate position as us with a broken autoupdater in production caused by an cargo update.

magneticflux- added a commit to magneticflux-/nixpkgs that referenced this pull request Sep 1, 2025
After NixOS#438726 updated `tauri` to >=2.8.0, it now checks for mismatched versions (tauri-apps/tauri#13993). This was always a problem, it just wasn't checked until now. This patch bumps the NPM versions to match the newer Cargo versions.
magneticflux- added a commit to magneticflux-/nixpkgs that referenced this pull request Sep 2, 2025
After NixOS#438726 updated `tauri` to >=2.8.0, it now checks for mismatched versions (tauri-apps/tauri#13993). This was always a problem, it just wasn't checked until now. This patch bumps the NPM versions to match the newer Cargo versions.
magneticflux- added a commit to magneticflux-/nixpkgs that referenced this pull request Sep 2, 2025
After NixOS#438726 updated `tauri` to >=2.8.0, it now checks for mismatched versions (tauri-apps/tauri#13993). This was always a problem, it just wasn't checked until now. This patch bumps the NPM versions to match the newer Cargo versions.
magneticflux- added a commit to magneticflux-/nixpkgs that referenced this pull request Sep 2, 2025
After NixOS#438726 updated `tauri` to >=2.8.0, it now checks for mismatched versions (tauri-apps/tauri#13993). This was always a problem, it just wasn't checked until now. This patch bumps the NPM versions to match the newer Cargo versions.
magneticflux- added a commit to magneticflux-/nixpkgs that referenced this pull request Sep 2, 2025
After NixOS#438726 updated `tauri` to >=2.8.0, it now checks for mismatched versions (tauri-apps/tauri#13993). This was always a problem, it just wasn't checked until now. This patch bumps the NPM versions to match the newer Cargo versions.
alyssais pushed a commit to NixOS/nixpkgs that referenced this pull request Sep 6, 2025
After #438726 updated `tauri` to >=2.8.0, it now checks for mismatched versions (tauri-apps/tauri#13993). This was always a problem, it just wasn't checked until now. This patch bumps the NPM versions to match the newer Cargo versions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🔎 In audit
Development

Successfully merging this pull request may close these issues.

[feat] warn user about Rust and JavaScript version mismatch in CLI
4 participants