- What is tomirons/tuxedo and what does it do?
- Tuxedo is a thin, opinionated layer over Laravel's Illuminate\Mail\Mailable. It lets you express each transactional email (receipts, invites, notifications) as a dedicated class with declared views, subjects, and data contracts. The goal is convention over configuration, cutting boilerplate in codebases that send many one-off emails. It is not a transport or templating engine; it sits on top of Laravel's existing Mail abstraction.
- Which Laravel versions does tomirons/tuxedo support?
- The package explicitly targets Laravel 5 mailables, and its last release was in February 2021. That predates Laravel 9's Symfony Mailer migration, which materially changed Mailable internals and view/attachment behavior. On Laravel 5.x through 8.x, feasibility is high. On Laravel 9 and above, expect illuminate/mail and illuminate/support constraint conflicts and treat adoption as a fork-and-patch exercise.
- Is tomirons/tuxedo still maintained?
- No. It has gone roughly four years without a release and has low adoption at around 93 stars. Low adoption means a narrow bug blast radius, few public usage patterns, and thin community test coverage across PHP and Laravel versions. The MIT license does permit forking, and the package surface area is small, so the cost to own a fork is bounded.
- How do I install tomirons/tuxedo?
- Installation is a standard Composer pull, but the real question is whether it resolves against your target Laravel version. Run composer why-not tomirons/tuxedo <laravel-version> to enumerate conflicts before committing. If constraints block installation, you are looking at patching or forking rather than a clean install.
- Can I use tomirons/tuxedo with Laravel 10 or Laravel 11?
- Effectively no, not without patching. Laravel 9's move to Symfony Mailer changed Mailable internals, view naming, and attachment handling, and Tuxedo predates that shift. For Laravel 10 or 11, treat it as a fork-and-own exercise or replicate the pattern in-house instead. Greenfield Laravel 11 or 12 projects should not adopt it as a dependency.
- Does tomirons/tuxedo work with Mail::fake() and Laravel's standard mail testing?
- Because Tuxedo builds on Mailable, Laravel's Mail::fake() assertions should generally still work. The thing to verify is whether its view and subject resolution interferes with how mailables are constructed and asserted in your tests. Combine Mail::fake() for assertions with real SMTP delivery against a sandbox such as Mailtrap to catch rendering regressions.
- What are good alternatives to tomirons/tuxedo?
- Plain Laravel Mailables, including built-in Markdown mailables, cover most of the same ground without a stale dependency. The other option is to copy the pattern: a small abstract TransactionalEmail class extending Mailable, traits for view and subject resolution, and a static for*() factory per email. That is roughly 150 to 300 lines and fully under your control.
- Should I fork tomirons/tuxedo for a Laravel 9+ upgrade?
- A fork is viable because the MIT license allows it and the code is small, stateless, and low complexity. Before doing it, define a fork policy and assign an internal owner, and decide whether a pinned fork is acceptable long term. Grep both the package and your codebase for SwiftMailer-era APIs such as withSwiftMessage, swiftMessage, and attachment calls, then port or remove them.
- How do I migrate away from tomirons/tuxedo?
- Treat it as a discrete mail-layer migration workstream, not a passive dependency bump. Target the Symfony Mailer API, replace Tuxedo's base classes and traits with your own abstract Mailable, and convert each email to a for*() static factory. Verify view resolution against Laravel 9+ naming and namespace conventions, then test with Mail::fake() and sandbox SMTP delivery.
- Is tomirons/tuxedo safe to use in production?
- Technical risk is rated high for new adoption because of staleness, low adoption, and coupling to Mailable semantics that have since shifted. Hidden breakage on minor upgrades is plausible, and the convention-based view resolution needs auditing for content, legal, and compliance footers such as CAN-SPAM and GDPR. For existing Laravel 5 to 8 codebases, keep it pinned, add lockfile and CI matrix coverage, and schedule a fork before any Laravel 9+ upgrade.