I want to publish an npm package for use in cloudflare projects that includes a pre-written durable

I want to publish an npm package for use in cloudflare projects that includes a pre-written durable object. End users would install the package, add a couple lines to their

wrangler.jsonc

wrangler.jsonc

(unless there is a magic way to not do this step) — and viola they have this particular durable object working.

I have 2 questions:

This import
```
import { DurableObject } from "cloudflare:workers";
```
```
import { DurableObject } from "cloudflare:workers";
```
assumes
```
cloudflare:workers
```
```
cloudflare:workers
```
can be resolved, but of course that is only importable with a build tool like vite. Should I bundle cloudflare:workers as an internal dependency? What would the CF team recommend?
How does the
```
class_name
```
```
class_name
```
property of wrangler's config work? Can it resolve a class that is in a dependency?

KKam Thanks Larry, I had considered something along those lines. Wouldn't that requir...

Larry•11/3/25, 8:24 PM

True. I hadn't thought of that. What if you set the new alarm at the beginning of your handler for the current alarm instead of at the end?

JJustin Schroeder I want to publish an npm package for use in cloudflare projects that includes a ...

Kevin•11/3/25, 8:38 PM

cloudflare:workers

cloudflare:workers

comes from

worker-configuration.d.ts

worker-configuration.d.ts

file that gets generated from config using . Durable object is just a typescript class that you import to your project and add to your wrangler config.

Justin SchroederOP•11/3/25, 8:40 PM

thats where typescript gets it, but it has a concrete implementation too doesnt it?

Kevin•11/3/25, 8:44 PM

I don't know the details about the runtime but since class_name must be the name of the class I guess thats how they know it.

JJustin Schroeder I want to publish an npm package for use in cloudflare projects that includes a ...

Hard@Work•11/3/25, 8:46 PM

You should mark it as an external dependency. Treat it like imports to

node:

node:

-prefixed packages

HHard@Work You should mark it as an external dependency. Treat it like imports to `node:`-p...

Justin SchroederOP•11/3/25, 8:49 PM

Thanks, will do. As for the

class_name

class_name

property in the config, how does that resolve to the actual class? Seems a bit magical — would love to understand that part more.

JJustin Schroeder Thanks, will do. As for the `class_name` property in the config, how does that r...

Hard@Work•11/3/25, 8:53 PM

It's the name of the export in the Worker's

main

main

file. So for example, if your package exports a DO named

SuperDO

SuperDO

, it would look something like this:

// src/index.ts, or whatever their main file is
export { SuperDO } from "justin_utils"; // class_name: SuperDO
export { SuperDO as MyMadeUpDOClassName } from "justin_utils"; // class_name: MyMadeUpDOClassName

// src/index.ts, or whatever their main file is
export { SuperDO } from "justin_utils"; // class_name: SuperDO
export { SuperDO as MyMadeUpDOClassName } from "justin_utils"; // class_name: MyMadeUpDOClassName

Justin SchroederOP•11/3/25, 9:26 PM

ok excellent. thank you for that clarification

Justin SchroederOP•11/3/25, 9:27 PM

Last question (for now

) is there any way to "extend" a

wrangler.jsonc

wrangler.jsonc

from some base — sort of like a

tsconfig.json

tsconfig.json

JJustin Schroeder Last question (for now 😂) is there any way to "extend" a `wrangler.jsonc` from ...

Hard@Work•11/3/25, 9:32 PM

No, there is not

1984 Ford Laser•11/3/25, 11:00 PM

