Skip to content

Conversation

jesseditson
Copy link

In some environments (namely, cloudflare workers), fetching wasm binaries (even from data urls) is disallowed. In addition, cloudflare workers don't support top level await, and it's not on the roadmap.

However, cloudflare does support uploading a wasm binary and importing it (which will import a module ready for instantiation).

This solution is similar to what was proposed in #30, but is a slightly lower hanging approach than making the entire API async - instead, it just borrows the init pattern from -compat and requires that you provide the wasm file (which can be referenced from the package). Because it is imported as a module, bundlers will find and include the wasm binary, resulting in this working as expected.

Usage ends up looking like this:

import rapier3d from "@dimforge/rapier3d-inject";
import rapier3dModule from "../../node_modules/@dimforge/rapier3d-inject/rapier_wasm3d_bg.wasm";

// later

await rapier3dLib.init(rapier3dModule);

// now can use rapier3d as usual

I realize this may not be as elegant a solution as would be possible with some more work, but for me I just needed to unblock a workflow running rapier on cloudflare and this allowed me to preserve some isomorphic logic because I can now inject the normal @dimforge/rapier3d on the client, and the new injected version in the worker.

As for implementation, I just wrote a quick script that copies the -compat package and overrides the init.ts scripts and the rollup config.

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

Successfully merging this pull request may close these issues.

1 participant