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

"Shared" wasm module no longer builds #250

Closed
1 task done
adrianlyjak opened this issue Apr 25, 2024 · 1 comment · Fixed by #249
Closed
1 task done

"Shared" wasm module no longer builds #250

adrianlyjak opened this issue Apr 25, 2024 · 1 comment · Fixed by #249
Labels
- P4: important Violate documented behavior or significantly improves performance (priority) pkg: cloudflare

Comments

@adrianlyjak
Copy link
Contributor

Astro Info

Astro                    v4.5.8
Node                     v21.7.3
System                   macOS (arm64)
Package Manager          npm
Output                   hybrid
Adapter                  @astrojs/cloudflare
Integrations             none

Describe the Bug

After upgrading to astro v10 (from v8), my wasm module imports stopped working. After investigating the tests, I discovered that the differences seems to be that in my build, a shared file that imports a wasm module is used both within an SSR route and a SSG route. When this scenario occurs, the astro build ends in an obscure error:

file:///Users/adrianlyjak/dev/withastro-adapters/packages/cloudflare/test/fixtures/wasm/dist/_worker.js/chunks/hybrid_DqxhzLZ0.mjs?time=1714010209741
Unknown file extension ".wasm" for /Users/adrianlyjak/dev/withastro-adapters/packages/cloudflare/test/fixtures/wasm/dist/_worker.js/add.1ot1qwu.wasm
  Stack trace:
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:160:9)
    at defaultLoad (node:internal/modules/esm/load:143:22)
    at async ModuleLoader.moduleProvider (node:internal/modules/esm/loader:285:45)

This change modifies the tests to reproduce the error

It seems like there's a flaw in the logic of splitting up a wasm import between pre-rendered and server rendered mode, it could be both!

			const isPrerendered = Object.keys(chunk.modules).some(
				(moduleId) => this.getModuleInfo(moduleId)?.meta?.astro?.pageOptions?.prerender === true
			);

			let final = code;

			// SSR
			if (!isPrerendered) {
				// replace with .wasm for workerd environments
			}

			// SSG
			if (isPrerendered) {
				// replace with .wasm.mjs for nodelike environments
			}

I'm thinking that this needs to be approached some other way. The best I can think of is to build the code for node while still emitting bundled assets, and then do a last minute minor modification to update the imports to point to the asset for cloudflare workers

What's the expected result?

You should be able to import shared wasm modules like before

Link to Minimal Reproducible Example

main...adrianlyjak:withastro-adapters:shared-wasm

Participation

  • I am willing to submit a pull request for this issue.
@alexanderniebuhr
Copy link
Member

@adrianlyjak Thank you for the well detailed issue report, I think the option to have a shared wasm file was just overlooked.

@alexanderniebuhr alexanderniebuhr added pkg: cloudflare - P4: important Violate documented behavior or significantly improves performance (priority) labels Apr 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
- P4: important Violate documented behavior or significantly improves performance (priority) pkg: cloudflare
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants