fix(tauri-cli, tauri-build): copy external binaries only during bundling

[sftse]

Should fix #14602

I'm a bit unsure about moving things from the build script to the tauri-cli, since parts of the bundler were placed deliberately in the build script.

If possible, moving as much as possible from the build script into the tauri-cli could improve code comprehension.

[sftse]

It's not a particularly clean fix, just moving enough out of tauri-build and duplicating some code into tauri-cli.

[github-actions]

Package Changes Through 87dd595

There are 3 changes which include tauri-macos-sign with patch, tauri-bundler with patch, tauri-cli with patch

Planned Package Versions

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

package	current	next
tauri-macos-sign	2.3.1	2.3.2
tauri-bundler	2.7.4	2.7.5
@tauri-apps/cli	2.9.5	2.9.6
tauri-cli	2.9.5	2.9.6

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

---

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

[sftse]

This line was necessary because copy_binaries was in the build script. Moving it to the bundler will always refresh the binaries before bundling, which is fine unless they take a long time to copy.

[FabianLars]

If possible, moving as much as possible from the build script into the tauri-cli could improve code comprehension.

The build script does so much shit so that users can use eg cargo run directly so there's only so much we can remove without breaking that.

[sftse]

Is it currently possible to build a fully functional Tauri app without calling tauri build or tauri bundle?

[sftse]

I've tried before and simply running cargo run --bin <app> failed

[sftse]

Ok, so the helloworld example does run with just cargo, never mind then.. Must be something else preventing my other app from running.

[sftse]

This fix has been working for me so far, I guess this would hinge on whether it is expected that bundling only works with tauri-cli.

The only way to break even less workflows would be to copy the binaries as best possible, ignoring errors in tauri-build and then copy again with strict error checking in tauri-cli, but this seems even less pretty.

Thoughts?

[Legend-Master]

Does this change break tauri dev/cargo run for cases where you do have the externalBin available (it seems like it)? I think the build script used to provide you the externalBin files during development without running tauri bundle right?

[sftse]

That is a valid point and a use case which would be broken through this change. We could as said opt to be more conservative and ignore some types of errors (NotFound) when called from the build script.

If somebody is relying on wrong paths in externalBins being found at build time, he would then receive a more obscure error when running tauri dev.

[Legend-Master]

This is quite tricky, I'm not sure if ignoring error here is a good choice here either since you wouldn't notice the error until much later when your app or other things call it

[sftse]

I understand this is technically breaking, but to play devil's advocate, the externalBin configuration is under bundle, as if it was never intended to be checked at build time. The directory we're copying into is the cargo target directory, which would be unusual to try call binaries from.

Somebody doing this would need to distinguish whether their app is built in debug or release mode to reliably call the right binaries, is that possible?

[FabianLars]

i don't care about cargo build but cargo run must keep working. still, tauri is in a position where even these kind of breaking changes should be made carefully (including to consider waiting for v3). we're not some small hobby project and we're officially following semver.

[Legend-Master]

I am not sure if this is a good idea even without the breaking change, to me, I would expect the whole thing to just work when I run tauri dev or cargo run (cargo build and then running the binary manually in extend), even though we did a lot of things that were probably not intended to be done in build scripts, they indeed reduced friction (I really hated the experience having to use mach in servo, they basically semi-followed the build script guide lines and put those things in their CLI but I honestly hate it more than what we did)

About the fact that those settings are under bundle, it sure is kind of confusing but I don't know if there's a better name / put it in another field