Single Worker with DO,RPC and rrv7 with partial prerendering

ok i wonder if that's true because it seems like they are integrating something related to RPC as well

KZOP•7/26/25, 8:05 PM

https://github.com/livestorejs/livestore/blob/ad4935a0c0043b32da18ca6c90ca37044cea009e/packages/%40livestore/sync-cf/src/cf-worker/durable-object.ts#L72

KZOP•7/26/25, 8:05 PM

class WebSocketServerBase implements CfWorker.DurableObject, CfWorker.Rpc.DurableObjectBranded

Hello, I’m Allie!•7/26/25, 8:11 PM

Oh, that's hacky...

KZOP•7/26/25, 8:11 PM

@HardlyWorkin' sry i don't mean to question it but someone from cloudflare,i have to find where i asked this, already told me i wasn't able to define a durableobject class without extending from durableobject. going to use this library to confirm whether or not rpc won't work but

KZOP•7/26/25, 8:11 PM

dude you have no idea how much this breaks me

Hello, I’m Allie!•7/26/25, 8:11 PM

It looks like they manually brand the DurableObject with __DURABLE_OBJECT_BRAND__DURABLE_OBJECT_BRAND, which might make the runtime allow RPC?

KZOP•7/26/25, 8:11 PM

spent the last few weeks dealing with how to get around cloudflare:imports breaking full stack frameworks that prerender

KZOP•7/26/25, 8:12 PM

ya i know

Hello, I’m Allie!•7/26/25, 8:12 PM

I haven't tried it myself, but maybe it works?

KZOP•7/26/25, 8:12 PM

ya the maybe is my prayer

KZOP•7/26/25, 8:12 PM

i don't know whats true anymore

KZOP•7/26/25, 8:13 PM

ok ty though for confirming that its at least hacky

KZOP•7/26/25, 8:14 PM

will try it out tonite thanks for the quick feedback

