It currently isn't possible to simply add a community plugin the same was as adding official plugins.
Trying to perform `npm run tauri add tauri-plugin-python` is trying to install npm package `@tauri-apps/plugin-python`.
But the npm scope `@tauri-apps/` is reserved for official tauri plugins.
The official documentation recommends to name the npm package `tauri-plugin-{name}-api` and it should be possible to have a parameter that makes it possible to install that package.
- closes#12217
This changes the command to check if the plugin is an official tauri plugin or not, using the appropriate npm package name format
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
Even though I couldn't even get the build to succeed when using the team name as the "developmentTeam" configuration (instead of the team ID), I've received reports that our processing of that value is broken and only works when it is escaped using `\"`.
* 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(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
* 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>
* 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
