- Is stampie/stampie-bundle a Laravel package?
- No. It is a Symfony bundle that wires the stampie/stampie library into the Symfony service container, so it has no Laravel auto-discovery, service provider, facade, or bundles.php-style registration. In a Laravel application the reusable part is the underlying stampie/stampie library, not this bundle.
- How do I install stampie/stampie-bundle in Laravel?
- You should not install the bundle in Laravel. Composer may resolve it, but it will not auto-register and its stampie.yaml config tree and Symfony DI services do not map to Laravel configuration. Use stampie/stampie directly behind a small custom service provider, or prefer Laravel's native Mail transports unless multi-provider failover is a hard requirement.
- What Laravel versions does stampie/stampie-bundle support?
- None officially. The package is a Symfony bundle and does not declare Laravel framework support, package discovery, or a Laravel service provider. For Laravel, depend on stampie/stampie directly or use Laravel's built-in mail system.
- Which Symfony versions does stampie-bundle support?
- Version 2.1.1 restores compatibility with Symfony 5 after the 2.1.0 release broke it, so pin ^2.1.1 if you are on Symfony 5.x. This release line does not state support for Symfony 6 or 7, so treat those upgrades as unverified and potentially blocked. Transitive constraints follow Symfony 5, including PHP 7.2.5 or newer.
- How do I configure Mailgun, SendGrid, or Postmark with stampie-bundle?
- In Symfony you configure the provider and API credentials under config/packages/stampie.yaml, then inject the Stampie Mailer service where you send mail. That configuration flow is Symfony-specific and does not translate to Laravel's config directory or service container. In Laravel, configure stampie/stampie yourself or use the matching native Mail transport.
- Can I switch email providers without changing code with Stampie?
- Yes. Stampie is a provider-agnostic transactional email abstraction over services such as Mailgun, SendGrid, and Postmark, so swapping providers is primarily configuration rather than application code. In Laravel this benefit comes from wrapping stampie/stampie directly, not from installing the Symfony bundle. For a single provider, native Laravel Mail is usually the lower-risk default.
- What are Laravel alternatives to stampie-bundle for multi-provider email?
- The main options are Laravel's native Mail system with the matching transport, or a thin custom wrapper around stampie/stampie if you truly need runtime provider switching or failover. The Symfony bundle itself is not a Laravel integration path. Choose native Mail first unless provider-agnostic failover is a hard product requirement.
- Is stampie-bundle maintained and safe to use in production?
- The 2.1.1 patch is a surgical Symfony 5 compatibility fix authored by stof, with no API or config schema changes, so the patch itself is low risk. The broader package has thin release cadence, is effectively single-maintainer, and has no stated Symfony 6 or 7 support in this line. Budget recurring quarterly maintenance checks rather than assuming passive stability, and keep exit cost low by limiting call sites that touch the Mailer service.
- How do I test stampie-bundle email sending in Laravel?
- There is no Laravel testing integration because this is a Symfony bundle. In Laravel, test the wrapper you build around stampie/stampie or use Mail::fake() with native transports. If you integrate it in Symfony, compile the container and smoke-test against a provider sandbox rather than sending live email in tests.
- Should I use stampie/stampie-bundle or Laravel's native Mail?
- For Laravel, prefer native Mail unless you need multi-provider failover or provider swapping without code changes. The stampie-bundle is a Symfony integration and should not be installed in Laravel; use stampie/stampie directly only if the abstraction is worth owning. Weigh the exit cost by counting how many call sites would touch the mailer service.