I just got the following warning in a Worker that creates a bunch of DO stubs in quick succession (and doesn't explicitly dispose of them). My understanding from reading the docs was that the disposal is technically optional as the runtime will do its best to dispose of them when necessary. Is there a certain limit I'm hitting where I need to start explicitly disposing?

An RPC stub was not disposed properly. You must call dispose() on all stubs in order to let the other side know that you are no longer using them. You cannot rely on the garbage collector for this because it may take arbitrarily long before actually collecting unreachable objects. As a shortcut, calling dispose() on the result of an RPC call disposes all stubs within it.

An RPC stub was not disposed properly. You must call dispose() on all stubs in order to let the other side know that you are no longer using them. You cannot rely on the garbage collector for this because it may take arbitrarily long before actually collecting unreachable objects. As a shortcut, calling dispose() on the result of an RPC call disposes all stubs within it.

11984 Ford Laser I just got the following warning in a Worker that creates a bunch of DO stubs in...

Larry•11/3/25, 11:48 PM

If you use

using

using

, the local resource is disposed but not the remote one. This is worrisome because it keeps the remote in wall clock billing mode. I don't think it matters, but I'm curious, are you doing DO to DO or are you using RpcTarget on the caller side?

LLarry If you use `using`, the local resource is disposed but not the remote one. This ...

1984 Ford Laser•11/3/25, 11:52 PM

It's RpcTarget but I definitely don't use

using

using

. Lemme add that in and see how I go

1984 Ford Laser•11/3/25, 11:53 PM

In this specific case it's only a single RPC call too so it doesn't even need to be a full stub necessarily. My VsCode autocomplete just does its own thing

HHard@Work You should mark it as an external dependency. Treat it like imports to `node:`-p...

Larry•11/3/25, 11:53 PM

I don't do this and it still seems to work. Where are you saying to specify this and how? I've never done it for a node:* dependency either, but my plain node packages go back to before they had node:*, I think.

LLarry I don't do this and it still seems to work. Where are you saying to specify this...

Hard@Work•11/3/25, 11:55 PM

I guess maybe it automatically guesses if deps are external or not? I meant more, if it throws errors because it can't find

cloudflare:whatever

cloudflare:whatever

, then you should mark it as external. If it already works, no need to change it

Burrito•11/4/25, 12:05 AM

(Also this only matters if your package project is built with a bundler)

LLarry If you use `using`, the local resource is disposed but not the remote one. This ...

1984 Ford Laser•11/4/25, 12:08 AM

This fixed it thank you, now I definitely need to go through and add

using

using

to like 20 different Workers

BBurrito (Also this only matters if your package project is built with a bundler)

Larry•11/4/25, 12:32 AM

Ahh, that makes sense. I use tsc now to prep for publishing to npmjs.com

LLarry As a thought... based upon your use of "additional work after returning", what a...

Need_Not•11/4/25, 7:25 AM

Wow Larry you put in a lot of work. As for the rquestion. The DO is like the controller and optimistic state which is called from a normal worker. So the functions have to return so that the worker can return back to the user.

One example is if old data needs to be purged to make room for new data. I simply save which data that is, set the alarm and then return back to the user. Some time later the alarm will fire and delete the data. At the same time the DO is meant to only be optimistic state so after inactivity or no longer relevant data it should just self destruct.

Need_Not•11/4/25, 7:46 AM

I'll give these a go

NNeed_Not Wow Larry you put in a lot of work. As for the rquestion. The DO is like the con...

Larry•11/4/25, 11:03 AM

Wow Larry you put in a lot of work

True, but a lot of what I'm doing right now is cleaning up and open-sourcing stuff we already use. It still requires cleanup, more tests, and documentation. As a side effect, we've fixed some bugs, improved the internal DX, and made it easier for our devs to work.

João Castro•11/4/25, 6:52 PM

About the 6 simultaneous outgoing connections limit, are there any plans to make it easier to work around it? I remember reading somewhere that 6 was chosen as the limit because its the default for some browsers, but acting as a server there are some real-world scenarios where we would benefit from having a higher limit.

Right now the options seem to be calling a worker through HTTP (so they don't share the resources and limits) or spawning a new DO instance, which is what I'm doing currently. Both sound very inefficient and can add unnecessary complexity for such a simple thing.

João Castro•11/4/25, 6:54 PM

This is a very noticeable bottleneck when dealing with Queues, for example

Pplgingras88 Absolutely — I agree with much of what’s been said. Cloudflare DOs bring strong ...

Nathan•11/4/25, 8:05 PM

We have automatic geo-routing at Rivet too. Additionally – a lot of folks run RivetKit on Durable Objects since Cloudflare provides unique features or run a hybrid of Cloudflare for managed & Rivet on-prem. Happy to chat in our Discord if you have any further questions to keep this channel on topic!

kchro3•11/4/25, 10:22 PM

hey folks, was poking around @Brayden 's actors library and thought it would be worth asking here.

suppose i have a UserDO where i want to store event logs per user. the id would be the user ID, so there would be a SQLite table representing every user event. i liked what the actors framework was doing, where you could have a dedicated "tracker" instance that would update on create / delete of every DO so that you can scan the other DOs.

i was also thinking that it could be helpful to:

support partitioning so that the users are collocated on the same tracker (e.g. if it's a b2b saas application, maybe you want the users to be partitioned by org so each tracker's ID would be org+tracker suffix; or maybe you want to collocate the tracker DO by geo)
add columns to the tracker's users (e.g. if a user has properties like age, createdAt, etc.), so that you could query them later
support repartitioning so that if the durable object for one tracker runs out of memory, it could fan out with a master-slave architecture.

have folks run into anything like that before or have thoughts on better approaches?

JJoão Castro About the 6 simultaneous outgoing connections limit, are there any plans to make...

João Castro•11/4/25, 10:29 PM

Just found the post where I read this: https://community.cloudflare.com/t/2019-9-19-workers-runtime-release-notes-concurrent-subrequest-limit/115546

Need_Not•11/5/25, 3:36 AM

Am getting

error setting identifier TypeError: this.parent.setName is not a function

error setting identifier TypeError: this.parent.setName is not a function

when running

await this.alarms.alarm();

await this.alarms.alarm();

the alarm seems to still work actually. Not sure what the setName function is for since it's not in any of the examples. (https://github.com/cloudflare/actors/blob/e910e86ac1567fe58e389d1938afbdf1e53750ff/examples/durable-objects/src/index.ts)

GitHub

actors/examples/durable-objects/src/index.ts at e910e86ac1567fe58e3...

An easier way to build with Cloudflare Durable Objects - cloudflare/actors

1984 Ford Laser•11/5/25, 4:59 AM

Assuming that the DO is not processing any other requests in between, will a 1second alarm interval always execute as close to 1000 milliseconds as possible (also assuming everything else in the universe works as expected)? Has anyone benchmarked performance here? I have a counting timer that I want to synchronize between clients, my current process tells all clients when to start counting (providing a datetime ground truth), then each client handles their own timeouts to manage counting up. I would prefer to sync over WS but only if I can keep the interval as close to 1000ms as possible. The timer is used for tracking state in sports matches, so if each tick is more than 10ms out of sync then it'll add up very quickly

11984 Ford Laser Assuming that the DO is not processing any other requests in between, will a 1se...

PhoenixSpace•11/5/25, 5:33 AM

I would prefer to sync over WS

No idea about the timer precision (I'd imagine there is some variability there), but websocket jitter would be more then 10ms, right?

1984 Ford Laser•11/5/25, 5:43 AM

I'll be lucky to have more than 5 clients connected at a time, in my experience sending simple WS messages can be completed in single millisecond timeframes. I can also do an interval of under 1second (say 975ms) if I know I'm going to have a semi predictable delay with each tick (I do this currently with awful accuracy lmao)

11984 Ford Laser Assuming that the DO is not processing any other requests in between, will a 1se...

lambrospetrou•11/5/25, 9:36 AM

I don't know the numbers off my head, but I can easily see it breaching the 1s throughout the day. Also, keep in mind that a single retry starts with a 2s exponential backoff, so you already are way ahead of your limit there. That is if there is a possibility your handler will fail.

Llambrospetrou I don't know the numbers off my head, but I can easily see it breaching the 1s t...

Larry•11/5/25, 1:18 PM

Is this a troublesome use case for Alarms? Just by listening to people talk about on here, including you, I'm getting the feeling that anything less than a minute, might be troublesome?

LLarry Is this a troublesome use case for Alarms? Just by listening to people talk abou...

lambrospetrou•11/5/25, 2:00 PM

I know many users do Alarms with such low frequencies, I do a few seconds myself too, but requiring every second accuracy seems a very easy thing to go wrong, in my opinion.
At that rate the DO is always active anyway, so probably using a larger alarm and then setTimeout could give you more accuracy. The alarm would only be for making sure you get external retries in case of a crash.
At least that's my current approach for few things. But, as always it depends on the use-case. I don't know if there is a hard guarantee on alarm invocation time at the tens of milliseconds level.

NNeed_Not Am getting `error setting identifier TypeError: this.parent.setName is not a fun...

Need_Not•11/5/25, 5:29 PM

any idea about this?

Llambrospetrou I know many users do Alarms with such low frequencies, I do a few seconds myself...

gruntlord6•11/5/25, 6:00 PM

in general you need to be careful with alarms. Its very easy to accidentally have them loop with short timers or by having a memory error in something tied to an alarm. I generally do every 10 seconds if being in memory already would benefit the task or 30+ seconds if it doesn't or if I don't want to have a huge rush of requests

gruntlord6•11/5/25, 6:01 PM

I also use them all the time since its an extremly usefull way to handle long running tasks entirely in code, but its a double edged sword and can add complexity if not properly setup

gruntlord6•11/5/25, 6:05 PM

I haven't tried it yet, but if anyone is trying to do a lot with durable objects then its probably worth looking into using lumenize to have workers handle the actual fetch etc to be more efficient and save on billing https://lumenize.com/docs/proxy-fetch/

Proxy Fetch | Lumenize

Offload Requests to a Worker and/or a Durable Object and have it execute a handler when the fetch is done

Ggruntlord6 I haven't tried it yet, but if anyone is trying to do a lot with durable objects...

PhoenixSpace•11/5/25, 6:12 PM

(I think your link is malformed)

PPhoenixSpace (I think your link is malformed)

gruntlord6•11/5/25, 6:46 PM

you don't visit the .com root every day? Thanks

Llambrospetrou I don't know the numbers off my head, but I can easily see it breaching the 1s t...

1984 Ford Laser•11/5/25, 9:46 PM

Appreciate the discussion on this. My use case only needs to stay within a few seconds for around 30 minutes at a time. I'm also not fussed about forcing the DO active as it will only be for a few hours a week per DO (maybe 20 DO instances total) so not any decent scale. Sounds like I need to not stress so much about syncing every second, will have a bit of a think about it

1534980751438970153470891543•11/5/25, 10:04 PM

does the durable object jurisdiction param only matter upon creation

1534980751438970153470891543•11/5/25, 10:06 PM

i.e. create the DO with the eu jurisdiction param (once), then omit the param forever afterwards

1534980751438970153470891543•11/5/25, 10:07 PM

knowing this will either be a few or many lines of change

11534980751438970153470891543 i.e. create the DO with the eu jurisdiction param (once), then omit the param fo...

Hard@Work•11/5/25, 10:07 PM

I would just keep it, there isn't really a reason not to send it

1534980751438970153470891543•11/5/25, 10:08 PM

im just wondering if its redundant

11534980751438970153470891543 im just wondering if its redundant