Laravel Mail Preview Laravel Package

Product Decisions This Supports

• Email template iteration speed (feature & roadmap): Because the package captures every outgoing mail as both .html and .eml on disk, it compresses the design-review loop for transactional emails (receipts, password resets, onboarding, notifications). PMs can decide to invest in richer email templates knowing the review cycle is same-hour, not same-sprint.
• Build vs. buy for email previewing: This is a small, MIT-licensed, single-purpose driver. It replaces ad hoc "send to a Mailtrap/Mailhog inbox" or "add a debug route" workarounds without a vendor contract — a clear buy (or, more precisely, adopt) decision versus building an in-house preview harness.
• QA and release-readiness gating: The SentMails facade enables content assertions (assertLastContains, assertSent, assertCount, assertNothingSent) that Laravel's Mail::fake cannot do because fakes do not render mailables. That turns "the welcome email looks right" from a manual QA checklist item into an automated CI check — a direct input to release-gate policy.
• Environment-scoped rollout: Defaults to enabled => env('APP_DEBUG', false), so the decision "preview in local/staging only, never production" is enforced by configuration, not convention. This is the kind of guardrail that reduces the blast radius of an accidental config copy.
• Onboarding and developer experience: The overlay link appears on any web response when mail is sent, which shortens the time for a new engineer or contractor to see the emails their code produces — relevant to a "can we onboard faster" initiative.
• Use cases: local development of mailables, staging demos to stakeholders (open the .eml in a real client for accurate rendering), regression tests on email copy (legal disclaimers, pricing, unsubscribe links), and post-refactor verification that recipients/CC/BCC wiring did not change.

When to Consider This Package

Adopt when:

• The product ships Laravel transactional email that changes frequently and is reviewed by non-engineers.
• You want preview artifacts without standing up a third-party mail-capture service or a persistent inbox.
• You need automated assertions on rendered email content (subject, body substrings, To/CC/BCC) in tests, not just "was a mailable dispatched."
• You want a zero-vendor, MIT-licensed dependency with an active release cadence (Laravel 9 through 11 support, recent maintenance, Spatie stewardship after the transfer from themsaid).

Look elsewhere or add caveats when:

• Production-adjacent risk matters: The preview transport writes to disk. It must be scoped to non-production APP_DEBUG environments; any deployment that runs with debug on in production becomes a data-retention and PII-hygiene concern. Pair adoption with an explicit config audit.
• You need a full email platform: This is not Mailtrap, Mailgun, or Postmark — no deliverability analytics, no bounce handling, no template management UI, no inbox collaboration. If stakeholders need shared review links or design approval workflows, budget for a hosted solution instead.
• Your test strategy leans on Mail::fake: Existing suites would need to migrate assertions to the SentMails facade, which is an incremental cost and a new testing idiom to document.
• Ecosystem risk tolerance is low: Despite ~1.3k GitHub stars, the package reports 0 dependents and a modest opportunity score — signals of a niche utility rather than a widely load-bearing dependency. Treat it as a nice-to-have with a fallback (a custom preview-style transport or a filesystem-based log driver) rather than a load-bearing architectural pillar.
• You need guarantees beyond Laravel's mail internals: The event payload still surfaces SwiftMailer-era Swift_Mime_SimpleMessage types, and behavior depends on Laravel's mail manager internals — upgrades across major Laravel versions have historically required package releases. Plan for minor version churn.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free, MIT-licensed add-on for our Laravel application that makes every email we send during development instantly visible and testable. It costs nothing to license, takes under an hour to install, and shortens the loop between "we wrote an email" and "we approved how it looks" from days of manual QA to minutes. It also lets us put email content under automated tests, which reduces the risk of a broken receipt, a wrong price, or a missing legal disclaimer reaching customers.

For engineering leads:

• One config change (swap the mail transport to preview), one middleware registration, one route macro — reversible in minutes.
• Preview artifacts (.html and .eml) land in storage/email-previews with configurable retention and filename format; an overlay link appears on responses with a configurable popup timeout.
• Fires MailStoredEvent with paths to both versions, so it composes with existing observability or tooling.
• Ships a SentMails facade that closes a real gap in Laravel testing: Mail::fake doesn't render mailables, so you can't assert on content. This one can — subject, body substrings, recipients, CC/BCC, counts.
• Guardrail: defaults to APP_DEBUG only, so it self-disables outside local/staging.

For design and marketing stakeholders: You get to see the actual email — and open the .eml in Outlook, Gmail, or Apple Mail for a realistic rendering — before it goes to a customer. No more "can you forward me a screenshot."

Recommended decision: Adopt for local and staging as a developer-experience and email-quality tool with a probationary status: it is a small, actively maintained but thinly-depended-upon package, so assign an owner, pin the version, and keep a documented fallback in case maintenance lapses. Gate on a one-line config audit confirming it cannot activate in production.