-
Notifications
You must be signed in to change notification settings - Fork 26
Migrate WasmModule construction to top-level factory functions. #94
Conversation
What's the rationale for switching to top-level factory functions? The async version is there for when we add web support. Wasmer doesn't have a built in way of compiling asynchronously, but on the web that's the main recommended way. |
By routing all ways to instantiate a wasmer based WasmModule through these two top level factory functions we'll be able to make everything else private in that file to explicitly exclude it from the public API. (we could use parts, but that would add a dependency on wasmer to Together with |
Sounds reasonable. How would we provide a different implementation of these functions for the web? Just delegate to impl functions defined in conditionally imported scripts? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you update the change log?
Conditional imports would be one way. However, there are some subtleties that make conditional imports suboptimal in my opinion. One of which is that they aren't really supported all that well by the dart analyzer. (But they are the most user friendly way in the sense that users won't have to care about any implementation details.) |
changelog updated (and version bumped) |
update changelog migrate brotli api add newline to changelog
a8c59f0
to
d25ab1c
Compare
I've rebased on main and squashed the commits. |
See #92 step 2.
The following are some TODOs as a note to myself: