[bug] tauri build modifies Cargo.toml?

[ReactorScram]

Describe the bug

Running stat src-tauri/Cargo.toml && pnpm tauri build --bundles none > /dev/null 2> /dev/null && stat src-tauri/Cargo.toml

I see the mtime for my Cargo.toml changes after pnpm tauri build. If I do the same with only cargo build --release, the mtime doesn't change, so I think it must be in Tauri.

My beforeDevCommand and beforeBuildCommand are empty strings, so I don't think anything else in my build pipeline should be modifying the Cargo.toml manifest.

Reproduction

I can go back and make a repro repository, I'm just curious if this is intended behavior and if there's anything I can do to disable it.

Expected behavior

I expect Cargo.toml to not change during the build process.
I'm trying to embed the Git version in my final exe and for some possibly Windows-specific reason, this modification is causing the Git version to show up as dirty / modified

Full tauri info output

[✔] Environment
    - OS: Windows 10.0.22621 X64
    ✔ WebView2: 120.0.2210.144
    ✔ MSVC:
        - Visual Studio Build Tools 2019
        - Visual Studio Community 2022
    ✔ rustc: 1.75.0 (82e1608df 2023-12-21)
    ✔ cargo: 1.75.0 (1d8b05cdd 2023-11-20)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: 1.75.0-x86_64-pc-windows-msvc (overridden by 'C:\cygwin64\home\User\projects\firezone\rust\rust-toolchain.toml')
    - node: 20.10.0
    - pnpm: 8.14.3
    - npm: 10.2.3

[-] Packages
    - tauri [RUST]: 1.5.4
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.5
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.9

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../src
    - devPath: ../src

Stack trace

N/A

Additional context

I searched in issues and docs but of course "Cargo.toml" and even "manifest" returned a lot of false positives, so maybe I missed something.

[ReactorScram]

I think it might be for this feature injection thing:

tauri/tooling/cli/src/interface/rust/manifest.rs

Lines 299 to 310 in 00e1567

	let persist = inject_features(&mut manifest, &mut dependencies)?;
	let tauri_features = dependencies
	.into_iter()
	.find(|d| d.name == "tauri")
	.unwrap()
	.features;
	if persist {
	let mut manifest_file =
	File::create(&manifest_path).with_context(|| "failed to open Cargo.toml for rewrite")?;
	manifest_file.write_all(

[FabianLars]

yep, that's it. You can disable it by using workspace inheritance for the tauri dependency as a workaround.
We should add a check for this though, i think we have that for the plist files too already.

[ReactorScram]

For the Tauri dep itself, e.g. tauri = { workspace = true }?

For anyone else who runs into this, it ultimately turned out to be a problem with line endings, which I solved (assuming the PR is merged) by adding a .gitattributes file with * -text: https://github.com/firezone/firezone/pull/3432/files

I still don't love rewriting Cargo.toml, but the rewrite was actually correct, it's just that Github had it out on our Windows runner as CRLF and then the toml_edit crate must have rewritten it as LF.

I wish CRLF would just disappear, I'm pretty sure modern Windows tools all handle LF just fine :/

[FabianLars]

For the Tauri dep itself, e.g. tauri = { workspace = true }?

yup

Okay, the check would probably fail on line endings (or maybe we have that check already and this is exactly what's happening 🤔)

I wish CRLF would just disappear, I'm pretty sure modern Windows tools all handle LF just fine :/

Same :(

[ReactorScram]

Nah I didn't have workspace set up, so your check might be okay.

It's just that toml_edit doesn't guarantee byte-for-byte roundtripping. Sometimes it re-orders keys too it seems, known issue - toml-rs/toml#163 (Although if that was the only problem, and if it was deterministic, I'd just check in the correct order on my dev system)

Anyway here's a repro case where it doesn't round-trip carriage returns https://github.com/ReactorScram/toml_edit_repro/blob/b348a5bbc9ae64b43e4ae82ffbab1fda35f68ca2/src/main.rs#L3

[CrendKing]

The rewriting Cargo.toml with LF on Windows is annoying. Is there a way to disable the rewriting feature?

[FabianLars]

#8711 (comment)

[CrendKing]

In my Cargo.toml, I have the following:

[build-dependencies]
tauri-build = { version = '2.0.0-beta', default-features = false, features = ['codegen', 'config-toml'] }

[workspace.dependencies]
tauri = { version = '2.0.0-beta', default-features = false, features = ['protocol-asset'] }

[dependencies]
tauri = { workspace = true }

When build, it is still changing the file to LF. Did I miss something?

[FabianLars]

maybe try the same with tauri-build 🤔

[ReactorScram]

Having this similar issue now: firezone/firezone#6597

I'd like to use the notification feature on Linux but disable it on Windows, since I use tauri-winrt-notification there.

Is that possible?