Mailer Bundle Laravel Package

Product Decisions This Supports

• Transactional email infrastructure (narrow slice). A package named wandi/mailer-bundle sits in the "send mail from the application" layer — transport configuration, message construction, and templating. It informs decisions about whether we build a thin internal mailer abstraction or adopt one.
• Build vs. buy vs. fork. With 2 stars, 0 dependents, and no meaningful adoption signal, this is not a "buy" in the vendor sense. It is a read-and-fork candidate: the decision it actually supports is "vendor the code into our repo" or "reject and write 200 lines ourselves," not "add a dependency."
• Framework fit on the roadmap. The Bundle suffix is Symfony convention, not Laravel. If our roadmap is Laravel-first, this package is likely a category mismatch — Laravel's built-in Mail/Notifications already covers this ground. This informs the framework-standardization decision, not a feature decision.
• Notification feature scoping. If the roadmap item is "templated, queued, multi-channel notifications with delivery observability," this package does not close that item. It supports de-scoping it: send plain transactional mail now, defer the notification platform.
• Dependency-risk policy. A concrete test case for our rule on low-adoption dependencies: MIT-licensed, tiny surface, easy to audit — acceptable for non-critical paths, unacceptable where email deliverability is revenue-bearing.
• Use cases where it is plausibly in scope: internal Symfony services, admin/ops alerting, low-volume templated mail in a codebase already owned by the same team that can patch it.

When to Consider This Package

Consider it when:

• You are on Symfony, not Laravel (the naming and the Wandi ecosystem strongly suggest a Symfony bundle; verify before anything else).
• You need a thin wrapper around Symfony Mailer for a small, internal, low-volume mail path.
• Your team can read and own the source — it is small enough to fork and maintain in-house under MIT.
• Email is non-critical (internal alerts, dev/staging fixtures) and a silent failure is tolerable.
• You are already inside the Wandi vendor ecosystem and consistency with existing services has value.

Look elsewhere when:

• You need proven adoption or any community support — 2 stars and 0 dependents means no ecosystem, no Stack Overflow answers, no third-party bug reports.
• You are on Laravel — use Mail, Mailable, and Notifications; do not adopt a Symfony bundle to replicate first-party functionality.
• Requirements include deliverability: bounce/complaint webhooks, DKIM/SPF tooling, provider failover, retry/backoff, send observability, or per-tenant throttling. This package will not carry that weight.
• You need documentation, security response, or a release cadence — none is evidenced by the public metadata.
• Email is revenue-bearing (receipts, password resets, onboarding). Dependency risk is not worth the saved lines of code.

Gate before adoption: confirm framework compatibility, last-commit recency, CI presence, test coverage, and whether it wraps a maintained mailer or reimplements transport. The repository description is empty, so capability claims must come from the source, not the listing.

How to Pitch It (Stakeholders)

One line: A small MIT-licensed mailer bundle with essentially zero adoption — worth reading, not worth depending on.

For executives: This is not a strategic dependency and we should not treat it as one. The code surface is small and permissively licensed, so the downside is bounded, but 2 stars and 0 dependents means no community, no security response, and no one else to find the bugs. Recommendation: treat it as reference source for a ~200-line internal mailer, or fork it if it genuinely fits. Do not put revenue-critical email behind it.

For engineering: Read the source first. The Bundle suffix indicates Symfony, so confirm it is relevant to our stack at all before spending time. If it fits, vendor the code rather than taking a versioned dependency — we get the same functionality with no supply-chain risk and no obligation to a maintainer who has none to us. If it does not fit, the fallback is first-party mail APIs plus a thin internal abstraction, which we control and can test.

Decision requested: Approve a timeboxed spike (half a day) to determine framework fit and whether the wrapper is worth forking; default to no-go if the spike finds it reimplements transport or lacks tests.