Brett can PM you the link, i dont know if i can share the same info. But im using the rest api to get list of DO objects, works well but is not "very fast"... depending of your requirements maybe just be simple to make you own list.

This same concept is also part of the nodejs module resolution. Thats nor pretty but i cant call that a antipattern considering the is very common and is the default resolution from the biggest js runtime out there. Anyway, you can just rename the output as part of your build step. Personally, im using the ESBuild bundle, so i just ask to output a .mjs file, but i can understand that other bundlers may need a rename. Anyway, i do think that request can be made on the wrangler github issues section, appear to be a simple adjustment.

Sure, but why do it if it's not necessary? Just because Node does it? With Deno on the horizon there is absolutely no reason in trying to not be browser compatible.

We need to distinguish between the types somehow. The HTTP upload API allows each module's content-type to be specified explicitly. But, Wrangler needs some way to know what type each file is. For now, it uses the file extension to figure it out. However, you're welcome to propose a change to Wrangler that lets it figure out the file type some other way.

feel free to pm the link

I just got: workers.api.error.max_durable_object_namespaces_exceeded [API code: 10067]

What is the limit?

@User 20

Ops... Okay!

Thats will increase in the future right? I setup a 3 stage test system. And the script has 8 DO ... so i need will reduce on only basic two step (prod/dev) until that, also, i need to avoid the creating more than 2 new DOs xD

Aren't you using 3 wrangler environments?

My wrangler.toml is dynamic generate as part of my deploy script. I assumed the effect was be the same.

Whoa 20? quite a bit less than unlimited : )

I'd assume you get 20 namespaces per environment

Number of objects is unlimited. Number of namespaces (i.e. classes) is limited. Though I'm a bit surprised the limit is 20, that seems like something we should increase.

When i list my namespaces using the rest-api, i only get id/name/script/class theres no info about the environment; I just tested using the --env and the effect is the same, as the each env is also another new script.

I dont know exactly what can be a reasonable number, but if the intention is to have several small DOs, i was expecting something like 300 (i.e 30 scripts x 10 DOs) ... I do not plan to use that number but was just my expectation.

I think KV also started out with a 20 limit, but is now 100. Just for reference.

How do environments affect that number? I'd think if my script has 20 different DOs I could still separate testing from production by deploying them into different environments, right?

the current namespace limit is due to the storage limit - not much use in each DO having 10 GB of storage if you can make 100 of them 🙂 We're looking to lift this.

Today the limit is account-wide. We're making some changes to environments that would give you the behavior you expect.

But the 10GB is account-wide, not for each namespace; So if we have 10/20/1000 namespaces the total limit is the same....

Thanks for clarifying. Don't we specify the entry point module in the

wrangler.toml

? I think I read something about the

main

key or something like that. Wouldn't that be enough to indicate that it is a module?

You actually can change it today, it's just the default to use .mjs

Or it should be that way...

I believe a rule like this in your wrangler.toml will be enough to make every .js file a module

toml
[[build.upload.rules]]
type = "ESModule"
globs = ["**/*.js"]

Yea must be a wrangler thing. The http upload api uses content-type = application/javascript+module in the multipart request body

I suppose it'd be possible to assume the main module is ES syntax, but then people might be confused why their main module is allowed to be

.js

but all other modules have to be

.mjs

...

By other modules you mean for the same worker? Since an ES module can't import commonJS modules. If the entry point is ES module, so must all dependencies... Or what am I missing?

Is it possible / wise to do fetch requests in the constructor of the Durable Object? E.g. when a durable object is (re)-created, I want to update some information (mainly the location / colo of this durable object) in our database.