Add add support for email bindings in Local Explorer

[kierzniak]

Local Explorer covers KV, R2, D1, Durable Objects, and Workflows, but not email bindings. Right now, when a Worker sends an email during local dev, it gets written as an .eml file to a temp directory and the path is logged to the terminal. It works, but it's clunky. You end up copying paths out of logs every time you want to check what got sent, and there's no good way to assert against captured emails in tests.

It would be really nice to just open the email view in Local Explorer and see a list of what's been sent (or forwarded / replied to from an email() handler), click into one, and see the headers, body, and attachments. The same API could back E2E tests too. I'm thinking Playwright or Vitest checking things like "did the signup flow actually send the welcome email, and did it go to the right address?" without needing to deploy or mock out a real mail server.

I'm happy to implement this and send a PR. Just wanted to check first in case the team already has something in flight or would prefer a different shape.

For the implementation I'd roughly follow the patterns already in the repo: persist captured emails alongside the other bindings' state so they stick around between dev sessions, add list/get/delete endpoints to the Local Explorer API, and build list + detail views in the UI based on how the existing bindings render.

[patsaas]

I agree, a view in Local Explorer would be great for emails.

My related request re: E2E testing to store email files in a project's .wrangler directory instead of the system tmp directory:
#13809

[emily-shen]

Hey! Its on our roadmap (along with other handlers like queues, cron triggers etc.) but nothing actively in development so if you wanted to, a PR would be very welcome!

I need to improve the contributing docs for the local explorer, but what you've said is basically it. One thing that might not be immediately obvious is that we filter out local openapi spec off the main one here. We'd want to implement the POST endpoint to send emails, but there isn't anything for listing so you can make one up for that and stick it in miniflare/scripts/openapi-filter-config.ts.

I'd leave the persistence across dev sessions alone for this piece of work, but we can definitely consider that separately (I'll respond to that in #13809). You can access the tmp directory right now by adding the email disk service binding to the explorer worker.

It's a fair chunk of work though, so no pressure :)