Skip to content

Add examples/worker-javascript - #36

Open
aron-cf wants to merge 2 commits into
stack/1-rename-worker-backendsfrom
stack/2-worker-javascript-example
Open

Add examples/worker-javascript#36
aron-cf wants to merge 2 commits into
stack/1-rename-worker-backendsfrom
stack/2-worker-javascript-example

Conversation

@aron-cf

@aron-cf aron-cf commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

The worker-shell backend has an example that shows how to drive it from a Durable Object, but the worker-javascript backend had none, so there was no worked reference for running a JavaScript module in a Worker isolate. This change adds an examples/worker-javascript that mirrors the shell example beat for beat: the same Durable Object class, the same HTTP routes for writing files, reading them back, and running code, and the same R2 mount. Where the shell example runs a command, this one runs a JavaScript module and returns the value the module produces.

Running a module with a structured input value and getting a structured value back is a different contract from a shell, which takes argv and stdin and returns a stream of bytes. To model that difference honestly, this change adds a callable capability to the backend interface. A callable backend is one you can hand a structured argument and that returns a structured value. The runtime router gates the input option on this declared capability rather than on the kind of backend, so the two axes stay independent: a shell backend that chose to accept structured input could also be callable. A call that passes input to a backend that is not callable now fails with a clear message.

Verify by running the example under wrangler dev and posting a module to its exec route, or run the router unit tests with npm test --workspace @cloudflare/computer. The example is listed in the project layout documentation.

aron-cf added 2 commits July 31, 2026 21:52
Mirror the worker-shell example with a Durable Object whose Workspace
runs an ECMAScript module in a Dynamic Worker through the
WorkerJavaScriptBackend. The DO class, HTTP routes, and R2 mount match
worker-shell; the difference is the backend and what exec runs.

The backend takes only the Loader binding, needs no
WorkspaceServiceProxy loopback, and requires waitUntil, so the DO
passes ctx.waitUntil.bind(ctx) into the Workspace options. The exec
route accepts a module source plus an optional structured input and
returns the run's status, streams, and the module's structured value.

List the new example in the project layout doc.
The runtime rejected structured input for any command-routed backend,
conflating two independent questions: which downstream surface a
backend speaks, and whether it accepts a structured input value and
returns a structured result. A shell backend that coerced JSON to
argv and parsed stdout back to a value could not opt in.

Add an optional callable capability to the backend interfaces, default
false. The WorkerJavaScriptBackend declares it true. The runtime router
now gates input on a callableBackendIds set built from that capability,
independent of command-versus-module routing, and reports a clearer
"not callable" error.
@pkg-pr-new

pkg-pr-new Bot commented Aug 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/computer/@cloudflare/computer@36

commit: 042ad76

function errorJSON(error: unknown, status: number): Response {
const message = error instanceof Error ? error.message : String(error);
const code = (error as { code?: string }).code;
return new Response(JSON.stringify({ error: message, code }), {
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants