Different wasm filenames between cargo leptos serve and cargo leptos build

[sebadob]

Describe the bug
I stumpled across this while I wanted to provide my input to the Docs issue.

The index page requests different file names between a cargo leptos build (-r) and cargo leptos serve, which makes the build step fail. This happens with leptos in SSR mode.

When I execute it in development mode with either cargo leptos serve or watch, the <link> matches the filename on the system:

<link rel="preload" href="/pkg/leptos-axum-template.wasm" as="fetch" type="application/wasm" crossorigin="">

When I execute the compiled binary, it requests the following wasm in the html with the added _bg, which does not exist at all in target/site, only the filename from above does:

<link rel="preload" href="/pkg/leptos-axum-template_bg.wasm" as="fetch" type="application/wasm" crossorigin="">

Leptos Dependencies

A list of dependencies would be pretty complex, since this a workspace'd setup.
The basis is the start-axum template from the docs though from a few days ago.

Expected behavior
I would expect the same filename all the time, no matter at what stage we are.
I don't know where the _bg is coming from or if there is maybe a good reason for this, but with this being added, I can only make a deployment work with a manual workaround in code inside my custom static files handler and basically rewrite the request from the browser and remove the _bg so it actually maps to an existing wasm file.

Screenshots

I am using rust_embed for all static files to only have a single binary in the end and also
a custom handler for the static files. I just quickly added some debug logging to actually compare what is availbale and what is requested. It is working fine during cargo leptos serve but will fail like in the screenshot after cargo leptos build and then manually executing the binary:

The .br extension is added by me manually since I want to serve precompressed files. But just to prove, that I did not add this _bg somehow, here a screenshot from the sourcecode from the browser:

While it does not have the _bg extension with cargo leptos serve:

If any additional information is needed, please let me know.
I am just in the middle of creating a template for a few upcoming projects that should be based on leptos, but I could push it even though it is not complete yet.

[gbj]

I don't know where the _bg is coming from or if there is maybe a good reason for this

This comes from some code that's used to ensure compatibility between scenarios in which people are building the frontend with wasm-pack (which appends _bg to all .wasm file names) and in which people are building it with cargo-leptos (which does not).

leptos/integrations/utils/src/lib.rs

Lines 53 to 59 in 8a90f97

	// Because wasm-pack adds _bg to the end of the WASM filename, and we want to mantain compatibility with it's default options
	// we add _bg to the wasm files if cargo-leptos doesn't set the env var LEPTOS_OUTPUT_NAME at compile time
	// Otherwise we need to add _bg because wasm_pack always does.
	let mut wasm_output_name = output_name.clone();
	if std::option_env!("LEPTOS_OUTPUT_NAME").is_none() {
	wasm_output_name.push_str("_bg");
	}

However, this compile-time check is inadvertently done at runtime instead here

leptos/integrations/utils/src/lib.rs

Lines 89 to 95 in 8a90f97

	// Because wasm-pack adds _bg to the end of the WASM filename, and we want to mantain compatibility with it's default options
	// we add _bg to the wasm files if cargo-leptos doesn't set the env var LEPTOS_OUTPUT_NAME
	// Otherwise we need to add _bg because wasm_pack always does. This is not the same as options.output_name, which is set regardless
	let mut wasm_output_name = output_name.clone();
	if std::env::var("LEPTOS_OUTPUT_NAME").is_err() {
	wasm_output_name.push_str("_bg");
	}

This means what you need to do is LEPTOS_OUTPUT_NAME=start-axum ./target/server/release/start-axum

Will fix in a PR in a second.

[sebadob]

That was a very easy fix. With this the ENV set beforehand it works fine.

Thank you for the fast reply!