Weave Code
Laravel Mail Builder Laravel Package
dophp/laravel-mail-builder
dophp/laravel-mail-builder provides a fluent, code-driven way to compose rich HTML emails in Laravel, helping you build and send templated messages without hand-writing markup. A lightweight helper for cleaner mailables.
dophp/laravel-mail-builder offers a fluent, chainable API for constructing Laravel emails without repetitive boilerplate. Define recipients, subject, views, and attachments in a single expressive builder, then send or queue the result through Laravel's native mail system.
- Fluent, chainable mail definition API
- Plays nicely with existing Mailables and Laravel's mailer
- Supports views, plain-text bodies, and attachments
- Queue-ready with a single method call
- Zero-config integration with any Laravel app
Frequently asked questions about Laravel Mail Builder
- How do I install dophp/laravel-mail-builder in a Laravel application?
- Install it with Composer by running composer require dophp/laravel-mail-builder. The service provider is auto-discovered on modern Laravel versions, so no manual registration is normally needed. Publish the package config and any frontend assets with php artisan vendor:publish and select the mail-builder tags. After publishing, clear your config and view caches so the new settings take effect.
- Which Laravel versions does this mail builder support?
- Support is defined by the illuminate/support and PHP constraints in the package's composer.json, so check those before upgrading. The package targets modern Laravel releases with auto-discovery and the current Mail API. If you are on an older Laravel major, verify compatibility in a branch first. Running composer update in a throwaway branch and executing your mail tests is the fastest way to confirm fit.
- What does slot-based, modular email building actually mean?
- Emails are stored as a structured document made of reusable blocks, and each block exposes named slots where content or nested blocks are placed. That structure compiles down to responsive, table-based HTML suitable for email clients. Because blocks are modular, you can define a house style once and reuse it across transactional mailables. The document format is also what makes programmatic composition and version control practical.
- Can I import my existing MJML or HTML templates into the builder?
- Yes, the package includes MJML and HTML import so existing templates can be converted into builder blocks instead of rewritten by hand. Imported markup is mapped onto the block model, so heavily custom or script-driven templates may need manual cleanup afterwards. Import is best treated as a migration aid, not a perfect one-to-one conversion. Always render and visually compare imported templates across major clients before shipping.
- How do merge tags work in compiled emails?
- Merge tags are placeholders embedded in block content that are resolved at render time from the data you pass to the mailable. They keep personalization out of the compiled template, so the same document can serve many recipients. Be careful to escape user-supplied values when they land in HTML or attributes. Test tags with missing or null values, since undefined data is the most common cause of broken sends.
- Does it support AMP for email and plain-text fallbacks?
- The package supports AMP output alongside a standard HTML version and can generate a plain-text fallback part. That lets you build a multipart message where each client receives the best variant it understands. AMP for email requires separate registration and validation with your sending provider, so treat it as an enhancement rather than a baseline. Most senders still need a solid HTML and text version first.
- What are pre-send audits and why should I use them?
- Pre-send audits run checks over the compiled document before delivery, catching problems like missing alt text, unresolved merge tags, suspicious links, or oversized output. Running them in tests or CI means broken emails fail the build rather than reaching customers. They are a safety net, not a substitute for rendering tests in real clients. Combine audits with a small set of visual snapshots for the highest-value templates.
- How do I test emails generated by this package?
- Use Laravel's Mail::fake to assert that the right mailable was sent with the right data, then separately assert on the compiled HTML. Snapshot tests work well here because the compiled output should be deterministic for a given document and payload. Keep at least one test per block type plus one end-to-end test for your main transactional email. Avoid asserting on exact markup for third-party client hacks you do not control.
- Will the builder affect performance or add runtime dependencies in production?
- Compilation is plain PHP inside your application, so there is no external service, queue, or storage dependency introduced by the builder. The main cost is compiling documents at send time, which you can mitigate by caching compiled output per template and locale. If you use the visual editor, its published assets must be deployed and served correctly, which is the most common production pitfall. Cache the compiled HTML rather than recompiling on every recipient.
- How does this compare to writing Blade mailables or using an MJML-only compiler?
- Plain Blade mailables give you full control but no shared block model, no import path, and no built-in audits. MJML-only compilers solve responsive rendering but leave composition, personalization tags, and fallbacks to you. This package sits above Laravel's mailer and adds a structured document, merge tags, AMP, plain-text fallback, and pre-send checks. Choose it when non-trivial email design is a recurring need rather than a one-off template.
Weaver
How can I help you explore Laravel packages today?