`app_bg.wasm` changed between 0.2.70 and 0.2.73

[cecton]

Describe the Bug

I'm the author of wasm-run but it broke recently because the JS file (app.js) can't find the WASM file (app_bg.wasm).

As you can see in my code here I was relying on the fact that the name of the files were always "app.js" and "app_bg.wasm". But between 0.70 and 0.73 you made a change somewhere so the name used is now the crate's name that is compiled: myfrontend_bg.wasm.

Because of that, the JS code can't load the WASM file anymore on projects using wasm-run.

Steps to Reproduce

1. Create a new project with wasm-run: cargo generate --git https://github.com/cecton/wasm-run-template.git -b main
2. Run serve: cargo run -- serve
3. Go on http://127.0.0.1:3000
4. See error

Expected Behavior

The name won't change between patch versions. This is a breaking change.

Actual Behavior

Every project using wasm-run right now that does cargo update will silently fail as this is a runtime error.

[cecton]

I believe I found the commit that changed this behavior: de2a5d7

Related to #2444

[alexcrichton]

I apologize for the breakage, would something like #2520 fix your use case?

@alexcrichton No, the PR I created assumes that the wasm file has the same name, it just couldn't lookup the wasm file's name correctly.

Example: "foo.js" and "bar_bg.wasm" are emit, the user calls foo.js' load(), load attempts to fetch "foo_bg.wasm," since "foo" was the name of the .js file, the fetch fails :)

wasm-bindgen should emit "foo.js" alongside "foo_bg.wasm," not "foo.js" with "bar_bg.wasm."

Hopefully it helped you see the problem better, and sorry for using metasyntactic variable placeholder names, if anyone cares.

[cecton]

I apologize for the breakage, would something like #2520 fix your use case?

I don't think it will because wasm-run is also going through the "web" output. https://github.com/wasmbl/wasmbl/blob/main/src/lib.rs#L741

@alexcrichton Can we yank the versions for now until we decide? I wouldn't mind that you increase the version to 0.3 for that change.

[alexcrichton]

Unfortunately this is old enough I don't think a yank is feasible at this time. I also do not have the time to manage an 0.3 release. @RReverser would you be able to comment on this as the author of the original patch?

[RReverser]

Hm, if the name change happened indeed in that commit, it wasn't intentional.

To be honest I don't fully understand the issue either:

As you can see in my code here I was relying on the fact that the name of the files were always "app.js" and "app_bg.wasm". But between 0.70 and 0.73 you made a change somewhere so the name used is now the crate's name that is compiled: myfrontend_bg.wasm.

I think crate name has been used for a while now (always?), and filename was never hardcoded to app.js / app_bg.wasm in wasm-bindgen, so the original assumption seems strange...

[RReverser]

I thought maybe something in my change made custom --out-name getting ignored (which is the option intended for customizing output name), but no, that still works just fine too. So I'm still not sure where the original assumption was coming from or what changed it.

[cecton]

The original name was derived from the URL. So if the JS file is on https://example.org/app.js it will load app.wasm. With the changes done, the name is now derived from the crate name at compile time. @RReverser

Before:

input = import.meta.url.replace(/\\.js$/, '_bg.wasm');

After:

                        input = new URL('{stem}_bg.wasm', import.meta.url);
...
                stem = self.config.stem()?
...
    pub fn stem(&self) -> Result<&str, Error> {
        Ok(match &self.input {
            Input::None => bail!("must have an input by now"),
            Input::Module(_, name) => name,
            Input::Path(path) => match &self.out_name {
                Some(name) => name,
                None => path.file_stem().unwrap().to_str().unwrap(),
            },
        })
    }

[cecton]

You know what it's okay. Apparently this doesn't seem to bother anybody else than me so I will make a fix on wasm-run.

[RReverser]

Oh, I see, so what you're saying is you were renaming output files after they were compiled, so after my changes hardcoded string no longer matches.

Makes sense, I didn't anticipate that scenario and assumed people use produced wasm-bindgen's output as-is - sorry about that.

But yeah, I think it's more reliable to use --out-name=app option on the wasm-run side.

[cecton]

Thanks for the tip! It worked like a charm ✨ I made a release this weekend.