Email Bundle Laravel Package

Product Decisions This Supports

• Closing the "build vs. buy" line for transactional email rendering. The recurring need is real — consistent, client-safe HTML for receipts, resets, onboarding, and notifications. This package is evidence that teams historically reached for a thin Twig-plus-CSS-inliner wrapper rather than building it. It does not de-risk the buy decision: 1 star, 0 dependents, archived, and Symfony2-only means there is no adoption signal, no community, and no maintenance path to lean on.
• Framework-fit triage. This is not a Laravel package. No service provider, no Blade view namespace, no integration with Laravel's Mail facade or Mailable pipeline. Any roadmap or backlog item that assumes drop-in Laravel usage should be closed immediately with a one-line rationale.
• Legacy modernization input. Symfony2 hit end of life in November 2018. If this appears anywhere in a dependency graph, treat it as a signal to scope a framework/PHP upgrade — a budget and roadmap input, not a feature decision.
• Prioritizing the email design system as its own initiative. If stakeholders are asking for "beautiful emails," the real decision is whether to fund a shared email layer (layout components, design tokens, partials, preview harness, visual regression tests). This repo is a historical example of that pattern, not a candidate implementation. The theming idea inside it is worth borrowing; the code is not.
• Vendor and landscape diligence. Useful as a cautionary example in dependency reviews: MIT license and a clear single purpose are not sufficient health signals. Opportunity score of 0.27, archived status, and zero dependents are the deciding factors.
• Shaping the replacement backlog. Rather than adopting, the PM can convert this evaluation directly into a scoped internal workstream: base mailable plus Blade email components, a CSS inliner step, a published mail theme, and rendered-output snapshot tests.

When to Consider This Package

Consider it only in one narrow scenario:

• You maintain a Symfony 2.x application that already depends on it, migration is explicitly out of scope this cycle, and email rendering must stay stable through a release freeze. Even then the defensible action is "pin the version and document the risk," not "adopt."

Look elsewhere in essentially every other case:

• Laravel applications — use first-party Mailer with Markdown mailables, a published mail theme, and tijsverkoyen/css-to-inline-styles (already a transitive dependency). All maintained, PHP 8 compatible, and hireable-for.
• Symfony 5/6/7 — Symfony Mailer plus Twig plus a CSS inliner covers the same ground with first-party support and security patching.
• Any team needing support, security response, or PHP 8 compatibility — archived means no fixes, no CVE channel, no compatibility guarantees. A hard disqualifier for anything customer-facing.
• Any team without existing usage — with 1 star and 0 dependents there is no community, no issue history to mine, and no third-party documentation. Integration cost lands entirely on the team, and the fork becomes ours to own indefinitely.

Adoption criteria that would need to hold and do not: maintained releases in the last 12 months, PHP 8.x support, a modest dependent base, CI, and a supported framework version.

How to Pitch It (Stakeholders)

Executive summary. We evaluated illarra/email-bundle for transactional email templating and recommend against adoption. The capability it targets — polished, brand-consistent transactional email — is worth funding. This artifact is a poor vehicle for it: the repository is archived, has a single star and zero dependents, targets Symfony2 (end-of-life since 2018), and is not a Laravel package, so it does not fit our stack at all.

Engineering summary. No new dependency, no migration work, no added surface area. We reach the same outcome with first-party tooling — framework-native mailables, a published theme, and a CSS inliner we already ship transitively — which is maintained, PHP 8 compatible, and testable. Adopting an archived bundle would create a permanent maintenance liability with no offsetting benefit, and any fork we produce becomes ours forever with no upstream to rebase against.

What we do instead. Close the "adopt this package" line item. Redirect the effort into a small, owned email template layer: shared Blade layout components, a config-driven theme key (the one design idea worth borrowing), an inlining step, a dev-only preview route for visual review, and snapshot tests on rendered output. Roughly two to three days of spike to extract reusable layout structure from the source, then build — not integrate.

Decision framing for the roadmap. Composite score of 0.36 and opportunity score of 0.27 accurately describe a historical curiosity, not a candidate. Record the decision, capture the theming idea, and move the budget into our own email component library. That delivers the stakeholder-visible outcome with materially lower long-term cost and no dependency risk.