Custom wasm file not loading correctly in Nuxt apps

[joaomarcelofm]

Describe the bug

Based on the sample code provided in this issue #354 by @Sec-ant, providing the URL for a self-hosted file should work.
I've added the wasm file as a static file of a Nuxt project as our CSP rules are pretty strict.

The camera is active, but the reader fails to execute.
The implementation is what's provided in the minimal reproduction setup below. Is that incorrect?

To Reproduce
https://stackblitz.com/edit/github-ptbbrj?file=app.vue

Screenshots

Desktop (please complete the following information):

• OS: MacOS
• Browser: Chrome
• Version: 123.0.6312.107

[Sec-ant]

Looks like there's a mismatch between the version of the WASM binary and the js code.

Each version of zxing-wasm (an indirect dependency of this lib) has an associated WASM binary file that is incompatible with other versions. You should make sure you use the correct version of the WASM binary when you want to serve it yourself.

The DX is not very good for users who want to host their WASM files themselves, I'm open to all kinds of suggestions to make this less an issue.

[dargmuesli]

Ideally, a user of vue-qrcode-reader should be able to import zxing_reader.wasm from vue-qrcode-reader, I'd say. That way the correct version is used at all times.

[joaomarcelofm]

Thanks both for the quick reply, I really appreciate it!

@Sec-ant suggestion fixed it! I really thought I had to correct the version 🙈
I'm not sure when it changed, though.

But I agree with @dargmuesli, it'd be good to have the file imported along with the lib so there's no mismatch. This setup creates some implicit knowledge in the team, and even if it's documented in code, someone might update the package and not realize they are breaking things.

[dargmuesli]

Should we maybe keep this issue open to track adding an import for zxing_reader.wasm to vue-qrcode-reader?

[joaomarcelofm]

Sure, I closed it as it wasn't a bug but feel free to reopen it 👍

From what I read in the original issue, one thing about this setup is that the reason to not include the wasm file in the lib is its size, which is fair. However, the end user will have to download it eventually, be it from the bundle or the CDN.

Would it be possible to include it in the package but defer the import so it doesn't take up the initial bundle weight and block critical resources? In our implementation, we already have QrcodeStream as a client-only component, so it'd be okay to have everything else only imported at that point. I think that shouldn't be a requirement, though. I think folks might need it for offline readers and whatnot, but perhaps that's not a main use case.

[github-actions]

This issue has been marked as stale. If there is no further activity it will be closed.

[dargmuesli]

@gruhn could we mark this tracking issue in a way that it isn't closed automatically?

[gruhn]

Not sure. I can remove the label but I think it will be re-added in awhile.

[dargmuesli]

On the documentation page for the action you've added that manages stale items, there are various configuration options on how to exempt items from the automation: https://github.com/actions/stale?tab=readme-ov-file

For example, the exempt-issue-labels or exempt-issue-assignees option could be configured.

[gruhn]

Just discovered this stage 3 ESM proposal, which might help streamline WASM imports.