Missing migration guide for usage of getBindings()

[eltigerchino]

Previously in V2, the getBindings() method was useful for working with SvelteKit and KV, D1, etc. locally. However, this method has been removed without new recommendations for retrieving the bindings.

The link below provides an example of how Miniflare V2 enabled local development of SvelteKit projects. I'm also wondering if this change has affected other fullstack frameworks.
sveltejs/kit#2966 (comment)

[mrbbot]

Hey! 👋 Thanks for raising this. With Miniflare 3, we're now using the open-source Workers runtime workerd to provide runtime APIs. This runs in a separate process, and you can't really reference JavaScript classes across process boundaries. What we could do is provide stubs that forwarded requests to workerd, but these wouldn't be very efficient. This may be enough for local development though. 🤔

Alternatively, it would be good to investigate whether the SvelteKit server could run inside workerd during development. I'm not too familiar with SvelteKit, but given it deploys to Workers, in theory it should be able to run in workerd for development too.

[SupremeTechnopriest]

@mrbbot Are you planning to continue support for v2? The switch to workerd kind of removed everything that made miniflare great... Losing the get* methods is a real bummer. For instance, I have a seed file that I use to set up my local dev KV Stores. I tried to implement the same functionality using a dispatchFetch to a temporary worker that put the json request body in the kv store, but I couldn't get it to work. Testing also took a big hit in v3...

While having an identical runtime is nice (no more behavior mismatch label), losing all the tooling that made miniflare great is a questionable trade off. It was very rare that I ran into behavior mismatches, but now I cant unit test my code and storage persistence seems to be broken all together (.mf/v3/kv/unused?). The release of v3 leaves me with these questions:

• Are there plans to bring these missing features back to v3?
• If so is there a public roadmap/timeline we can follow?
• And in the meantime, will v2 still be maintained?

Hopefully the answer to all of these questions is yes because the v3 release feels incomplete and premature. Not trying to disparage all of your hard work. You have definitely made workers 1000000x better to work with and I appreciate you thoroughly. Its just that the v3 release was an emotional roller coaster. I saw a new version available, got super excited, started upgrading my project, was quickly disappointed, and had to roll back. It always feels icky running an outdated version of a dependency. 😢

[SupremeTechnopriest]

Actually, let me relocate this to a discussion. Probably better place for it.

[SupremeTechnopriest]

#588

[eltigerchino]

What we could do is provide stubs that forwarded requests to workerd, but these wouldn't be very efficient. This may be enough for local development though. 🤔

Do you mean something like this example? I managed to get the basic KV get and put working by writing a worker for it. It would be great if there was a built-in functionality for this.

Alternatively, it would be good to investigate whether the SvelteKit server could run inside workerd during development. I'm not too familiar with SvelteKit, but given it deploys to Workers, in theory it should be able to run in workerd for development too.

I'm not too sure myself, but I believe it relies on Vite's dev server to run and that requires node(?).

PS: Appreciate your time taken to reply and for the great work on miniflare v3

[eltigerchino]

closed by #639