* fix(cli): Statically compile msvc runtime
fixes https://github.com/tauri-apps/tauri/issues/11642
ref https://github.com/swc-project/swc/pull/7965
i only added it for x64 for now but we should monitor x32 (swc removed it for this one again) and aarch64 (swc never added it).
x32 is fairly rare as a dev system and aarch64 didn't seem much testing in general (as a dev system) so i'd prefer to wait and see if it's needed.
note that i don't know if any other tooling (rust etc) need the dyn runtime so that's also something to monitor
* 32bit and arm64
closes#11614
Remove UNC manually, instead of `dunce::simplified` because `path` could have `*` in it and that's not allowed on Windows and `dunce::simplified` will check that and return `path` as is without simplification resulting in a missing pattern in scope
for the scope pattern `\\?\C:\path\to\dir\**`, we expect the scope to have:
- `\\?\C:\path\to\dir\**`
- `C:\path\to\dir\**`
but if we use `dunce::simplified`, it will see `**` as invalid path component on Windows and will not simplify the path resulting in a scope that only has `\\?\C:\path\to\dir\**`
* On Windows, set name of Window Class, closes#7498
allow to customize it instead of current value hard coded "Window Class"
* feat(windows): add window_classname, closes#7498
allow to customize the window class name instead of current value hard coded "Window Class"
* feat: add window_classname, closes#7498
* add changes file
* Update core/tauri-config-schema/schema.json
* Update tooling/cli/schema.json
* missing pieces after merge
* clippy
---------
Co-authored-by: Géraud-Loup <47665233+geraudloup@users.noreply.github.com>
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* enhance(core): use `diagnostic::on_unimplemented` on rustc 1.78 and newer for async commands with references
* change file
* clippy
* clippy
* add TODO
* Fix mixup of `env_tauri_app_path()` and `env_tauri_frontend_path()` in tauri's path resolutions
* Rename functions in `app_paths` to match their corresponding, publicly exposed env var keys
* Rename `app_dir`/`app_path` variables that deal with the frontend app's directory to `frontend_dir
* Rename `APP_DIR` to `FRONTEND_DIR`
* Improve comment on meaning of tauri path env vars
* fix(api/menu): fix submenus when created using an object in `items` field in the object passed to `Menu/Submenu.new`
closes#11435
also closes#11422 as I included the docs in this PR
* Update .changes/js-submenu-in-options.md
* Update packages/api/src/menu/base.ts
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
* chore(deps) Update Rust crate image to v0.25.4
* Also bump json-patch and resvg
* Just json-patch for now
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Tony <legendmastertony@gmail.com>
* fix(runtime-wry): run `cursor_position` getter on main thread
closes#10340
* clippy
* clippy
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* feat(core): add WebviewWindow::resolve_command_scope
This new functionality exposes the `CommandScope` resolution as a function (currently only commands can resolve them as a dependency injection via CommandItem)
This function is useful to validate the configuration at runtime (do some asserts at setup phase to ensure capabilities are properly configured) and to resolve scopes in a separate thread or context
* adjust return type
this changes the resource plugin close() API to fallback to the parent window and AppHandle resource tables, letting the JS to delete global resources.
The need for this was brought up on https://github.com/tauri-apps/plugins-workspace/pull/1860#issuecomment-2419175001
the store plugin stores the resources in the AppHandle, and we want the existing close() API to work on global resources otherwise every consumer needs their own resource close commands
* feat(cli): add support for providing custom app/src paths to tauri's CLI via optional env vars
* fix tests
* rename env vars (app vs src is confusing)
* add change file
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* Warn that android is not supported
* Warn that Android is not supported.
* Update crates/tauri/src/ipc/mod.rs
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
the audit failed, so the 2.0.2 release is failing. I'm also adding the latest merged change to the 2.0.2 release in this change so we're in sync in the changelog.
* fix(bundler): wrap `Exec` in desktop with quotes, rename appimage main binary if has spaces
* Update .changes/main-binary-name-spaces-linux.md [skip ci[
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
custom IPC systems that manually call Webview::on_message must know the invoke key checked by Tauri. This exposes that key in the App/AppHandle instances.
This is safe because the key is never leaked to remote denied webview URLs
* chore: promote to v2 stable
- deletes all RC change files
- adds a new change file to promote all packages to v2 stable
- manually fix the tauri-driver, tauri-macos-sign, tauri-bundler versions so the next covector bump will move them to 2.0.0
- manually patch the metadata-v2.json file so the next covector update will mark all packages as 2.0.0
* ignore audit vuln without fixes
* bump msrv to 1.78
* run covector version
* fix sync lockfile covector
* #[allow(clippy::manual_inspect)]
* feat(cli): enhance Android dev port forwarding, closes#11137
this changes the `android dev` port forwarding (that is actually handled by the `android-studio-script` command - triggered by our Gradle plugin) with some enhancements:
- make the whole process more resilient by checking if the port was actually forwarded and rerunning the `adb reverse` command until it tells us the forward is ready
- if the `adb devices` list is empty, retry a few times (waiting a few seconds) to tolerate devices being booted - slows down "raw builds" (Build Project Android Studio menu for instance) that shouldn't happen often anyway - if you're running `android dev` you're usually running the app on a device instead of simply testing builds
* use host IP to run on android physical device
* fix(cli): iOS app signature not retaining entitlements, closes#11089
The IPA does not retain the entitlements as a regression from #10854 which removed the signing step from the build() and archive(), deferring to the export() call
To retain the entitlements we need to force sign one of the files in the app bundle. The most reliable way to do this is to use a self signed certificate as a dummy signature - it is replaced by the export() call so we do not rely on any user provided certificate
Additionally the export options are incorrectly configuring a manual signing, preventing Xcode from properly managing provisioning profiles, which is also part of the fix
* fix header
* Detect ARM gnueabi as soft-float (armel)
Detect ARM gnueabi as soft-float (armel) instead of hard-float (armhf).
Also change the signature of `tauri_bundler::bundle::Settings::binary_arch`
to return an enum instead of a `&str`.
* Update .changes/bundler-gnueabi-armel.md
* fix dmg
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
Co-authored-by: Lucas Nogueira <lucas@tauri.studio>
* fix(core): share webcontext between webviews
closes#10981
* update wry version
* Update crates/tauri-runtime-wry/src/lib.rs [skip ci]
* on linux, only register protocol once per context
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
Co-authored-by: Lucas Nogueira <lucas@tauri.studio>
* feat: add `upgradeCode` config option
* fix build on other platforms
* Update crates/tauri-bundler/src/bundle/settings.rs [skip ci]
* move to subcommand, use same product name fallback as the bundler
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
This PR groups files in a predictable mannar, so instead of
```
windows/
|_ templates
|_ main.wxs
|_ installer.nsi
|_ nsis.rs
|_ msi.rs
```
we group them next to each other
```
windows/
|_ msi
|_ main.wxs
|_ mod.rs
|_ nsis
|_ installer.nsi
|_ mod.rs
```
* Migrate from objc/cocoa to objc2
* Update crates/tauri-runtime-wry/src/webview.rs
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
* feat(cli): add log plugin to the app template
The log plugin is really important for mobile development - without it you don't have a clue about logs and stdout for iOS apps
* patch tauri dep for local testing
* clippy
the checkPermissions command is also a PermissionCallback, and the annotation check is incorrectly ignoring that fact, so the requestPermissions is never resolved for the geolocation plugin
* remove dbg! in resources test
* use methods from `fs` and `env` qualified
* share `ACL_MANIFESTS_FILE_NAME` and `CAPABILITIES_FILE_NAME` consts across crates
* simplifiy `Manifest::new` code for better readability
* move reading global api scripts logic next to the function that defines it
* [tauri-build] move acl logic from lib.rs to acl.rs
* use const value for schema instead of enum value with a single variant
* remove unnecessary info from permissions hover
* move related functions next to each other & improve readability of others
* use methods from `fs` and `env` qualified
* fix warning, unused return in test
* document some functions
* improve generated schema for better scope schema completion, simplify, reorganize and document the logic
previously if you had `fs` and `http` plugins added in a project
and then try to write an extended permission for `fs:allow-app-meta`
```json
{
"identifier": "fs:allow-app-meta",
"allow": [ <here> ]
}
```
and even though identifier is from `fs` plugin,
the JSON schema suggests `path` and `url`.
Now it will only suggest relevant field which is `path`
* resolve permissions from other plugins, generate `core:default` as a normal set instead of special logic
* move `PERMISSION_SCHEMAS_FOLDER_NAME` to acl module
* use gneric trait because of MSRV
* ensure `gen/schemas` dir is created
* clippy
* fix(core): Use productName for FileDescription
fixes#10968fixes#10890
* just unwrap since winres will panic anyway or use the cargo.toml description which we don't want
* regen
* nsis
The upgrade code generation was changed due to an accidental regression in #9375. Previously `UpgradeCode` was calculated using the main binary name which was `<product_name>.exe`, but #9375 changed the default main binary name to `<cargo-crate-name>.exe` and thus a different UpgradeCode was generetad.
This PR reverts this change to use product name for `UpgradeCode` generation.
* refactor(core): change `Assets::iter` item to use `Cow`
make the iterator more flexible to support Assets implementations that do not rely on static assets
* fix test?
* lint
* lint
* clippy again
having duplicate capability identifier lead to unexpected behavior because one of the capabilities gets ignored.
With this change the build script now fails when this happens.
- the Xcode project now uses a fixed output library name, which means changes to the Cargo.toml lib name won't affect it (backwards compatible change, we're checking if this new format is being used or not by reading the project.pbxproj)
- sync config identifier with the pbxproj
- sync development team config with the pbxproj
the sync runs both on dev and on build
Co-authored-by: Amr Bashir <amr.bashir2015@gmail.com>
* chore: add root taurignore
enhances the DX of running `tauri dev` in any of the examples folder - we don't need to watch the entire workspace for changes
* extend ignore list
The example for the `setSize()` method in the documentation wrongly imports `getCurrent` (I believe as was in tauri v1)
instead of `getCurrentWebview`.
* generate `Context` inside a thread
fix#9882
this is a workaround for #9882 due to windows having a small
stack size for the main thread (1MiB) versus other platforms which
have 8MiB. the true fix would be to lower the generated code
stack size, but with lots a plugins, there are lots of ACL
configurations.
* add change file [skip ci]
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.studio>
* feat(cli/info): include plugins info
closes#10682
* header
* resolve package manager once
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.studio>
* chore: cleanup unnecessary scripts and files
- Removed `.cargo/config` and `__TAURI_WORKSPACE__` workaround
- Removed husky and precommit hooks
- Remove unecessary script files
- Moved `.scripts/covector/sync-cli-metadata.js` to `.scripts/ci/sync-cli-metadata.js`
- Moved `app-icon.png` to `.github/icon.png`
- Enhanced has-diff.sh script to output which files are modified
* lock file
* bring back __TAURI_WORKSPACE__
* add change file
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.studio>
changes the CLI `add` command to match the CLI major and pre requirements for known plugins
this is required because right now adding the deep-link plugin installs the v1 plugin (latest version known by cargo as the v2 is still in RC), even though we're running the v2 CLI
* feat(core): enhance IPC permission error message
- include more information about current URL and allowed origins
- enhance formatting of the error message
* plugin not found & command not found
* lint
I noticed the plugin build fails on older Swift (tested on macOS 12) because the default minimum required macOS version (10.10 in my case) is older than `v10_13` which is set by the Tauri iOS package (and also swift-rs).
So the plugins must explicitly define a minimum macOS version too.
* fix(android): avoid rebuilds if nothing changed
Unconditionally overwriting files where the build reruns if they changed
leads to rebuilds every time.
Only overwrite a file if its content is different to not rebuild in such
a case.
* use write_if_changed utils
* use existing function
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* feat(ios): add a new cli option to dev to use project archs
Add a new option to instruct cargo-mobile2 to use architectures configured in the project for building
* update cargo-mobile2, add change file
* fix change file [skip ci]
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* skip pack in publish, use check fetch
* remove script
* remove apt, exists in main pipeline
* CLI doesn't need separate check
* no assets for tauri-cli
Update gradle to 8.9 and the gradle android plugin to 8.5.1 in the android templates (requires latest Android Studio). This should add support for Java 21 but Java 17 keeps being the recommended version.
CLI commands will now consistently search for the `app_dir` (the directory containing `package.json`) from the current working directory of the command invocation.
Core plugin permissions are now prefixed with `core:`, the `core:default` permission set can now be used and the `core` plugin name is reserved.
The `tauri migrate` tool will automate the migration process, which involves prefixing all `app`, `event`, `image`, `menu`, `path`, `resources`, `tray`, `webview` and `window` permissions with `core:`.
Fixed an issue where configuration parsing errors always displayed 'tauri.conf.json' as the file path, even when using 'Tauri.toml' or 'tauri.conf.json5'.
The error messages now correctly shows the actual config file being used.
Infer macOS codesign identity from the `APPLE_CERTIFICATE` environment variable when provided, meaning the identity no longer needs to be provided when signing on CI using that option. If the imported certificate name does not match a provided signingIdentity configuration, an error is returned.
Fix `ResourcePaths` iterator returning an unexpected result for mapped resources, for example `"../resources/user.json": "resources/user.json"` generates this resource `resources/user.json/user.json` where it should generate just `resources/user.json`.
@@ -37,9 +37,12 @@ Hi! We, the maintainers, are really excited that you are interested in contribut
- Provide convincing reason to add this feature. Ideally you should open a suggestion issue first and have it greenlighted before working on it.
- If fixing a bug:
- If you are resolving a special issue, add `(fix: #xxxx[,#xxx])` (#xxxx is the issue id) in your PR title for a better release log, e.g. `fix: update entities encoding/decoding (fix #3899)`.
- Provide detailed description of the bug in the PR, or link to an issue that does.
- If the PR is meant to be released, follow the instructions in `.changes/readme.md` to log your changes. ie. [readme.md](https://github.com/tauri-apps/tauri/blob/dev/.changes/README.md)
## Development Guide
**NOTE: If you have any question don't hesitate to ask in our Discord server. We try to keep this guide to up guide, but if something doesn't work let us know.**
@@ -48,7 +51,7 @@ Hi! We, the maintainers, are really excited that you are interested in contribut
First, [join our Discord server](https://discord.gg/SpmNs4S) and let us know that you want to contribute. This way we can point you in the right direction and help ensure your contribution will be as helpful as possible.
To set up your machine for development, follow the [Tauri setup guide](https://tauri.app/v1/guides/getting-started/prerequisites/) to get all the tools you need to develop Tauri apps. The only additional tool you may need is [PNPM](https://pnpm.io/), it is only required if you are developing the Node CLI or API packages (`tooling/cli/node` and `tooling/api`). Next, fork and clone this repo. It is structured as a monorepo, which means that all the various Tauri packages are under the same repository. The development process varies depending on what part of Tauri you are contributing to, see the guides below for per-package instructions.
To set up your machine for development, follow the [Tauri setup guide](https://v2.tauri.app/start/prerequisites/) to get all the tools you need to develop Tauri apps. The only additional tool you may need is [PNPM](https://pnpm.io/), it is only required if you are developing the Node CLI or API packages (`packages/cli` and `packages/api`). Next, fork and clone this repo. It is structured as a monorepo, which means that all the various Tauri packages are under the same repository. The development process varies depending on what part of Tauri you are contributing to, see the guides below for per-package instructions.
Some Tauri packages will be automatically built when running one of the examples. Others, however, will need to be built beforehand. To build these automatically, run the `.scripts/setup.sh` (Linux and macOS) or `.scripts/setup.ps1` (Windows) script. This will install the Rust and Node.js CLI and build the JS API. After that, you should be able to run all the examples. Note that the setup script should be executed from the root folder of the repository in order to run correctly.
@@ -58,15 +61,15 @@ See [Architecture](../ARCHITECTURE.md#major-components) for an overview of the p
### Developing Tauri Bundler and Rust CLI
The code for the bundler is located in `[Tauri repo root]/tooling/bundler`, and the code for the Rust CLI is located in `[Tauri repo root]/tooling/cli`. If you are using your local copy of `@tauri-apps/cli` (see above), any changes you make to the bundler and CLI will be automatically built and applied when running the build or dev command. Otherwise, running `cargo install --path .` in the Rust CLI directory will allow you to run `cargo tauri build` and `cargo tauri dev` anywhere, using the updated copy of the bundler and cli. You will have to run this command each time you make a change in either package.
The code for the bundler is located in `[Tauri repo root]/crates/tauri-bundler`, and the code for the Rust CLI is located in `[Tauri repo root]/crates/tauri-cli`. If you are using your local copy of `@tauri-apps/cli` (see above), any changes you make to the bundler and CLI will be automatically built and applied when running the build or dev command. Otherwise, running `cargo install --path .` in the Rust CLI directory will allow you to run `cargo tauri build` and `cargo tauri dev` anywhere, using the updated copy of the bundler and cli. You will have to run this command each time you make a change in either package.
### Developing The Node.js CLI (`@tauri-apps/cli`)
`@tauri-apps/cli` is a wrapper to `tauri-cli` so most changes should be written on the Rust CLI. The `[Tauri repo root]/tooling/cli/node` folder contains only packaging scripts to properly publish the Rust CLI binaries to NPM.
`@tauri-apps/cli` is a wrapper to `tauri-cli` so most changes should be written on the Rust CLI. The `[Tauri repo root]/crates/tauri-cli` folder contains only packaging scripts to properly publish the Rust CLI binaries to NPM.
### Developing Tauri Core and Related Components (Rust API, Macros, Codegen, and Utils)
The code for the Rust crates, including the Core, Macros, Utils, WRY runtime, and a few more are located in `[Tauri repo root]/core/tauri-(macros/utils)`. The easiest way to test your changes is to use the `[Tauri repo root]/examples/helloworld` app. It automatically rebuilds and uses your local copy of the Tauri core packages. Just run `cargo run --example helloworld` after making changes to test them out.
The code for the Rust crates, including the Core, Macros, Utils, WRY runtime, and a few more are located in `[Tauri repo root]/crates/tauri-(macros/utils)`. The easiest way to test your changes is to use the `[Tauri repo root]/examples/helloworld` app. It automatically rebuilds and uses your local copy of the Tauri core packages. Just run `cargo run --example helloworld` after making changes to test them out.
The JS API provides bindings between the developer's JS in the Webview and the builtin Tauri APIs, written in Rust. Its code is located in `[Tauri repo root]/tooling/api`. After making changes to the code, run `pnpm build` to build it. To test your changes, we recommend using the API example app, located in `[Tauri repo root]/examples/api`. It will automatically use your local copy of the JS API and provides a helpful UI to test the various commands.
The JS API provides bindings between the developer's JS in the Webview and the builtin Tauri APIs, written in Rust. Its code is located in `[Tauri repo root]/packages/api`. After making changes to the code, run `pnpm build` to build it. To test your changes, we recommend using the API example app, located in `[Tauri repo root]/examples/api`. It will automatically use your local copy of the JS API and provides a helpful UI to test the various commands.
This handbook contains information about our release pipeline and how to deal with common issues.
This document is mainly intended for team members responsible for maintaining the project.
- [Covector](#covector)
- [Version Pull Request](#version-pull-request)
- [Releasing and Publishing](#releasing-and-publishing)
- [Publishing failed, what to do?](#publishing-failed-what-to-do)
## Covector
We use [`covector`](https://github.com/jbolda/covector) to manage our version bumps and release pipeline.
It can be configured in [`.changes/config.json`](../.changes/config.json) which includes how each package should be published step by step.
Some packages can't be published directly using `covector` as it requires to be built on a matrix of platforms
such as `tauri-cli` prebuilt binaries which is published using [publish-cli-rs.yml](./workflows/publish-cli-rs.yml)
and `@tauri-apps/cli` native Node.js modules which is published using using [publish-cli-js.yml](./workflows/publish-cli-js.yml)
both of which are triggered after `covector` has created a github release for both of them, see `Trigger @tauri-apps/cli publishing workflow`
and `Trigger tauri-cli publishing workflow` steps in [covector-version-or-publish.yml](./workflows/covector-version-or-publish.yml)
## Version Pull Request
On each pull request merged, [covector-version-or-publish.yml](./workflows/covector-version-or-publish.yml) workflow will run, and:
When there're change files inside `.changes` folder and they're not all included in `pre.json` (usually this is only when we are in `-alpha` to `-rc` phase), it will open/update an `Apply Version Updates From Current Changes` PR (https://github.com/tauri-apps/tauri/pull/11029 for example) that bumps all packages based on current existing change files and generate `CHANGELOG.md` entries. see `Create Pull Request With Versions Bumped` step in [covector-version-or-publish.yml](./workflows/covector-version-or-publish.yml).
Otherwise, covector will start to publish packages configured in [`.changes/config.json`](../.changes/config.json).
## Releasing and Publishing
Releasing can be as easy as merging the version pull request but here is a checklist to follow:
- [ ] Double check that every package is bumped correctly and there are no accidental major or minor being released unless that is indeed the intention.
- [ ] Make sure that there are no pending or unfinished [covector-version-or-publish.yml](./workflows/covector-version-or-publish.yml) workflow runs.
- [ ] Sign the Version PR before merging as we require signed commits
- [ ]`git fetch --all`
- [ ]`git checkout release/version-updates`
- [ ]`git commit --amend -S`
- [ ]`git push --force`
- [ ] Approve and merge the version pull request
## Publishing failed, what to do?
It is possible and due to many factors that one or many packages release can fail to release, there is no reason to panic, we can fix this.
Did all of the packages fail to release?
- yes?
- [ ]`git checkout -b revert-branch`
- [ ]`git revert HEAD~1`
- no?
- [ ]`git checkout -b revert-branch`
- [ ]`git revert HEAD~1 --no-commit`
- [ ] Edit the commit and revert only changes related to packages that failed to publish
- [ ]`git revert --continue`
Then:
- [ ] Make a pull request with reverted changes, get it approved and merged
- [ ] Fix the issue that caused releases to fail in another PR, get it approved and merged
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
