* docs: clarify Capability::windows/webviews OR nature
It is intuitive to expect that for the capability to be enabled,
_both_ the window label and the webview label have to match.
However, this is not the case: the capability is enabled
if _either_ the window label matches a pattern
in `Capability::windows` _or_ the webview label matches a pattern
in `Capability::webviews`.
This commit should somewhat clarify this oddity
and protect developers from adding excessive permissions.
For reference, `Capability::webviews` was added in
0cb0a15ce2
(https://github.com/tauri-apps/tauri/pull/8789).
* Apply suggestions from code review
Co-authored-by: Amr Bashir <github@amrbashir.me>
* update schemas
---------
Co-authored-by: Amr Bashir <github@amrbashir.me>
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* Add a new option to remove unused commands
* Fix compile
* Add markers to all core plugins
* Clippy
* Add allow unused when running with this
* Use build script to generate allowed-commands.json
* Clean up and add proper reruns
* Wrong path
* Revert to #[cfg_attr(not(debug_assertions), allow(unused))]
* Add change files
* Some more docs
* Add version requirement note
* Avoid rerun if no capabilities folder
* Remove unused box
* small cleanup
* fix channel
* implement for app handler too
* rely on core:default for channel perms
* Move this feature to config
* Docs change
* Forget one last remove_unused_commands
* Remove removeUnusedCommands from helloworld
* tell handler that the app ACL manifest exists
* update change file
* update doc
* update change file
* Use a struct to pass the data instead of env var
* Clippy
* Fix can't exclude inlined plugins on Windows
due to UNC paths...
* Apply suggestion from code review
* Remove remove on empty to tauri-build
* Revert "Remove remove on empty to tauri-build"
This reverts commit b727dd621e.
* Centralize remove_file(allowed_commands_file_path)
* Escape glob pattern
* update change file
* remove unused commands for dev too
* Update crates/tauri-utils/src/config.rs
Co-authored-by: Fabian-Lars <github@fabianlars.de>
* regen schema
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
Co-authored-by: Fabian-Lars <github@fabianlars.de>
* moving to macbook
* that was so weird to implement
* rm patch
* Discard changes to Cargo.lock
* Create change-pr-12366.md
* add missing builder fn
* remove test
* split change files
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* feat(cli): allow merging multiple configuration values
Currently the dev/build/bundle commands can only merge a single Tauri configuration value (file or raw JSON string), which imposes a limitation in scenarios where you need more flexibility (like multiple app flavors and environments). This changes the config CLI option to allow multiple values, letting you merge multiple Tauri config files with the main one.
* fix ios build
* feat: add `WebviewBuilder.disable_javascript` and `WebviewWindowBuilder.disable_javascript`
* wry 0.50.3
* add missing config options and API types
* add change file for api
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
* chore(deps): Update windows to 0.59. Update webview2-com to 0.35
* wry and other crates and objc2
* window-vibrancy 0.6
* Update windows059-webview035.md
* win compile error
* tao
* tao 0.32.1
* updatus maximus
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
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>
