Headoo Mailjet Bundle Laravel Package

Technical Evaluation

Architecture fit. Fails the first gate, and the failure is a stack mismatch rather than a quality judgment. Despite being filed as a Laravel/PHP package, this is a Symfony bundle: it ships a bundle class, a DI extension, and YAML service definitions, and expects kernel registration. Laravel performs no discovery on symfony-bundle types, so installing it yields classes with no wiring — no service provider, no facade, no publishable config. Even inside a Symfony app, its sole contribution (binding a Mailjet transport into the container) is already served by symfony/mailjet-mailer and Mailjet's own SDK. There is no architectural gap for it to fill.

Integration feasibility. Low, and the signals are mutually reinforcing: repository flagged Deprecated, 3 stars, 0 dependents, composite score 0.205. Zero dependents is decisive — no downstream project has validated it against a current framework or PHP runtime, so we would be first with no prior art. The glue code itself is trivial; the question is whether a dead wrapper is defensible when the maintained path costs the same half-day.

Technical risk. High, concentrated in sustainment rather than function.

Key questions. Which Mailjet API version does it target, and does Mailjet still support it? What PHP/Symfony constraints does composer.json declare? Is the license compatible with our distribution model? Any repository activity after the deprecation notice? Which services send via Mailjet today, at what volume and SLA? And the framing question that subsumes the rest: is the requirement "integrate Mailjet into Laravel," or simply "deliver transactional email via Mailjet"? The second is solvable without this package at all.

Integration Approach

Stack fit. Poor as named, fine as intent. The underlying need — transactional email through Mailjet — is well served on Laravel by the official SDK behind a narrow adapter bound into the Mail layer, or by registering Mailjet as a custom Symfony Mailer transport (Laravel's mail layer sits on Symfony Mailer). Both are maintained, both are roughly fifty lines of glue, and neither drags a deprecated tree behind it.

Migration path. Do not adopt. If a service already depends on this bundle, introduce an outbound-mail interface at the call sites, keep the bundle as one implementation behind it, and add a Mailjet-SDK implementation alongside. Cut over by configuration flag, verify deliverability plus bounce and webhook behavior, then delete the bundle and its transitive dependencies.

Compatibility. Assume the composer constraints are stale until proven otherwise. Do not force-install with --ignore-platform-reqs — that converts a visible install error into invisible runtime drift. The replacement path carries no such constraint: the official SDK and the Mailer transport both track current PHP releases.

Sequencing. (1) Inventory actual Mailjet usage, volumes, and webhook consumers. (2) Confirm vendor-side API version and account status. (3) Build the adapter against the official SDK in non-production. (4) Parallel-run and compare delivery, bounce, and webhook behavior. (5) Cut over service by service. (6) Remove the package and record the decision. Days, not weeks — which is precisely why there is no case for carrying a deprecated dependency to avoid it.

Operational Impact

Maintenance. This is where the cost lands. A deprecated package does not sit still; it accrues. Dependency conflicts on every framework upgrade, advisories surfacing in SCA scans with no fix available, and a recurring "why is this here?" tax on each engineer who touches the mail path. Forking is worse — we would be maintaining an email wrapper as an unscheduled side project.

Support. None. No maintainer response path, no issue triage, no upstream contact. When delivery breaks, the only escalation route is Mailjet's own support, who will reasonably ask why we run an unsupported client. The burden falls on whoever inherits the service — not the team that introduced it.

Scaling. Not a concern. Mailjet is a hosted HTTP API; throughput is bounded by provider rate limits and our queue design, not the client library. The package neither helps nor hinders scale. Decouple sending from request paths via a queue regardless.

Failure modes. The dangerous ones are quiet: a Mailjet API change the abandoned client does not track (symptoms appear as failed sends, not exceptions); framework upgrades that silently alter behavior under --ignore-platform-reqs; TLS or auth-scheme deprecations provider-side; and the classic — an engineer removing the "unused" bundle without realizing a webhook route depends on it. Mitigate with send-failure alerting, bounce and complaint webhook monitoring, and a written usage inventory before any removal.

Ramp-up. Low technical ramp, non-trivial knowledge risk. The API surface is small enough to read in an hour; the risk is that nobody owns it and its history is undocumented. If retained at all, time-box it: name an owner, write a one-page runbook, set a removal date. Given 0 dependents, 3 stars, and an explicit deprecation flag, the defensible position is to reject adoption outright and spend the small integration effort on a maintained path.