Intro

We want to support Wasmer 3 in fp-bindgen. However, Wasmer 3 brings with a few changes that make it less than trivial to upgrade to it. This caused our initial upgrade approach to fizzle out, but some lessons were learned.

Clonability

Currently the fp-bindgen Runtime can be Cloned. However, the new Wasmer 3 Store cannot be cloned. This is arguably an improvement, but in order to make sure that our Runtime struct can still be cloned, we have to do some work. If we don't keep Stores around across method calls, but simply create new ones, that should already solve the issue, though. It seems that to create a new Module you need a Store, but this store is not actually used in the Module creation. Therefore, I guess a Module can be reused even across stores.

Mutability

In Wasmer 3 function invocations require a mutable wasmer Store. In Wasmer 2 this was not the case. Method calls on our generated Runtime struct would therefore also need to become mutable. Arguably this is more correct, since method calls are mutating memory and so on. However, it is a change to be aware of and would potentially be breaking to our users. If the Runtime remains cloneable, though, it may be less of a worry. Some extra details here: wasmerio/wasmer#3530

Feature

For compatibility purposes (and the changes listed above) it would be nice if users of fp-bindgen can choose whether to use the existing Wasmer 2 support or move to the new Wasmer 3 support. It would be nice if we can place the Wasmer 3 support behind a new host feature flag.

(note: ticket updated on March 6th after discussion with @kajacx on Discord)