Weave Code
Headoo Mailjet Bundle Laravel Package
headoo/headoo-mailjet-bundle
Integrates the Mailjet email service into PHP applications, providing a simple way to send transactional and marketing emails through Mailjet's API with straightforward configuration.
Symfony2 Bundle for initializing Mailjet PHP API v3 wrapper
Frequently asked questions about Headoo Mailjet Bundle
- Is headoo/headoo-mailjet-bundle a Laravel package or a Symfony bundle?
- It is a Symfony2 bundle, despite being catalogued alongside Laravel and PHP packages. It ships a bundle class, a dependency-injection extension, and YAML service definitions, and it expects registration in a Symfony kernel. Laravel has no concept of a Symfony bundle and performs no discovery for the symfony-bundle type, so nothing gets wired up. Treat any listing that presents it as a Laravel package as a categorisation error.
- How do I install and configure headoo/headoo-mailjet-bundle in a Laravel app?
- You cannot meaningfully do so. Composer will download the code, but there is no service provider, no facade, and no publishable configuration file, so the container is never told about the Mailjet transport. You would end up with classes on disk and zero integration. The package is also flagged Deprecated, so installing it introduces an abandoned dependency for no functional gain.
- Why doesn't Laravel auto-discover this bundle's service provider?
- Laravel's package discovery only inspects the extra.laravel.providers and extra.laravel.aliases keys declared in a package's composer.json. This bundle declares the Symfony bundle type and registers itself through a Symfony DI extension instead. Since no provider key exists, discovery silently returns nothing and the package remains inert. That is the first and most decisive reason it cannot be dropped into a Laravel application.
- Is headoo/headoo-mailjet-bundle still maintained?
- The repository is flagged Deprecated and no fixes or CVE response path are expected. It has roughly 3 stars and zero dependents, meaning no downstream project has validated it against a modern framework or PHP runtime. A composite health score around 0.205 reflects that abandonment. There is no community, no searchable Q&A corpus, and no reason to expect future updates.
- What is the best alternative for sending Mailjet email in Laravel?
- Use Mailjet's official PHP SDK behind a thin adapter bound into Laravel's mail layer, or register Mailjet as a custom Symfony Mailer transport, since Laravel's mail layer is built on Symfony Mailer. Both paths are actively maintained and track current PHP releases. The glue code is roughly fifty lines either way. Neither drags a deprecated dependency tree into your lockfile.
- Which Mailjet API version does this bundle wrap, and is it still supported?
- It is built as a wrapper around the Mailjet PHP API v3, but the repository provides no confirmation that the target version is current. API drift is a real risk when a package has been dormant long enough to be marked deprecated. Before relying on it, verify the vendor-side API version and whether Mailjet still supports that surface. In practice the official SDK removes the question entirely.
- Will the bundle's Composer constraints work with current PHP and Laravel versions?
- Assume the constraints are stale until you prove otherwise. Deprecated Symfony2-era bundles are typically pinned to end-of-life Symfony and PHP ranges, which will produce dependency conflicts on modern installs. Do not work around it with --ignore-platform-reqs, because that converts a visible install error into invisible runtime drift. The official SDK and a custom Mailer transport carry no such constraint.
- How do I migrate an existing application off this bundle without breaking email delivery?
- Introduce an outbound-mail interface at your call sites and keep the bundle as one implementation behind it. Add a second implementation built on the official Mailjet SDK, then cut over by configuration flag. Parallel-run both paths and compare delivery, bounce handling, and webhook behaviour before deleting the bundle and its transitive dependencies. This is days of work, not weeks, which is exactly why carrying a deprecated dependency to avoid it makes no sense.
- Can I use this bundle alongside Laravel's Mail facade or Symfony Mailer?
- No, it provides no transport integration for either. Its only contribution is binding a Mailjet transport into a Symfony service container, which is already handled by symfony/mailjet-mailer and Mailjet's own SDK. It does not register a Laravel mail driver, expose a Mail facade hook, or implement a Symfony Mailer transport that Laravel could consume. There is no architectural gap for it to fill on Laravel.
- How should I test Mailjet transactional email in Laravel before going to production?
- Build against the official Mailjet SDK behind your own adapter so you can swap in a fake or log driver during tests without touching call sites. Assert on the outbound-mail interface rather than on Mailjet internals, then run a parallel send against a staging Mailjet account to confirm deliverability, bounce classification, and webhook payloads. Verify webhook consumers explicitly during cutover, because they are the part most likely to break silently. Doing this with a maintained SDK means your test harness survives framework upgrades.
Weaver
How can I help you explore Laravel packages today?