You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When implementing workarounds like this that interface with Tauri dependencies like webview2, the app must be sure to depend on the same version of these crates as tauri itself. There is no good way that I know of to depend on the right version except to use cargo tree or look at the version in the resulting error message to know which version to depend on.
Should tauri reexport these so they can be used directly?
Reproduction
No response
Expected behavior
Crates like windows aren't depended on directly by apps as they can use them from the tauri namespace
I don't think we should re-export these because if you're reaching for these crates, you probably will also need to enable more features than what we enable internally, so you'll have to add it as a dependency in your Cargo.toml anyways.
Describe the bug
See the workaround in #7418 as an example .
When implementing workarounds like this that interface with Tauri dependencies like webview2, the app must be sure to depend on the same version of these crates as tauri itself. There is no good way that I know of to depend on the right version except to use
cargo tree
or look at the version in the resulting error message to know which version to depend on.Should tauri reexport these so they can be used directly?
Reproduction
No response
Expected behavior
Crates like
windows
aren't depended on directly by apps as they can use them from the tauri namespaceFull
tauri info
outputStack trace
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: