Under the hood Bindings

How Devflare wires Durable Objects from config to runtime

Durable Object bindings normalize into a stable binding shape, compile into Wrangler , and participate in Devflare’s own DO bundling path.

This is one of the places where Devflare feels the most application-aware. It is not only compiling config — it is discovering DO classes, bundling them, and keeping local runtime behavior coherent.

Normalization: Local strings, explicit objects, and cross-worker refs normalize into one DO binding model
Compile target: Wrangler
Preview note: DO apps often need branch-scoped preview workers instead of same-worker preview URLs

Devflare normalizes the authored shape before it does anything louder

DO bindings accept a string, an explicit object, or a cross-worker reference produced by . Devflare normalizes those into one internal shape before later steps inspect them.

That normalized shape is what lets config, compiler, and test-context setup all speak the same language even when a DO comes from another worker package.

Durable Objects from authored config to generated output

Keep the binding readable in source, then inspect only the Wrangler-facing slice Devflare emits when the config is compiled.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'chat-worker',

files: {

durableObjects: 'src/do/**/*.ts'

bindings: {

durableObjects: {

ROOM: 'ChatRoom',

LOCK: { className: 'WriteLock' }

}

})

Local runtime support depends on what Devflare can model directly

The local test context can auto-detect cross-worker DO refs and stand up the required multi-worker Miniflare shape for them.
The DO bundler discovers classes from , emits worker-compatible code, and even handles special cases like usage.
Tests can use the normal DO namespace ergonomics instead of a custom fake API surface.

Compile, preview, and cleanup behavior

Compile emits and optional for each binding, which is what Wrangler-facing output expects.
Cross-worker DO references are resolved before compile output is treated as final.
Preview and deploy workflows need to respect real DO migration and preview caveats instead of pretending the platform limitations disappeared.

This is where Devflare earns its keep

If a tool cannot keep DO authoring, local runtime, and test setup coherent, DO-heavy apps get painful fast. Devflare’s value is that these pieces stay part of one story.

Durable Objects

Devflare treats Durable Objects as a real first-class surface in config, local runtime, and tests, not as an awkward plugin hanging off the side of the worker.

Testing Durable Objects

Durable Objects are well-supported in the default Devflare harness, which means you can test real object behavior without hand-building a fake namespace first.