Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Base Mail Bundle

Base Mail Bundle Laravel Package

instaclick/base-mail-bundle

Instaclick BaseMailBundle is a Symfony bundle that provides a reusable foundation for composing and sending email, with mailer services and extension points for custom transports, templates, and application-specific mail workflows. It helps standardize mail setup across Symfony projects.

View on GitHub
Deep Wiki
Context7

This Bundle provides mail support for Symfony2 applications

Frequently asked questions about Base Mail Bundle
Can I use instaclick/base-mail-bundle in a Laravel application?
No. Instaclick BaseMailBundle is a Symfony2 bundle, not a Laravel package. It depends on Symfony's DependencyInjection component, a Bundle class with an Extension and Configuration tree, the Symfony event dispatcher, and a Swift Mailer transport stack. Laravel has no shared contract surface for those seams, so the bundle cannot be dropped in and wired up through a service provider. At best it can be read as a reference implementation of a thin mail abstraction.
Does instaclick/base-mail-bundle support Laravel 10 or Laravel 11?
No. The last release targets PHP 5.3 to 5.6 and Symfony 2.x. Laravel 10 and 11 require PHP 8.1 or newer plus symfony/* v6 or v7, which directly conflict with the bundle's pinned constraints. There is no forward-compatible branch, so Composer resolution fails before any code runs.
Why does composer require instaclick/base-mail-bundle fail with a dependency conflict?
Composer cannot reconcile the bundle's legacy constraints with a modern Laravel project. The bundle pins old symfony/* component versions, an obsolete Swift Mailer dependency, and a PHP floor far below what Laravel 10 or 11 requires. Because there is only a January 2014 release and no maintained branch, there is nothing for Composer to resolve against. The practical answer is not to add it to composer.json at all.
What is instaclick/base-mail-bundle actually used for?
It provides a lightweight foundation for composing and sending email in Symfony2 applications. You get base message and mailer abstractions to extend, dependency-injection service wiring, template-driven body rendering for reusable layouts, and simple recipient and attachment handling. The point was to avoid rewriting mail logic in every project by standardizing message construction across an application.
Is instaclick/base-mail-bundle still maintained?
No. The last release was January 2014 and the code targets PHP 5.3 to 5.6 with Symfony 2.x. The repository has roughly 4 stars and 0 dependents, with no fork activity and no evidence of production use at scale. Adopting it would mean committing to maintain a ten-year-dormant Symfony2 bundle yourself.
How do you install and configure the bundle in a Symfony2 project?
It would be added as a Composer requirement in a Symfony2 application and registered in AppKernel, then configured through the bundle's Extension and Configuration tree. Services are defined in Resources/config and rely on Symfony's DependencyInjection container plus the event dispatcher. Mail delivery runs through a Swift Mailer-based stack, and you extend the base mailer and message classes for application-specific workflows. These steps have no Laravel equivalent.
Does the bundle depend on Swift Mailer, and is that a problem today?
Yes, its transport model is built on Swift Mailer, which has been deprecated in favour of Symfony Mailer. Laravel's mail layer already sits on symfony/mailer through illuminate/mail, so the bundle's core delivery concept is both duplicated and obsolete. That makes the dependency a liability rather than an integration point.
What Laravel mail features replace this bundle's mailer abstraction?
Laravel already owns this layer through illuminate/mail: Mailable classes, the MailManager and Mailer contracts, custom transports registered with Mail::extend, queued mailables, and the MessageSending and MessageSent events. Multi-transport delivery, observability, and interception hooks are all native. If you need pre-send redaction or audit logging, a listener on MessageSending does the job in a few lines.
How do I test mail sending in Laravel if I don't use this bundle?
Use Mail::fake() and assert on Mailables with assertSent, assertQueued, and assertNothingSent. You can inspect recipient, subject, and view data on the faked message without touching a real transport. For transport-level behaviour, swap in a custom mailer binding inside a test service provider. None of this requires the legacy bundle.
Is instaclick/base-mail-bundle safe for production, and what is its license?
The license is MIT, which is permissive and unproblematic, but the real concern is provenance and longevity rather than licensing. The code is ten years unmaintained, targets an end-of-life PHP and Symfony generation, and has no community to surface regressions. Running it in production would mean owning a fork indefinitely, which is why the recommended path is to reimplement the useful patterns Laravel-natively.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
robertmarney/lara-hierarchial-collections
simonschaufi/rule-doc-generator
emissaoja/emissaoja
blackbricksoftware/gravityforms-civicrm-form-processor
al-rahabi/fancy-crud
jinas/dhivatar-component
mltstephane/laravel-quality
bernskiold/laravel-talentlms
bernskioldmedia/laravel-form-architect
youbar/easy-crud
c-point-labs/laravel-hostyourai
dbravoan/dbcms-admin-theme-dbcms
dbravoan/dbcms-theme-db-cyber
dbravoan/dbcms-blocks-basic
dbravoan/dbcms-module-content-audit
dbravoan/dbcms-module-ai-assistant
paygate-to/paygate-php
padosoft/askmydocs-connector-base
defstudio/supercharged-carbon
bernskioldmedia/laravel-matomo