Release Version 1

.changeset/README.md

@@ -0,0 +1,8 @@
+# Changesets
+
+Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
+with multi-package repos, or single-package repos to help you version and publish your code. You can
+find the full documentation for it [in our repository](https://github.com/changesets/changesets).
+
+We have a quick list of common questions to get you started engaging with this project in
+[our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md).

.changeset/absent-in-dev-honours-a-real-value.md

@@ -0,0 +1,16 @@
+---
+'devflare': patch
+---
+
+Correct what `.absentInDev()` promises. It said the key is "omitted entirely in dev"; what it
+actually does — and always did — is omit the key when NOTHING supplies a value. A value that is
+genuinely present still wins, in dev as everywhere else.
+
+That is the intended escape hatch: a developer who deliberately exports a sender to point their
+machine at a real one gets it. But the absolute phrasing invited the pairing that defeats the
+descriptor entirely — writing the value into `.env.public`, which is committed, so it reaches
+every checkout and hands the exact placeholder to every laptop the descriptor exists to withhold.
+The documentation now says both halves, and a test pins the behaviour so the warning cannot
+quietly become false.
+
+No behaviour change.

.changeset/bridge-app-route-websocket-forward.md

@@ -0,0 +1,28 @@
+---
+'devflare': patch
+---
+
+Fix `devflare dev`: forward app-route WebSocket upgrades to the app worker.
+
+In worker mode the dev gateway runs as the entry worker (`routes: ['*']`) with
+the app (e.g. SvelteKit) worker as a service binding. A browser opening
+`new WebSocket('/api/doc/:id/subscribe')` — whose handler does
+`return stub.fetch(clientUpgradeRequest)` and returns the Durable Object's `101`
+— never reached that handler: the gateway hijacked **every** unmatched WebSocket
+upgrade into its in-worker bridge RPC socket. The socket appeared to upgrade
+(`101`), but the app route never ran, so a DO's hibernation broadcast never
+crossed tabs and a second concurrent connection could not share the DO instance.
+
+This is distinct from the programmatic `stub.connect()` path fixed in the prior
+release; it is the path a Worker/SvelteKit route takes when it forwards a client
+WebSocket upgrade to a DO.
+
+The gateway now forwards an unmatched WebSocket upgrade to the app worker and
+passes its response through when the app answers with a genuine upgrade
+(`101` + a `webSocket`), so `stub.fetch(clientUpgradeRequest)` reaches the DO and
+its client socket streams back to the browser — two tabs then share one DO
+instance and `ctx.getWebSockets()` broadcasts (and `webSocketClose` leave frames)
+work. It falls back to the bridge RPC socket only when the app does not answer
+with an upgrade (the bridge client path, which exists only when there is no app
+worker). The `/_devflare/do-ws` connect() path, configured `wsRoutes`, and the
+native DO RPC path are unchanged.

.changeset/bridge-do-rpc-native-dispatch.md

@@ -0,0 +1,19 @@
+---
+'devflare': patch
+---
+
+Fix `devflare dev`: bridge Durable Object RPC **method** calls (e.g.
+`stub.push(arg)`, `stub.pull(since)`) when the DO also defines a custom `fetch()`
+handler.
+
+The local dev gateway routed every DO method call through the DO's `fetch()`
+using an internal `_rpc` convention. A DO that `extends DurableObject` and
+overrides `fetch()` — for example a websocket-only handler that returns `426`
+for non-upgrade requests — received that probe on its own `fetch()`, returned a
+non-JSON body, and the call failed with a bogus `... is not valid JSON` error.
+
+The gateway now dispatches method calls natively (`stub[method](...args)`) —
+exactly as on real Cloudflare, and matching what `devflare/test` already did —
+and only falls back to the `_rpc` fetch convention for Durable Objects that are
+not RPC-enabled. The `.fetch()`/WebSocket bridge paths are unchanged and still
+reach the user handler.

.changeset/bridge-do-websocket-fix.md

@@ -0,0 +1,24 @@
+---
+"devflare": patch
+---
+
+Fix the Durable Object WebSocket relay through the live dev gateway, and harden
+proxied-response limits:
+
+- **DO WebSocket `stub.connect()` was broken in both directions.** The live
+  gateway (`gateway-runtime.ts`) and the bridge client disagreed on the WS-data
+  wire format: the client sent/expected binary `WsData` frames while the gateway
+  only read string frames inbound and emitted a JSON `ws.data` envelope outbound,
+  so every payload was silently dropped. The gateway now speaks the same binary
+  `WsData` frame format as the client (matching `wire.ts`/`server.ts`) in both
+  directions, honoring the TEXT flag. Added an end-to-end integration test that
+  round-trips binary (both directions) and a text frame through the real gateway.
+- **Oversized proxied responses now throw a clear error** instead of being
+  silently truncated. DO and service-binding `fetch()` responses reached through
+  the bridge are delivered inline over the WebSocket and are capped at 512 KB
+  (workerd's ~1 MB message limit); a larger body now throws, with the boundary
+  documented in the Cloudflare support matrix. Large R2 objects remain exempt
+  (HTTP transfer side-channel).
+- The gateway handshake now advertises only the capabilities it actually
+  implements end-to-end (`ws-relay`, `http-transfer`); `streams` is no longer
+  advertised since proxied responses are inlined, not streamed.

.changeset/bridge-do-websocket-hibernation-broadcast.md

@@ -0,0 +1,31 @@
+---
+'devflare': patch
+---
+
+Fix `devflare dev`: relay a Durable Object's WebSocket-hibernation cross-socket
+broadcast.
+
+Two WebSocket clients connecting to the SAME DO instance
+(`env.DOC_ROOM.getByName(id)` twice) could not see each other's messages when the
+DO used the hibernation API (`ctx.acceptWebSocket()` with the runtime-dispatched
+`webSocketMessage`/`webSocketClose` handlers and a `ctx.getWebSockets()`
+broadcast). The upgrade succeeded (`101`) and both sockets landed on one instance
+(`ctx.getWebSockets().length` reached 2), but `webSocketMessage` never fired, so
+a frame sent by one client was never delivered to the other.
+
+Root cause: the bridge gateway pumped the DO's WebSocket **in-process** (it called
+`stub.fetch(upgrade)` and drove the returned client socket with
+`accept()`/`send()`). An in-process-pumped partner socket does not trigger
+workerd's hibernation dispatch — only a genuine inbound connection does. The
+`devflare/test` gateway had no DO WebSocket handler at all, so `stub.connect()`
+hung there.
+
+Durable Object `connect()` now opens a real pass-through WebSocket to a new
+`/_devflare/do-ws` gateway endpoint, which forwards the upgrade to the DO and
+returns its `101` response verbatim (the same pattern the browser WebSocket routes
+already use). miniflare then wires the inbound connection to the DO's client
+socket, so the runtime dispatches the hibernation handlers and delivers
+`ctx.getWebSockets()` broadcasts across every connected client — exactly as on
+real Cloudflare. Both the `devflare dev` and `devflare/test` gateways are covered.
+The single-socket WebSocket path, the legacy in-process relay (`createWsProxy`),
+and the native DO RPC path are unchanged.

.changeset/bridge-set-cookie-fidelity.md

@@ -0,0 +1,27 @@
+---
+'devflare': patch
+---
+
+Fix multi-`Set-Cookie` corruption when a response is relayed through the dev
+bridge.
+
+When a Durable Object or service-binding `fetch()` response set **more than one**
+cookie (e.g. a session cookie plus a CSRF cookie), the bridge flattened the
+response headers with `Headers.entries()`/`forEach()`. Per the Fetch spec's
+sort-and-combine, those APIs fold multiple `Set-Cookie` headers into a single
+comma-joined value, so the browser received one corrupted
+`Set-Cookie: a=1; Path=/; SameSite=Lax, b=2; Path=/; HttpOnly` — the second
+cookie was lost and the first mangled. This bit any response relayed via a
+service-binding or DO `fetch` through the local bridge whenever the gateway ran
+under a compatibility date before `2023-08-01` (where workerd still combines
+`Set-Cookie` and has no `getSetCookie()`).
+
+The bridge now enumerates `Set-Cookie` separately and carries each value as its
+own entry through serialize → deserialize (reconstructed with `append`, never a
+join), so every cookie survives byte-faithfully with all attributes intact. It
+reads cookies via the standard `Headers.getSetCookie()` and falls back to
+workerd's legacy `getAll('set-cookie')`; when a runtime exposes neither, the
+combined value is preserved verbatim rather than dropped. Both the workerd
+gateway (`GATEWAY_RUNTIME_JS`) and the host-side (`server.ts`) serialization
+paths are fixed, for `Request` and `Response` alike. Single-cookie and
+non-cookie headers are unchanged.

.changeset/bridge-superseded-socket-isolation.md

@@ -0,0 +1,30 @@
+---
+"devflare": patch
+---
+
+Stop a retried bridge connect from tearing down the connection it just established,
+and stop the SvelteKit handle from blaming a request's own error on the platform.
+
+**`BridgeClient` — a superseded socket could dismantle the live connection.** A refused
+socket rejects on `error` but stays alive until its `close` arrives, so a caller that
+retries in between replaces `this.ws` while the old socket is still wired to its
+handlers. Those handlers were unconditional: the abandoned socket's `close` ran
+`handleDisconnect()` — clearing `isConnected`, dropping the codec and rejecting every
+in-flight call on the connection that had just replaced it — while a late `open`
+installed a second codec over the live one, and either could clear another attempt's
+in-flight marker. The connect timeout, too, closed whichever socket was current rather
+than the one that attempt opened. Every handler now acts only while its own socket is
+still the client's, and settles its own attempt. Overlapping attempts were rare when a
+request connected once; `connectBridgeWithRetry` (added in the previous release) retries
+~20 times inside a single request, which makes them routine — so a bridge that blinked
+during an HMR reload could leave the client wedged rather than reconnected.
+
+**`devflare/sveltekit` — the platform fallback caught the whole request.** The `try` in
+`handle`/`createHandle` spanned both `createDevflarePlatform()` and `resolve(event)`, so
+an error thrown anywhere downstream was logged as `[devflare] Failed to create platform`
+— hiding the real cause behind a wrong diagnosis — and the request was then re-run via
+the fallback. That re-run repeated every side effect the first pass had already
+performed, and ran outside the request context devflare had established for it, so
+`getContext()`/`env()` throw during the retry. The fallback is now scoped to building the
+platform: a request that fails on its own merits propagates, once. A genuine platform
+failure still falls through to an unbridged `resolve()` exactly as before.

.changeset/browser-shim-port-flag.md

@@ -0,0 +1,23 @@
+---
+'devflare': patch
+---
+
+Let the local Browser Rendering shim be moved off 8788, via `--browser-shim-port` / `DEVFLARE_BROWSER_SHIM_PORT`.
+
+The shim is a listener of its own beside the Miniflare runtime, and its port was only reachable
+from `createDevServer()` — never from the CLI. So two `devflare dev` servers that both declared a
+`browser` binding collided on 8788 no matter how their runtime ports were arranged, which is
+exactly the multi-instance setup `--runtime-port 8788` and `DEVFLARE_DIR` otherwise make possible.
+8788 is also a popular port to have already taken, being one off the 8787 runtime default.
+
+Both dev commands now take the port:
+
+```bash
+bunx --bun devflare dev --runtime-port 8790 --browser-shim-port 8791
+DEVFLARE_BROWSER_SHIM_PORT=8791 bunx --bun devflare dev
+```
+
+`workspace dev` reads the same flag as the FIRST port of its per-app block (each app that binds
+browser rendering listens on that plus its index), which otherwise starts at 9700. The flag beats
+the environment variable, and either one is rejected with a clear error rather than quietly
+falling back when it is not a usable port. Unset, both commands bind exactly as before.

.changeset/browser-shim-puppeteer-1-1-endpoints.md

@@ -0,0 +1,29 @@
+---
+'devflare': patch
+---
+
+Serve the endpoints `@cloudflare/puppeteer` 1.1.0 and later actually call, so `puppeteer.launch(env.BROWSER)` works again.
+
+The local Browser Rendering shim was built against `@cloudflare/puppeteer` 1.0.x and still
+served only its URLs. 1.1.0 moved every one of them without a major bump, so a current client
+never reached the shim at all — `launch()` failed at the first call with
+`Unable to create new browser: code: 404: message: Not found`, which is the shim's own 404
+travelling back through the binding.
+
+| client  | acquire                       | devtools websocket                          |
+| ------- | ----------------------------- | ------------------------------------------- |
+| ≤ 1.0.7 | `GET /v1/acquire?…`           | `GET /v1/connectDevtools?browser_session=…` |
+| ≥ 1.1.0 | `POST /v1/devtools/browser?…` | `GET /v1/devtools/browser/<sessionId>`      |
+
+Both generations are now served, on one route table, so which client version an app pins stays
+the app's decision rather than devflare's.
+
+The same release also dropped the transport's chunk framing — up to 1.0.7 every CDP message
+travelled as binary frames behind a 4-byte length header, with a keep-alive ping each second,
+and from 1.1.0 it is plain unframed JSON. Fixing only the paths would therefore have moved the
+failure rather than removed it: the session would open and then the first `Browser.getVersion`
+would arrive wrapped in a header the client no longer unwraps. The binding worker now picks its
+framing from the path the client connected on, which is exactly as reliable a signal, the two
+having changed in the same release.
+
+`/v1/sessions`, `/v1/history` and `/v1/limits` never moved and are untouched.

.changeset/browser-shim-sessions-envelope.md

@@ -0,0 +1,17 @@
+---
+'devflare': patch
+---
+
+Return the browser shim's session and history lists in the envelope `@cloudflare/puppeteer` reads them from.
+
+`puppeteer.sessions(env.BROWSER)` and `.history(env.BROWSER)` both resolved to `undefined`
+against the local shim. The client does `JSON.parse(text).sessions` and `JSON.parse(text).history`
+— it has in every version it has shipped, and its own types say so (`SessionsResponse`,
+`HistoryResponse`) — while the shim answered with a bare array, so the field it looked for was
+never there.
+
+Unlike the endpoint move alongside this, that was never a version skew: it was equally wrong for
+every client. `/v1/limits` was already correct and is untouched.
+
+Anything reading `/v1/sessions` or `/v1/history` off the shim directly rather than through
+puppeteer now finds the array one field in.

.changeset/builtin-subpath-externals.md

@@ -0,0 +1,27 @@
+---
+"devflare": patch
+---
+
+Stop the `[UNRESOLVED_IMPORT] Could not resolve 'fs/promises'` warning that rolldown
+printed on every `devflare dev` start-up for a dependency that imports a Node builtin
+**subpath**.
+
+The bundler's external list was hand-maintained and named only ~20 bare builtins, so
+every subpath — `fs/promises`, `stream/web`, `stream/promises`, `timers/promises`,
+`dns/promises`, `util/types`, `assert/strict`, `path/posix`, … — fell through it, as did
+whole builtins the list never gained (`timers`, `process`, `worker_threads`,
+`perf_hooks`, `diagnostics_channel`, `http2`, …). A dependency only has to
+`await import('fs/promises')` in a Node-only branch, as `@cloudflare/puppeteer` does, for
+the worker-compat transform to hoist it into a static import and turn it into a warning
+on every build.
+
+The list is now derived from the runtime's own `builtinModules`, so it cannot drift from
+Node's builtin set again. Rolldown already externalized these specifiers after warning
+about them, so the bundle it writes is byte-identical — only the warning goes away.
+
+One behaviour change worth knowing: a bare builtin name now resolves to the builtin even
+when an npm package of the same name is installed. That was already true for `fs`,
+`path`, `stream`, `crypto`, `events`, `util`, `url`, `assert` and the rest of the old
+list; it now also holds for the builtins it missed, `punycode` among them. Packages that
+only a non-Node host reports as builtins — Bun lists `ws` and `undici` — are excluded, so
+they keep being bundled from `node_modules`.

.changeset/cf-binding-remote-preview-fields.md

@@ -0,0 +1,12 @@
+---
+"devflare": minor
+---
+
+Model the `remote` flag and preview/jurisdiction/migration fields on the core
+resource bindings. KV, D1, R2, queue producers, and service bindings now accept
+`remote?: boolean` (use the real remote resource during local dev), and KV
+(`previewId`), D1 (`previewDatabaseId`, `migrationsTable`, `migrationsDir`), and
+R2 (`previewBucketName`, `jurisdiction`) accept their preview/jurisdiction/
+migration fields — all compiled to the matching wrangler keys. R2 buckets and
+queue producers now accept an object form (`{ bucketName | queue, remote, … }`)
+in addition to the existing string shorthand, which keeps working unchanged.

.changeset/cf-cron-fetch-lint-secrets.md

@@ -0,0 +1,16 @@
+---
+"devflare": minor
+---
+
+Add build-time safety checks and cron validation. Cron expressions are now
+validated against Cloudflare's 5-field grammar (`src/config/cron.ts`) at
+config-parse time (a `.superRefine()` on `triggers.crons`) and in
+`cf.scheduled.trigger(cron)`, so a typo like `cf.scheduled.trigger('* * *')`
+fails with an actionable message instead of silently passing. The explicit
+2-arg fetch-handler style requirement is now also checked at dev-start / `build`
+time (`validateFetchHandlerStyle()` in the shared worker-load chokepoint),
+reusing the exact same resolver and style markers as the request-time check —
+zero false positives, with the runtime check kept as the backstop. Finally, a
+successful **production** deploy prints a one-line hint that runtime secrets are
+set via `wrangler secret put` / the dashboard (devflare never sends secret
+values to Cloudflare); the hint never fires on preview or dry-run deploys.

.changeset/cf-deploy-lifecycle.md

@@ -0,0 +1,11 @@
+---
+"devflare": minor
+---
+
+Add deploy-lifecycle parity. `devflare deploy --prod --percentage <n>` performs a
+gradual/canary rollout (uploads a new version with `wrangler versions upload`,
+then shifts `<n>%` of traffic to it via `wrangler versions deploy <id>@<n>`, with
+an optional `--version` to pin the version keeping the remainder) — production
+only, never shifting traffic on preview/dry-run. New `devflare tail` command
+streams a deployed worker's live logs over Cloudflare's tail API (`--format
+pretty|json`, clean teardown on exit).

.changeset/cf-local-dev-wiring.md

@@ -0,0 +1,11 @@
+---
+"devflare": minor
+---
+
+Wire deploy-modeled-only bindings into local development. Analytics Engine now
+binds in local dev (Miniflare's write-only no-op stub, so `writeDataPoint()` no
+longer throws), tail consumers are delivered locally when the consumer Worker is
+present in the same dev instance (the tail handler was already testable via
+`cf.tail.trigger()`), and the mTLS `remote` flag is forwarded to the local
+binding so deploy and local dev agree on the binding shape. Wired consistently
+across the dev server, the cross-process bridge, and the test context.

.changeset/cf-stale-claims.md

@@ -0,0 +1,10 @@
+---
+"devflare": patch
+---
+
+Correct stale offline-support classifications. Durable Objects and Service
+bindings are no longer mislabelled "no offline support" — they run fully locally
+under `createTestContext()` (Miniflare executes the DO class / resolves the
+service binding), classified honestly as offline-native with the caveat that
+there is no pure in-memory `createMockEnv()` mock for them. (Vectorize was
+reclassified to an offline fixture in the previous release.)

.changeset/cf-stream-vpc-flagship-bindings.md

@@ -0,0 +1,14 @@
+---
+"devflare": minor
+---
+
+Add first-class support for three more Cloudflare bindings: **Stream**
+(`bindings.stream`), **VPC** (`bindings.vpcServices` / `bindings.vpcNetworks`),
+and **Flagship** (`bindings.flagship`). Each is schema-validated, compiled to the
+matching wrangler keys (`stream`, `vpc_services`, `vpc_networks`, `flagship`),
+typed on the generated `env`, and documented in the support matrix. Stream runs
+locally through Miniflare with a deterministic pure mock (`createMockStreamBinding`)
+for hosted operations; Flagship has a configured-value pure mock
+(`createMockFlagshipBinding`) — its local Miniflare plugin returns call defaults,
+not evaluated flags; VPC services/networks are a remote boundary (Miniflare only
+proxies them) testable via a custom fake injected through `createMockEnv`.