🐛 BUG: wrangler pages dev with proxy command does not expose durable objects to qwik

[zbynekwinkler]

Which Cloudflare product(s) does this pertain to?

Pages

What version(s) of the tool(s) are you using?

wrangler 3.2.0

What version of Node are you using?

v18.16.1

What operating system are you using?

WSL (openSUSE leap 15.5)

Describe the Bug

I want to use qwik framework together with durable objects. When I use create-cloudflare to create an app with qwik, it adds the following to packages.json:

    "pages:dev": "wrangler pages dev --compatibility-date=2023-07-10 -- pnpm run dev",

This works great (sans durable objects). I was able to track down that the way to develop durable objects with pages locally is to connect to an existing worker:

Currently, the only way to use Durable Objects with Pages functions is by configuring a binding to an existing Worker's Durable Object namespace. Since it just connects to that namespace and doesn't actually reimplement it, they'll share data.

So. Using

    "pages:dev": "wrangler pages dev --compatibility-date=2023-07-10 dist --do NAME=Class@../path-to-existing-worker/",

populates the platform.env key in a qwik request handler and I can see my durable object (along with ASSETS: Fetcher):

export const onRequest = async ({ platform }: { platform: any }) => {
  console.log(platform.env);
};

However - this requires the project to be prebuilt into dist folder. That way I use all the vite niceness in qwik. I have tried to combine the the two - using proxy with the --do option but that does not work for me (the env key in platform is not set).

    "pages:do": "wrangler pages dev --compatibility-date=2023-07-10 --do NAME=Class@../path-to-existing-worker/ -- pnpm run dev",

The output during startup suggests that the durable object is made available, but the platform.env is undefined.

Please provide a link to a minimal reproduction

No response

Please provide any relevant error logs

No response

[mayfieldiv]

From digging into the wrangler source code, I was finally able to make durable object bindings work locally for Cloudflare Pages in my project.

Each instance of wrangler publishes its running worker and durable objects to a worker registry, running locally on port 6284. You can request http://localhost:6284/workers manually to see what your running wranglers are currently broadcasting. It should return something like this:

{
  "my-durable-objects-worker": {
    "protocol": "http",
    "mode": "local",
    "port": 8787,
    "host": "127.0.0.1",
    "durableObjects": [
      { "name": "MY_DURABLE_OBJECT", "className": "MyDurableObject" }
    ],
    "durableObjectsHost": "127.0.0.1",
    "durableObjectsPort": 8787
  }
}

You need to specify the full --do BINDING=MyClass@service-name for your Pages wrangler to be able to locate and bind the durable object running in your other non-Pages worker locally.

In the above example, you'd do:

wrangler pages dev --do MY_DURABLE_OBJECT=MyDurableObject@my-durable-objects-worker ...

[mrbbot]

Hey! 👋 Apologies for the delayed response here. Accessing bindings whilst still using framework dev servers is something we're actively looking at improving. @dario-piotrowicz is currently working on something for Next.js, but we're exploring ideas for other frameworks too. 👍

[RonenEizen]

Unfortunately same issue with SvelteKit and the instructions from the docs do not work, nor do I get a list mentioned by @mayfieldiv when I navigate to http://localhost:6284/workers. Although my worker is running but the list appear empty.

[RonenEizen]

Unfortunately same issue with SvelteKit and the instructions from the docs do not work, nor do I get a list mentioned by @mayfieldiv when I navigate to http://localhost:6284/workers. Although my worker is running but the list appear empty.

I finally was able to get the DurableObject work to show up in the worker registry. Apparently the worker must have default export with fetch handler. Though DurableObject is not available to vite when calling wrangler pages dev -- vite dev command, it is available when project is built. One workaround I came up with specifically for vite is to run 3 commands in parallel vite build --watch, wrangler pages dev ./svelte-kit/cloudflare and wrangler dev for the DurableObject worker.

[longrunningprocess]

fwiw, that's what is also required in sveltekit projects to make a D1 binding available to a locally running version of the build.

vite build and then wrangler pages dev .svelte-kit/cloudflare will populate the bindings, platform.env in the case of sveltekit projects, found in the wrangler.toml

[gerhardcit]

Have a look at this. I got sveltekit dev to work locally using cf-bindings-proxy for Cloudflare D1

james-elicx/cf-bindings-proxy#43

[CarmenPopoviciu]

hi folks,

lots of things to unpack in this issue, so will do my best to answer everything.

1. Pages + Durable Objects

Today, Pages cannot define/deploy a Durable Object itself. In order to use Durable Objects with Pages, the DO needs to be defined inside a separate Worker. Once this Worker is deployed, you can reference that Durable Object in your Pages project in three ways:

• via wrangler.toml (still in beta)

[[durable_objects.bindings]]
name = "MY_DO"
class_name = "MyDOClassName"
script_name = "MyWorkerScriptName"

• via cmd line args (like most of you have pointed out)

# wrangler pages dev [directory] --do <do_binding_name>=<do_class_name>@<worker_script_name>
wrangler pages dev [directory] --do DO_BINDING=MyDOClassName@MyWorkerScriptName

• via Dash

We are aware that our docs around using DOs in Pages could be better, and we are working on that. We are also aware that folks could use more helpful examples/demos/tutorials around this topic, and we will be working on that as well. In the meanwhile, while not ideal, this fixture in the workers-sdk repo can serve as an example of Pages with DOs.

2. Pages proxy command
It used to be the case that users could specify a proxy command in local development for Pages, like for example wrangler pages dev -- vite dev. This has been in the meanwhile deprecated due to many issues, and is no longer recommended moving forward. The recommended way today is to build your application to your static assets [directory], then run wrangler pages dev [directory]. This results in a more faithful emulation of production behavior than the proxy command did.

We are aware that this is not an optimal user experience, but we are hoping to make improvements/address as part of this milestone.

I hope that these details are helpful, but happy to provide more clarifications if needed. I empathise with the friction of getting all this to work, so would really love to help y'all <3.

In the meanwhile closing as won't fix, as proxy command is deprecated.