HHello, I’m Allie!It looks like they manually brand the DurableObject with `__DURABLE_OBJECT_BRAND...

KZOP•7/26/25, 8:16 PM

i wonder if that's why i was inadvertantly gaslit into being told that you couldn't define it without using the cloudflare: import

Larry•7/26/25, 8:17 PM

It implements the DurableObjectBranded interface also so unless they implemented it wrong, it will be able to use RPC

KZOP•7/26/25, 8:18 PM

what is even the point of forcing us to have to use the cloudflare:* imports

KKZ what is even the point of forcing us to have to use the cloudflare:* imports

Hello, I’m Allie!•7/26/25, 8:19 PM

I don't know about you, but I find it easier to do extends DurableObjectextends DurableObject than trying to apply a brand manually, and also apply types to the DO class itself anyway

Larry•7/26/25, 8:19 PM

It's work to use implementsimplements over using the base class implementations with extendsextends so that's why the Cloudflare person told you what they did.

KZOP•7/26/25, 8:20 PM

ok yes i understand that but itseems like you could have just abstracted that away in @ cloudflare/workers-*

Larry•7/26/25, 8:20 PM

Also, the import is variable based upon the compatibility date. They can bake implementation details into the base class.

KZOP•7/26/25, 8:21 PM

i'm assuming one or both of you are cloudflare employees so i'm just going to say my piece once on this bc i have to fake shout at someone over there.

KKZ ok yes i understand that but itseems like you could have just abstracted that aw...

Hello, I’m Allie!•7/26/25, 8:22 PM

The eventual goal is to reduce usage of @cloudflare/workers-types@cloudflare/workers-types(to be clear, it's not going anywhere for the forseeable future, at least not to my knowledge).

wrangler types

wrangler types

should generally generate types compatible with the compatibility dates/flags you select, in a way that @cloudflare/workers-types@cloudflare/workers-types would struggle to match

Larry•7/26/25, 8:22 PM

Cathartic release is important!

KZOP•7/26/25, 8:23 PM

your cloudflare:* imports combined with the fact that you cannot separate the export definitions outside of the main class into secondary means that for full stack frameworks that allow you to do partial prerendering ... you CANNOT GET around the build breaking because node chokes on the cloudflare:* import

Larry•7/26/25, 8:24 PM

Hmmm, I wonder how the vitest integration gets around that since I think it's node-based also

KZOP•7/26/25, 8:24 PM

i had to do weirdo stuff to get around this

KZOP•7/26/25, 8:24 PM

because they import the wrangler unstable proabably

KZOP•7/26/25, 8:25 PM

but the problem is i can't do that for react-router build for instance without rearchitecting that mess of a framework

LLarry Hmmm, I wonder how the vitest integration gets around that since I think it's no...

Hello, I’m Allie!•7/26/25, 8:25 PM

Afaik it just marks cloudflare:*cloudflare:* imports as external

Hello, I’m Allie!•7/26/25, 8:25 PM

Just like node:*node:*

Larry•7/26/25, 8:26 PM

That makes sense

KZOP•7/26/25, 8:26 PM

OK but the problem is that full stack frameworks that are vite based when they try to do prerendering will load the main entry point into node (from the ones that i've found)

KZOP•7/26/25, 8:27 PM

they build the client,ssr then they import main and send it the request to render the page

KZOP•7/26/25, 8:28 PM

cloudflare/vite-plugin "fixes" it by shortcircuiting the ability to prerender. PROBLEM SOLVED... move on

KZOP•7/26/25, 8:29 PM

that issue is sitting in the backlog never to be resolved

KZOP•7/26/25, 8:29 PM

meanwhile i just could have done this

KZOP•7/26/25, 8:29 PM

anyway sorry love everything that cloudflare is doing EXCEPTING THE GDAMN cloudlfare:* imports

KZOP•7/26/25, 8:29 PM

i get it your special i agree with that

KZOP•7/26/25, 8:30 PM

just recognize that stuff leaks into node

KZOP•7/26/25, 8:31 PM

my god this ate up a 20% of a month of my life

KKZ i get it your special i agree with that

Hello, I’m Allie!•7/26/25, 8:31 PM

Couldn't you split out the actual entrypoint into a separate file? If you aren't using the vite-pluginvite-plugin, then you can't use DOs directly in dev anyway. And with a separate entrypoint for Vite Dev/vs your Worker, you shouldn't ever hit a cloudflare:*cloudflare:* import

KZOP•7/26/25, 8:31 PM

you can use d0's with out the vite plugin with out isseue

KZOP•7/26/25, 8:32 PM

the issue is they have to exported from the main class.

KZOP•7/26/25, 8:33 PM

the work that i did was to create multiple vite entrypoints separate worker entry point from the rr entry point and make that what rr build loads

KZOP•7/26/25, 8:34 PM

the problem with that is that you have to completely separate the two no cross contamination which was not failing until i did something with the loadcontext. then the only time rr touches cloudflare was through the load context after its initialized on the worker side. but it causes a performance hit

KZOP•7/26/25, 8:35 PM

tl;dr i nerfed the worker side so that all real functionality that needs anything from the rr side now had to function in the rr side

KZOP•7/26/25, 8:38 PM

my problem could be solved if the DurableObject class did not have to be exported from the main class.

KZOP•7/26/25, 8:40 PM

i seem to be confused by why cloudflare:* exists. i thought it had something to do with native only. i get it for actual method functionality that expects workerd to be the runtime its running

KZOP•7/26/25, 8:40 PM

but if a durable WITH rpc can exist from the workers-types then i don't know anymore outside of actual workerd native only functionality

KZOP•7/26/25, 8:42 PM

and the one thing you can get around is you can "dynamic import" a baseclass you plan on extending from

Single Worker with DO,RPC and rrv7 with partial prerendering

Similar Threads

Similar Threads

Similar Threads