-
Notifications
You must be signed in to change notification settings - Fork 63
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
Instantiation mode with default imports #512
Comments
This might make sense as an option actually. We'd need to use a dynamic import in the instantiation body and make this a configurable option as part of the instantiation output. Happy to give pointers if you're interested in working on it. |
Thanks for your answer. I doubt if I can pick it up. After a few days finding out how this library works, I haven't really figured out how the inside works yet. |
I don't know if it's reasonable or possible, but is it possible to have an instantiation mode or something so that the WebAssembly.compile as a function argument can be left out? This way we aren't required to instantiate with a WebAssembly.compile object if we have the base64 of the WASM file inside the JS module. Also we can override the imports to allow things like preopens and env easily. |
It sounds like you want some kind of partial instantiation here? It's an interesting use case, perhaps there's a way to define it with CLI arguments so that the given imports are host imports and the given ones are instantiate arguments. But I also like your first suggestion for handling this too as default arguments, that seems a little more elegant. |
When using instantiation mode of the transpile command, the
imports
is a required arguments ofinstantiate
function. Can we the lists of the default imports like using in non-instantiation? This way we can specify/overwrite imports when needed.The text was updated successfully, but these errors were encountered: