fix(devframe): forward allowedOrigins through createDevServer - #230
Open
dvcolomban wants to merge 1 commit into
Open
fix(devframe): forward allowedOrigins through createDevServer#230dvcolomban wants to merge 1 commit into
dvcolomban wants to merge 1 commit into
Conversation
CreateDevServerOptions had no allowedOrigins field, and createDevServer never forwarded one into its initDevframe(...) call, even though the lower-level initDevframe/initiate.ts already accepts allowedOrigins and the WS transport underneath already implements the full WsOriginRegistry check. Passing allowedOrigins to createDevServer was either a type error or a silent no-op depending on the call site. Adds the field to CreateDevServerOptions (documented the same way as initiate.ts's own field) and forwards it into the initDevframe call. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
✅ Deploy Preview for devfra ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull request overview
This PR fixes an options “drop” in the devframe dev-server adapter by adding allowedOrigins to CreateDevServerOptions and forwarding it into the underlying initDevframe(...) call, enabling consumers to configure the existing WS origin gate through the primary createDevServer API.
Changes:
- Extend
CreateDevServerOptionswithallowedOrigins?: readonly string[] | WsOriginRegistry | falseand document its behavior. - Forward
options.allowedOriginsthroughcreateDevServerintoinitDevframe. - Add end-to-end adapter tests covering default, array allowlist, and
WsOriginRegistry-gated origin behavior; update the public API snapshot accordingly.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tests/snapshots/tsnapi/devframe/adapters/dev.snapshot.d.ts | Updates the public API snapshot to include allowedOrigins on CreateDevServerOptions. |
| packages/devframe/src/adapters/dev.ts | Adds the allowedOrigins option to the dev-server adapter options and forwards it into initDevframe. |
| packages/devframe/src/adapters/tests/dev.test.ts | Adds integration tests validating origin checks for default behavior, explicit allowlists, and WsOriginRegistry registration flow. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Not a new capability —
initDevframe/initiate.ts(packages/devframe/src/adapters/initiate.ts) already accepts and fully plumbsallowedOrigins?: readonly string[] | WsOriginRegistry | falsedown to the WS transport's origin check (ws-server.ts), which already implements the fullWsOriginRegistrycheck.createDevServer(packages/devframe/src/adapters/dev.ts) is a thinner adapter built on top ofinitDevframe, and it simply never declared or forwarded this already-existing option into itsinitDevframe(...)call. PassingallowedOriginstocreateDevServertoday either throws a type error or is a silent no-op depending on how loosely the call site is typed —createDevServerwas the one seam in the chain dropping it.This adds
allowedOriginstoCreateDevServerOptions(documented the same way asinitiate.ts's own field, including theWsOriginRegistryescape hatch and thefalse"disables the check entirely, not recommended" caveat) and forwardsoptions.allowedOriginsinto theinitDevframe({...})call — pure plumbing, no new runtime behavior.Why this matters
createDevServeris the adapter most CLI/dev-server consumers reach for directly. Anyone reaching the tool from another host (LAN, tunnel) or wiring aWsOriginRegistryfor external viewer registration currently has no first-party way to configure that throughcreateDevServer— only through the lower-levelinitDevframe, which most consumers don't call directly.Tests
Three new cases in
packages/devframe/src/adapters/__tests__/dev.test.ts:allowedOriginsis omittedWsOriginRegistryobject gates the upgrade end to end — connecting before registration is rejected, then registering the viewer origin through the registry lets the same connection throughAll assert via a real WS connect/close outcome, not by inspecting
isAllowedcall counts, matching the existing origin-check tests inws.test.ts.pnpm lint && pnpm knip && pnpm test && pnpm typecheck && pnpm buildall pass.