Deno / Vercel Edge / Netlify Edge#

Roadmap for the three additional edge adapters in @mandujs/edge. All three are scaffolded stubs today — directory structure, handler factory signatures, and accessor exports are in place, but the bodies return CLI_E214 (not-implemented) until Phase 15.2 / 15.3 land.

Shipped today. Cloudflare Workers — see cloudflare-workers.mdx.

Scaffolded stubs#

packages/edge/src/
├── workers/          # shipped (Phase 15.1)
├── deno/             # stub — Phase 15.2
├── vercel/           # stub — Phase 15.2 (Edge Functions path)
└── netlify/          # stub — Phase 15.3

Each subpackage exports:

// packages/edge/src/deno/index.ts (today)
export function createDenoHandler(
  manifest: RoutesManifest,
  opts?: HandlerOptions,
): Handler {
  throw new CliError("CLI_E214", "Deno Deploy adapter is not yet implemented");
}

export function getDenoEnv(): DenoEnv | undefined {
  return undefined;
}

export function getDenoCtx(): DenoServeCtx | undefined {
  return undefined;
}

The signatures match what the final implementation will expose — you can already write against them if you want your app to light up the moment 15.2 lands.

Shape parity#

All four edge adapters (shipped + coming) follow the same contract:

The name differs per runtime because each exposes a different native context object (Deno's ServeCtx, Vercel's RequestContext, etc.), but the shape is the same: "accessor that returns the runtime's context if available, else undefined."

Polyfill mapping — identical#

All four edge adapters share the same polyfill table for Bun-specific APIs. The table is in the edge index.

This means an app that runs on Cloudflare Workers today will, once the other adapters ship, run unchanged on Deno Deploy / Vercel Edge / Netlify Edge — modulo runtime-specific binding differences (Deno KV vs Cloudflare KV, etc.).

Phase timeline#

Estimates are not dates — they track ordering, not calendar weeks. See docs/bun/phases-4-plus.md in the Mandu repo for the full Phase plan.

What you can do today#

Write against the scaffolded exports#

Import the stub — it'll compile, and your code is ready to run when the adapter ships:

import { getDenoEnv } from "@mandujs/edge/deno";

export async function handler() {
  const env = getDenoEnv();  // returns undefined until Phase 15.2
  // ...
}

Use Workers today, migrate later#

Pick Workers now. The accessor pattern is identical, so swapping:

// Before
import { getWorkersEnv } from "@mandujs/edge/workers";

// After (Phase 15.2)
import { getDenoEnv as getWorkersEnv } from "@mandujs/edge/deno";

is a one-line change per file — plus the wrangler.toml → Deno deploy config swap.

Deploy Deno via mandu deploy --target=docker#

If you need Deno today, you can bypass the edge adapter and deploy a traditional Deno process via Docker:

# Run the Mandu app under `deno run` instead of bun run
mandu deploy --target=docker
# Then edit the emitted Dockerfile to use `denoland/deno` and `deno run`

This loses edge cold-start advantages but gets you Deno compatibility until Phase 15.2 ships.

Contributing#

The stubs are in place specifically to make the contribution surface clear. If you want to help ship Phase 15.2 / 15.3:

1. Read packages/edge/src/workers/index.ts in the Mandu source — the reference implementation.
2. Mirror the structure in packages/edge/src/deno/ or vercel/ or netlify/.
3. Run bun test packages/edge/ — the tests describe the expected behavior.
4. Open a PR referencing the tracking issue in the Mandu repo.

Common errors#

CLI_E214: Deno Deploy adapter is not yet implemented — you're calling a stub. Wait for Phase 15.2 or use Cloudflare Workers today.

Type errors against getDenoEnv despite the import resolving — the stub's return type is DenoEnv | undefined, so TypeScript complains about unchecked access. Guard with if (env) or use non-null assertion (env!) if you're sure the runtime is ready.

🤖 Agent Prompt#

Apply the guidance from the Mandu docs page at https://mandujs.com/docs/edge/deno-vercel-netlify to my project.

Summary of the page:
Deno/Vercel/Netlify Edge adapters: currently scaffolded stubs under `packages/edge/src/{deno,vercel,netlify}/`. Phase 15.2 will complete Deno and Vercel Edge; Phase 15.3 Netlify Edge. API shape mirrors workers adapter: createXHandler(manifest, opts) + getXEnv()/getXCtx() accessors. Polyfill mapping identical — WebCrypto + web-standard fetch.

Required invariants — must hold after your changes:
- All three adapters (deno, vercel-edge, netlify-edge) currently export stub factories — calling them returns CLI_E214
- API surface will mirror `@mandujs/edge/workers` — `createXHandler(manifest, opts)` + `getXEnv() / getXCtx()` accessors
- Polyfill mapping is identical to Workers — WebCrypto, web-standard fetch, no Bun APIs at runtime
- Phase 15.2: Deno Deploy + Vercel Edge complete
- Phase 15.3: Netlify Edge complete

Then:
1. Make the change in my codebase consistent with the page.
2. Run `bun run guard` and `bun run check` to verify nothing
   in src/ or app/ breaks Mandu's invariants.
3. Show me the diff and any guard violations.

Related#

• Edge — Cloudflare Workers — the reference implementation.
• Edge index — polyfill mapping across all four adapters.
• Deploy — Netlify — for Netlify today (Node Functions path; Edge Functions in Phase 15.3).
• Deploy — Vercel — for Vercel today (Node Functions path; Edge Functions in Phase 15.2).

For Agents#

{
  "schema": "mandu.edge.roadmap/v0.24",
  "shipped": ["workers"],
  "phase_15_2": ["deno", "vercel-edge"],
  "phase_15_3": ["netlify-edge"],
  "stub_error_code": "CLI_E214",
  "shape_parity": {
    "handler_factory": "createXHandler(manifest, opts)",
    "env_accessor": "getXEnv() -> XEnv | undefined",
    "ctx_accessor": "getXCtx() -> XCtx | undefined"
  },
  "rules": [
    "Calling a stub handler throws CLI_E214 — treat as 'not-implemented', pick Workers today",
    "API signatures are final — safe to code against today",
    "Polyfill mapping is identical across all four adapters — migration is import-rename only"
  ]
}