feat(cloudflare-runtime): local send_email stub that logs under alchemy dev - #76
Merged
Merged
Conversation
…s typed error/requirement channels The dts bundler cannot name the inferred Credentials requirement from @distilled.cloud/cloudflare and degraded make/layer (and everything composed from them, e.g. RuntimeServices.layerRuntime) to any/any. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…my dev Add SendEmail.local alongside SendEmail.remote: a wrapped-binding stub (send-email.worker.ts) whose send() logs the message metadata (from/to/ subject) and resolves instead of delivering, mirroring analytics-engine's local no-op. This lets a consumer default send_email to log-in-dev and opt into the real remote binding explicitly, matching Miniflare/Wrangler behavior. Reuses the cloudflare-internal:email EmailMessage shim.
Contributor
Author
|
@sam-goodwin I think this is in good shape, how about you? |
Contributor
|
@john-royal please review this |
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
3 participants
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.
Adds
SendEmail.localalongside the existingSendEmail.remote, plus asend-email.worker.tswrapped-binding stub. Under a local runtime (e.g.alchemy dev),env.<binding>.send(...)logs the message metadata (from / to / subject) and resolves, instead of proxying to the deployed binding and delivering real mail.Why
Today the only
send_emailvariant isremote(...), which proxies to the deployed binding — so a Worker run locally sends real email from the production domain on everysend()in the dev loop, with no local stub to fall back to. This surfaced downstream in alchemy: see alchemy-run/alchemy#865, where the first fix was just a docs warning that "send_email is live under alchemy dev." @john-royal noted that Miniflare/Wrangler insteadconsole.logthe message unless you opt into the real remote binding, and suggested implementing that. This PR is the runtime half.How
send-email.worker.ts: a minimal stub whosesend()logsfrom/to/subject(when present) and resolves. Mirrors the no-opanalytics-engine.worker.tsstub, but logs rather than discards so the dev loop still shows what would have been sent. Handles both the builder-form message and a pre-builtEmailMessage.SendEmail.ts: registers the stub as a second internal extension module inSendEmailLive(alongside the existingcloudflare-internal:emailEmailMessageshim, reused unchanged), and addsexport const local(props)that points a wrapped binding at it — same shape asremote(props).Consumer side
The alchemy side (separate PR, ready to open once this lands and a cloudflare-runtime version bump exists) defaults
send_emailto.localunderalchemy devand adds thedev: { remote: true }opt-in that selects.remote— the flag shape agreed in alchemy-run/alchemy#865.Verification
bunx --bun tsdownbuilds clean (worker + node outputs, dts includesdeclare const local),tsc -bpasses, oxlint/oxfmt clean.