Weave Code
Email Bundle Laravel Package
illarra/email-bundle
Illarra EmailBundle is a Symfony/PHP package that streamlines sending emails from applications. It offers configurable mail transport integration, templated message composition, and convenient services for delivering transactional and notification emails.
Create beautiful emails in Symfony2
Frequently asked questions about Email Bundle
- Is illarra/email-bundle compatible with Laravel?
- No. illarra/email-bundle is a Symfony2 bundle, not a Laravel package, and it relies on Symfony kernel bundle registration, the Symfony DI container, Twig, and the Symfony-Swiftmailer bridge. Laravel has none of those extension points, so there is no ServiceProvider, facade, Blade namespace, or package auto-discovery to hook into. The technical evaluation rates it as not feasible as a Laravel dependency.
- Can I install illarra/email-bundle in a Laravel app with Composer?
- Composer may resolve it, but installing it will not give you a working Laravel mail integration. The bundle expects Symfony 2.x conventions and will pull in old Twig and Swiftmailer constraints that conflict with modern Laravel on PHP 8.x. The recommendation is not to adopt it as a dependency at all.
- What Laravel versions does illarra/email-bundle support?
- None. The package is a Symfony2 bundle and has no Laravel version support, no Laravel service provider, and no integration with Laravel's Mail facade or Mailable pipeline. It is archived and was built for a Symfony 2.x stack that reached end of life in November 2018.
- What should Laravel developers use instead of illarra/email-bundle for templated emails?
- Use Laravel Markdown mailables with a published resources/views/vendor/mail theme as the single point of brand control. For layout chrome, build Blade components such as x-mail.layout, x-mail.button, and x-mail.panel. This covers the same functional ground as the bundle without standing up a parallel Symfony container.
- Does illarra/email-bundle support Blade templates?
- No. The bundle uses Twig template rendering for HTML and text bodies, which is the Symfony view engine. Laravel uses Blade, and there is no Blade view namespace or bridge in the package. Porting the rendering logic into Laravel would mean rewriting it around Blade rather than using the bundle.
- Is illarra/email-bundle safe and maintained for production use?
- No. The repository is archived, has one star, zero dependents, and no security response channel. Its Symfony 2.x constraints pin old Twig and Swiftmailer versions with known CVEs and no PHP 8.x compatibility. Rendering user-influenced content through an unmaintained Twig stack is an injection and template-escalation risk you cannot patch.
- How do I inline CSS in Laravel emails without this Symfony bundle?
- Use tijsverkoyen/css-to-inline-styles, which is already a transitive Laravel dependency. Invoke it in a base Mailable subclass or mailable middleware so your published mail theme stays the source of truth. This replaces the need for a separate Symfony email composition layer.
- Can I use illarra/email-bundle for queued or transactional email in Laravel?
- Not practically. The bundle is built around Symfony's mailer and dependency injection, not Laravel's Mail facade or queue integration. You would need to run it as an isolated Symfony micro-kernel out of process, which is disproportionate for transactional or notification email. Laravel mailables and queued mail through the Mail facade are the native route.
- How would I migrate from illarra/email-bundle to Laravel mailables?
- There is realistically nothing to migrate because the package has zero dependents and no Laravel call sites. Treat the work as greenfield: inventory the email types you actually send, build Blade layout components, port content into Markdown mailables, and delete the evaluation branch. The evaluation budgets roughly two to three days for this.
- Is there any reason to fork illarra/email-bundle for a Laravel project?
- The evaluation says no. It is best classified as a reference implementation to read once, mine for layout ideas, and discard. If you borrow anything, borrow the config-driven theme key idea and reproduce it in a base Blade layout. If you truly fork it, you must name a maintainer and define a review cadence first.
Weaver
How can I help you explore Laravel packages today?