Yeah, the DO local story isn't the best at the moment, there definitely needs to be some better examples for it

it's possible? (without binding to a worker)

The key setup you need is: - A regular separate worker that exports the durable object (it doesn't need to export anything else, like a normal worker would) - Run that locally with

wrangler dev --local

- In pages dev, use

--do MyBinding=MyWorkerScriptName@MyDOClassName

, then you can access your do namespace with

context.env.MyBinding

And for production you just bind it in the dashboard to your DO namespace

i tried that, but it is a bit too complicated a setup for my memory. so, i kind of have to pick one or the other (functions vs workers). since i need to use DO, it has to be workers. so, is there a way to use workers in the same way one would use pages? essentially, being able to call the scripts from the same port domain: './auth' vs 'somedomain.com:somport/auth'?

You can put workers over any domain you own, yes

But it wouldn't work for

.pages.dev

domains (including preview deployments)

what about localhost dev?

There's not any nice way for local dev doing that really

This unfortunately is the best approach, I'd recommend you give it a go, we'd be happy to answer any questions you get

i did. that was the approach i took after i found DOs could not be bound directly, but it is complicating things too much for me. my memory can handle complicated code, but not complicated configuration, unfortunately. anyway, it looks like i need to hardcode the urls. thank you

You can always just register the command above in your

package.json

scripts, so that you don’t have to call it from memory

i did, it's just that with that setup, i have config info in a toml file for the worker, and config data in the package.json for the worker and functions. i have the code in seperate places, and some code has to be in both the worker and the functions, and so i need to also share code between. if i make a change to the functions code, i have to keep in mind how that will affect the other and vice versa. i also have two sepeate tsconfigs and two Env interaces.

it also doesn't help that workers and pages have different commands/configs requirements, so i have to remember both

and that's on top of everything else (the client side)

Still not sure I understand thought why you need any code in the Worker, other than for the DO. Functions should be able to handle interactions with KV, R2, D1 etc, without having to touch the Worker at all

i suppose if i removed all logic from the DO and created a generic interface for putting/getting values, that would certainly help. but much of the configuration issue is still there, so i think i will go for the lessor of the two evils, and just deal with the url issue. or, going the other way (which seams less complicated to me). if i could bind the worker itself, i could potentially use pages to get the url of a bound worker for the client (and have all my code in workers), but worker binding in pages does not appear to be supported (even though the documentation says it is)

Note too that this would mean that you would in effect be paying 2x for every request. And Service Bindings should work fine on Pages, just not in local dev

And for the config, you should be able to import it directly in your Functions, if you need it there

true, so it looks like i will just stick to workers, and use pages for the static content. and perhaps port everything to pages once it has direct support for local DO. thank you 🙂

Hi. I have a Gatsby project using Pages Functions. I haven't figured out how to serve my functions locally for local development. Any tips?

Nevermind - quite simple:

npx wrangler pages dev public

I have a question about

[vars]

in pages functions. When I run

wrangler pages dev ...

, I can access the variables declared in

[vars]

as intended, but the workers in functions released with

wrangler pages publish

seem to ignore the

vars

in I have a feeling that

vars

in

wrangler.toml

is being ignored. The result of

wrangler secret put xxx

is the same. The released functions

Objecte.keys(env)

run returns the following results, regardless of the original vars setting. ASSETS, CF_PAGES, CF_PAGES_BRANCH, CF_PAGES_COMMIT_SHA, CF_PAGES_URL Is this the intended behavior, or just a

wrangler pages ...

is under development?

It is a bug that

wrangler pages dev

reads your

wrangler.toml

at all. All configuration should be passed via the CLI, or

.dev.vars

for secrets.

Okay thanks. I will wait for the bug to be fixed. I'll inject the variables in the build step as a workaround, since

wrangler secret put

didn't seem to work either. It's not a good way to do it, though, because if I miss reference it, I'll expose it to the client.

Variables/Bindings for published Pages Projects should be managed on the Dashboard. At the moment,

wrangler pages publish

only supports uploading a built project, not configuring it.

We need wrangler.toml (or sth else) for pages.

Is it possible to rewrite the path to /functions to e.g. /build/functions? It's not a huge annoyance because I've just untracked /functions aslike my build folder, it's just a tiny annoyance.

Not at the moment, no

Hello 👋 , I'm new to this discord server and don't know if my question fits in the #910978223968518144 channel or is better placed in #992060581832032316. I basically have an issue with #992060581832032316 but only when I want to use it on #910978223968518144 so which channel should I use?

say it