fix: don't ship global api bundle if withGlobalTauri is false

[Legend-Master]

Another effort to reduce bloat, we're currently shipping bundle.global.js (~40KB currently) no matter if it's used or not, this PR changes it to use our existing code plugin_global_api_scripts for the core plugins as well

Reference: #12820

[github-actions]

Package Changes Through 85ad03a

There are 12 changes which include tauri with minor, tauri-runtime with minor, tauri-runtime-wry with minor, tauri-utils with minor, tauri-cli with minor, @tauri-apps/cli with minor, @tauri-apps/api with minor, tauri-build with minor, tauri-plugin with minor, tauri-bundler with minor, tauri-codegen with minor, tauri-macros with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
@tauri-apps/api	2.3.0	2.4.0
tauri-utils	2.2.0	2.3.0
tauri-bundler	2.2.4	2.3.0
tauri-runtime	2.4.0	2.5.0
tauri-runtime-wry	2.4.1	2.5.0
tauri-codegen	2.0.5	2.1.0
tauri-macros	2.0.5	2.1.0
tauri-plugin	2.0.5	2.1.0
tauri-build	2.0.6	2.1.0
tauri	2.3.1	2.4.0
@tauri-apps/cli	2.3.1	2.4.0
tauri-cli	2.3.1	2.4.0

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[WSH032]

I remember that in 2.3, setting withGlobalTauri=True at build time and then setting withGlobalTauri=False at runtime could still disable the global JS API.
However, in 2.5, the runtime configuration no longer works. I think this is due to changes in crates/tauri/src/manager/webview.rs?

I want to upstream the runtime configuration context feature to Tauri, so I've started to pay attention to which configurations are compile-time and which are runtime.

[Legend-Master]

I remember that in 2.3, setting withGlobalTauri=True at build time and then setting withGlobalTauri=False at runtime could still disable the global JS API.

Yeah, I think so, but only for the ones in tauri not the plugins, this PR just combined the logic together so that they are now bundled together

[WSH032]

So in reality, was I just taking advantage of a "bug"?
Or, is Tauri willing to make withGlobalTauri configurable at runtime? If it affects the build and cannot be configured at runtime, I think it would make more sense to put it in BuildConfig.

[Legend-Master]

So in reality, was I just taking advantage of a "bug"?

I can't say if that was a bug or not to be honest since it can really be augured both ways

Or, is Tauri willing to make withGlobalTauri configurable at runtime?

I don't think that's a good idea, that means we'll have to ship the scripts no matter what

If it affects the build and cannot be configured at runtime, I think it would make more sense to put it in BuildConfig.

Since it affects what we inject to the app's code directly, I think it makes more sense to stay in app

Context::config_mut and all the Context related methods should ideally really only be used by the generate_context macro, and if you use it directly, you'll need to mimic the behavior of that macro

If all you want is to set it to false through Context::config_mut at runtime though, we can add a check to not injecting it

[WSH032]

My idea is to add a feature similar to dynamic-acl or a configuration like BuildConfig::remove_unused_commands to decide at compile time whether to ship the scripts. AppConfig::with_global_tauri would remain for deciding at runtime whether to actually inject the scripts.

My use case is to precompile Tauri as a dynamic library or executable, so that users don't need a Rust compiler.
Only BuildConfig and BundleConfig determine compile-time configuration and cannot be changed at runtime (i.e., modifying them at runtime has no effect).
identifier, AppConfig, and PluginConfig can be modified dynamically at runtime.

I'll create a PR to try implementing this feature. It's somewhat similar to:

impl Context {
    /// tauri_dir: absolute path to `src-tauri/`
    fn load_runtime_context(&mut self, tauri_dir: PathBuf);
}

fn load_runtime_config will load {tauri_dir}/tauri.conf.json and mimic the behavior of the generate_context macro. For example, loading the web page from disk according to BuildConfig::FrontendDist, loading and setting the global icon from disk according to BundleConfig::icon, and dynamically adding acl from {tauri_dir}/capabilities, etc.

This is somewhat similar to Python's initialization, where compile-time configuration is used by default, but some parts can be configured at runtime.

[Legend-Master]

Look at what we have in AppConfig, I changed my mind, maybe it makes more sense to be in BuildConfig 😂

I don't fully understand what exactly you want to do with generating contexts at runtime though, like do you want to ship the app with all the config and capability files? (or it's just easier for the pytauri to work without the help of tauri-build and generate_context macro in dev?)

[WSH032]

What I want is: I only ship a precompiled executable (or dynamic library), and users provide their own tauri.conf.json and capabilities files.
The executable will generate the corresponding Context based on the user-provided tauri.conf.json and capabilities, and then use this Context to initialize the Tauri App.

Not sure if I explained this clearly.

[WSH032]

Here is a practical usage example: https://github.com/pytauri/pytauri/tree/main/examples/tauri-app-wheel/python/src/tauri_app_wheel

The prebuilt binary is downloaded from PyPI, while the capabilities and Tauri.toml files are provided by the user at runtime. The script can dynamically generate the Context to drive the Tauri App, such as creating windows, setting permissions, and loading assets from disk (instead of using embedded assets).

Currently, I have hacked the Context to achieve this, which is quite fragile. So I'm wondering if this functionality could be upstreamed to Tauri (even as an unstable API).

[Legend-Master]

I see now, after skimming through the code, correctly me if I'm wrong though

So you're trying to mimic the generate_context, but because it's python, this would happen at runtime, and the generate_context you used in your code would be generating a barebone Context with the info in your repo's environment, and then you would modify that based on the user's code at runtime, and what you want is more or less that we provide a way to generate the Context struct in rust (which can be used directly by a rust function), instead of that macro that generates rust code (text)

[WSH032]

So you're trying to mimic the generate_context, but because it's python, this would happen at runtime, and the generate_context you used in your code would be generating a barebone Context with the info in your repo's environment, and then you would modify that based on the user's code at runtime

Exactly.

what you want is more or less that we provide a way to generate the Context struct in rust (which can be used directly by a rust function), instead of that macro that generates rust code (text)

There might be a slight difference from what I had in mind. If I understand correctly, it's impossible to avoid using macros entirely, because something always needs to be embedded (such as plugin_global_api_scripts and plist).
What I want right now is just a runtime api to patch the existing Context (which is generated at build time by generate_context). This api needs to mimic the behavior of generate_context (for example, setting the icon, providing assets, etc.).

I'll submit a PR later, as long as someone is available to review it.