* fix(bundler): keep NSIS and WiX out of System32 when bundling as SYSTEM
When the cache dir is inside the Windows system directory, as it is for the SYSTEM account, WOW64 redirects the 32-bit NSIS and WiX executables to SysWOW64 and makensis fails with "Unable to start child process, error 0x2". Store the tools in the project output directory in that case.
* fix(bundler): fail clearly when the tools dir is still inside System32
The fallback to the project output directory doesn't help when the project or its target directory is itself inside the Windows system directory, for example a Jenkins workspace under the SYSTEM profile, and neither does `useLocalToolsDir`. NSIS and WiX would then fail with the same `error 0x2`, after a warning claiming the tools were moved somewhere safe. Check the final tools directory and return an error that explains the redirection instead.
* docs(config): describe where tools go for the SYSTEM account
The `useLocalToolsDir` docs still said tools are always cached in the user's cache directory when it's disabled and recommended enabling it for the Windows SYSTEM user because that directory is "restricted". Explain the WOW64 redirection, the new fallback to the build output directory, and what enabling the option still gains.
* fix(bundler): log the SYSTEM tools dir warning once
The NSIS and MSI bundlers, and their updater variants, each resolve the tools directory, so a single build printed the same warning up to four times. The warning also said `useLocalToolsDir` only silences it, while it actually moves the tools to `target/.tauri`, shared across build profiles and targets.
* docs(bundler): only NSIS caches WebView2 installers in the tools dir
The MSI bundler downloads the WebView2 installers into its own output directory, not into the tools directory.
* fix(bundler): don't move the tools for a 32-bit x86 CLI
`processor_architecture()` reports the native architecture, so a 32-bit x86 CLI on 64-bit Windows moved the tools out of the system profile cache, although it is redirected exactly like NSIS and WiX and the cache already worked for it. Check the build's own architecture instead.
* fix(bundler): don't panic when there's no cache dir for the tools
Now that there is a fallback directory for the NSIS and WiX tools, use it instead of panicking when the cache directory can't be determined, like the AppImage bundler already does for linuxdeploy.
* refactor(bundler): rename tauri_tools_path to tools_directory
The NSIS and MSI bundlers bind the result to a local tauri_tools_path, and build_nsis_app_installer takes a tauri_tools_path parameter, both shadowing the helper of the same name.
* test(bundler): cover the tools directory selection
The tests only covered the path prefix check and the system directory lookup. Split the selection into a function that takes the local tools, cache, project output and system directories, and test the precedence, both fallbacks and the System32 error.
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* fix(api): type check dev tooling configs
* `@rollup/plugin-typescript` doesn't support this
of course something breaks... https://github.com/rollup/plugins/issues/1755
* clean up pnpm workspace config
* add notes on the node types
* prettier
The Linux button-press and touch handlers assumed the widget hierarchy webview -> GtkBox -> GtkWindow and unwrapped a downcast of the webview's second ancestor. Embedding applications that reparent the webview into another container (e.g. a GtkPaned) panic the main thread on the first click. Resolve the webview's toplevel window instead - identical behavior for the stock hierarchy, correct at any nesting depth.
Co-authored-by: Avi <aviynw6@gmail.com>
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
Cargo treats a file listed in a crate's dep-info as changed if it was
modified after the compilation started. generate_context! writes the
frontend assets, icon data and macOS Info.plist to OUT_DIR during the
compilation and embeds them with include_bytes!, so the first unchanged
build after one that wrote such a file recompiled the app crate.
Set their modification time to 2000-01-01 UTC, a date FAT and exFAT can
store. Each file name is a checksum of the data the file was generated
from, so the time isn't needed to tell versions apart. Errors are
ignored; at worst the next build recompiles the crate as before.
Closes#16318
Cargo treats a missing `rerun-if-changed` path as changed, so an app that
lists its capabilities in `app > security > capabilities` and has no
`capabilities` directory re-ran the build script and recompiled on every
build. A non-empty list only selects the capability files it references by
identifier, so creating the directory alone can't change the selection.
Keep the watch for an empty list, where every file in the directory is
selected.
Closes#16319
* fix(macos-sign): delete the temporary keychain when setup fails
Keychain::with_certificate_file returned early on any failure after
create-keychain, before Keychain (and its Drop) existed, leaving a random
.keychain-db in ~/Library/Keychains and possibly in the search list.
* Update crates/tauri-macos-sign/src/keychain.rs
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
---------
Co-authored-by: Fabian-Lars <30730186+FabianLars@users.noreply.github.com>
Amr Bashir