allow for loading wasm without unsafe wasm execution #1793
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
Shared with Meta
| "SHELL:--no-entry" | ||
| "SHELL:-s ALLOW_MEMORY_GROWTH=1" | ||
| "SHELL:-s ASSERTIONS=0" | ||
| "SHELL:-s DYNAMIC_EXECUTION=0" |
There was a problem hiding this comment.
From what I learned in the other threads, DYNAMIC_EXECUTION=0 might be making the bindings quite a bit slower, if we still end up using it anyways.
Might be worth removing this argument from the base64 variant, or seeing what happens if we add EMBIND_AOT to both (might require bumping emsdk here
yoga/javascript/just.config.cjs
Line 140 in 1b7d2c8
| set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/binaries) | ||
| add_link_options( | ||
| ${COMPILE_OPTIONS} | ||
| "SHELL:--closure 1" |
There was a problem hiding this comment.
Could we avoid duplicating the bits here that are not different?
|
Thanks for digging into this issue! I've been a little bit weary towards wanting many flavors. E.g. some folks have wanted CommonJS, others have wanted an ASM.js version, not to mention the sync compile vs async compile delineation we have right now. But it seems like this issue is pretty commonly hit, so this makes sense to me. When we did have multiple flavors though, for sanity, we ran Jest tests against each of them. That would be great to add back here (some of it was in the before state for) ef1d772 I haven't thought about it closely, but I almost wonder if it might make sense to have different packages for these. |
fixes #1767, by allowed you to not bundle the wasm as a base64 encoded string which is dynamically loaded at eval time