When i can use durable objects service?

Hopefully sometime in the near future! If you haven't already, please fill out a request to join our closed beta (https://www.cloudflare.com/cloudflare-workers-durable-objects-beta/). We're also working hard and excited to launch our open beta soon!

Some more feedback off of the conversation earlier in #808377982858166342: When uploading modules, if there is a problem with the script, the current error message looks something like:

json
{
  "result": null,
  "success": false,
  "errors": [
    {
      "code": 10021,
      "message": "Uncaught ReferenceError: MyDurableObjectClass is not defined\n  at line 0\n"
    }
  ],
  "messages": []
}

or

Uncaught ReferenceError: default is not defined\n  at line 0\n

when not using DO. "problem with the script" here means that there is a reference to an undefined global. When a script gets uploaded to Cloudflare, you're obviously executing it, to try and import the modules (MyDurableObjectClass or default) which we export in the script. This error message tells us that something went wrong, but not where the problem in our script actually is. If I include a

console.log(process.env.NODE_ENV)

or

console.log(setImmediate)

somewhere in my script, all I get back is the ReferenceError. If I was entirely writing the script myself, that's not really a problem, because I would know that those globals don't exist. However, a lot of external library packages do things such as:

if (process.env.NODE_ENV === "production") {} else {}

or

const someFunc = setImmediate || setTimeout

And the upload process just completely fails if you try to include them. To work around it, I'm using a Rollup plugin,

@rollup/plugin-replace

to replace these global references with

"production"

or

undefined

or similar, but to first identify which variables I need to swap out, I have to manually search through the built script (100,000s of LOC) to find them, because the error message on upload doesn't tell me. Is there any way this message could be improved to instead throw a ReferenceError for the missing global?

A minimal example:

typescript
console.log(someMadeUpGlobal)

export default {
  fetch: async (request) => new Response("Hello")
}

gives "ReferenceError: default is not defined" rather than "ReferenceError: someMadeUpGlobal" is not defined.

cc @User

Thanks for digging into this! Agreed, we should show a better error there. Also, definitely feel the pain about importing modules with Node-isms. I've been working on a Rollup config, let me share it and see if it makes your experience easier. https://gist.github.com/Electroid/7d55c0023fe6ef3277f7c4fe361a58f0

Oh that very well might just do the trick for a lot of the problems I've come across!

I'll try swapping that config out for my own and see if it still deploys. Gimme a 10 mins or something to wrap up something.

That will still minify to 1 file. But once https://github.com/cloudflare/wrangler/pull/1764 is merged, you'll be able to set

preserveModules

to

true

, and the file structure of your project will be preserved.

And this becomes the end result. All your dependencies become ESM-ified

I saw that was possible when I was messing around with the publish script of the chat demo (now I'm just using wrangler). Why would I want to publish them all individually? Any particular reason?

Wait, what. Wasn't expecting all the node_modules to be individual too. That's really interesting. But my question still stands—is there any benefit to this?

I think there's some readability benifits, also stacktraces. But, of course, some will still want to minify and that's ok too

I was suprised to find out

is-odd

requires

is-buffer

! Like.. huh?

Using this as my config:

javascript
import { terser } from 'rollup-plugin-terser'
import replace from '@rollup/plugin-replace'
import { nodeResolve } from '@rollup/plugin-node-resolve'
import commonjs from '@rollup/plugin-commonjs'
import typescript from '@rollup/plugin-typescript'
import json from '@rollup/plugin-json'
import nodePolyfills from 'rollup-plugin-node-polyfills'
import nodeGlobals from 'rollup-plugin-node-globals'
import dynamicImportVars from '@rollup/plugin-dynamic-import-vars'

export default {
  input: './src/index.ts',
  output: {
    exports: 'named',
    format: 'es',
    file: './dist/index.mjs',
    sourcemap: false,
  },
  treeshake: {},
  plugins: [
    // replace({
    //   'process.env.NODE_ENV': JSON.stringify('production'),
    //   'process.nextTick': undefined,
    //   setImmediate: undefined,
    //   process: '({})',
    // }),
    typescript(),
    nodeResolve({ browser: true }),
    commonjs({
      transformMixedEsModules: true,
    }),
    json(),
    nodePolyfills(),
    nodeGlobals(),
    dynamicImportVars({ warnOnError: true }),
    // terser({
    //   ecma: 'ESNext',
    //   output: {
    //     comments: false,
    //   },
    // }),
  ],
}

Gives a brand new error that I've never seen before:

json
{
  "result": null,
  "success": false,
  "errors": [
    {
      "code": 10021,
      "message": "Uncaught Error: No such module.\n  at line 0\n"
    }
  ],
  "messages": []
}

Uncommenting the

replace

plugin then deploys successfully as before. Haven't got time to dig into finding exactly what's missing from that config you gave me right now, but I will do later 🙂 Thanks for your help @User

Yea, I know why you see that. You would need to use my branch of wrangler in that PR.

Oh, trying that now then...

Hmm, same error. Wrangler definitely rebuilt, so not sure what could have happened.

No worries—what I've got works at the moment 🙂

Ah intersting. thanks for trying it out!

Possibly (probably) because I wasn't totally strict about using your exact config? I just tried to jam in most of the plugins you had into mine. Very likely my fault.

iirc, you'll need to make sure your output files end in

mjs

Yeah, I just have it configured to give a single output:

./dist/index.mjs

.

quick question: is there any way to know which PoPs currently support DOs? > However, not all Cloudflare locations support Durable Objects yet today, so the object may not be located in exactly the same PoP where it was requested. (from https://developers.cloudflare.com/workers/learning/using-durable-objects)

Not at present. Why do you ask?

just curious... i didn't realize that string-based DOs were chosen by hash not by request PoP, and when i moved some KV-related logic from a worker into a DO the cache lag went way up.

(the answer here is to keep the KV logic in the worker, not in the DO, but it made me curious to know if my DOs are local are not. i'm closest to the Osaka PoP, FWIW)

anyway, this "limitation" made me write better code, so 👍.

FWIW, as of a couple weeks ago, string-derived DOs will actually be created in the closest storage colo, but still require synchronizing with the colo chosen by hash if the object is new

essentially they are migrated immediately on creation