Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Without --release, no wasm-opt is performed, despite custom profiles. #933

Open
simbleau opened this issue Jan 5, 2025 · 2 comments
Open

Comments

@simbleau
Copy link
Member

simbleau commented Jan 5, 2025

As discovered in #605,

Using a --cargo-profile which inherits from release does no wasm-optimization.

This is because the release flag has many opinions that shadow a custom profile, primarily around wasm optimization.

Example 1:

        let wasm_opt = attrs
            .get("data-wasm-opt")
            .map(|val| val.parse())
            .transpose()?
            .unwrap_or_else(|| {
                if cfg.release {
                    Default::default()
                } else {
                    WasmOptLevel::Off
                }
            });

Example 2:

    async fn wasm_opt_build(&self, wasm_name: &str) -> Result<()> {
        // If not in release mode, we skip calling wasm-opt.
        if !self.cfg.release {
            return Ok(());
        }

This shouldn't happen if a custom profile is applied, since I specified my own optimization level (i.e. opt-level = 'z') in a custom wasm-release profile. Currently, if I don't add --release, my custom profile's opt-level is skipped.

Thus, I'd propose the following:

  • Add a new --opt-level config, which will accept an opt level. Currently it is an attribute in documents, but doesn't have a CLI flag. Opt level should fall back to a sensible default if --release is used, but do nothing if a cargo profile is used.
  • If --opt-level is absent, and --release is not used, skip wasm-opt.

Hence, using a profiles should behave as such:

trunk build --release
  • Builds the release cargo profile
  • Runs wasm-opt with a default optimization level (current behavior)
trunk build --cargo-profile wasm-release
  • Builds the wasm-release cargo profile
  • Skips wasm-opt
trunk build --cargo-profile wasm-release --opt-level z
  • Builds the wasm-release cargo profile
  • Runs wasm-opt with a aggresize size ('z') optimization level
@simbleau
Copy link
Member Author

simbleau commented Jan 5, 2025

An alternative I didn't mention is that we could attempt to read and inherit the optimization level from a given cargo-profile in the cargo manifest for packages (or workspace manifest, if a member).

Benefits:

  • No additional cli flag

Cons:

  • More complicated
  • What if the user wants a different wasm-opt level from a cargo opt level? Are they 1:1?

@ctron
Copy link
Collaborator

ctron commented Jan 13, 2025

IIRC a lot of features internally are triggered by the "release" flag. I think we should move away from this and have individual settings. And having --release only change the default values for those individual flags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants