Stampie Bundle Laravel Package

Technical Evaluation

Architecture fit. stampie-bundle is a Symfony bundle, not a Laravel package. It wires the stampie/stampie library (a provider-agnostic transactional-email abstraction over SendGrid, Mailgun, Postmark, Mandrill, etc.) into the Symfony service container via a stampie.yaml config tree and an ApiFactory/Mailer service. If the target application is Laravel, there is a real impedance mismatch: no package auto-discovery, no service provider or facade, different config-loading semantics, and no bundles.php registration path. The reusable asset in that case is the underlying stampie/stampie library, not this bundle.

Integration feasibility. v2.1.1 is a single, surgical fix restoring compatibility with Symfony 5 (PR #50, authored by stof — a long-standing Symfony core contributor). No API surface changes, no config schema changes. Integration is a Composer constraint bump (^2.1.0 → ^2.1.1). The signal worth noting is that Symfony 5 support was broken at v2.1.0 and required a community patch — useful evidence about maintainer bandwidth and CI coverage.

Technical risk. Low for the patch itself. Moderate for the package as a whole: thin release cadence, effectively single-maintainer, hard coupling to Symfony major versions, and no stated support for Symfony 6/7 in this release line. Secondary risk is strategic — since Symfony Mailer and Laravel's own mail transports matured, the abstraction-layer value of Stampie has eroded for single-provider use cases; it still earns its place where multi-provider failover or provider-swapping without code changes is a requirement.

Key questions.

1. What is our actual framework and major version — Laravel, or Symfony 5.x? This determines whether the bundle is even addressable.
2. Do we need runtime provider-switching / failover, or is a single transport sufficient? If single, native mailers are the lower-risk default.
3. Which Symfony and PHP versions are on our support matrix, and is Symfony 6/7 support on the package roadmap?
4. If Laravel: is the plan to wrap stampie/stampie directly in a service provider, and who owns that wrapper?
5. What is our exit cost if the package goes unmaintained — how many call sites touch the Mailer service?

Integration Approach

Stack fit. Symfony 5.x: the bundle is now usable as designed — register in config/bundles.php, configure the API and provider under config/packages/stampie.yaml, inject Stampie\Mailer. Laravel: do not install the bundle. Either depend on stampie/stampie directly behind a small custom service provider, or use Laravel's native Mail with the matching transport — prefer the latter unless multi-provider failover is a hard requirement.

Migration path. Composer constraint bump only. Pin ^2.1.1 explicitly; remaining on 2.1.0 leaves the Symfony 5 incompatibility in place. No code, config, or data migration is implied by the changelog.

Compatibility. Transitive constraints follow Symfony 5 (PHP 7.2.5+). Verify our runtime is on a supported PHP branch and confirm the exact Symfony minor (5.4 LTS preferred over earlier 5.x). Flag explicitly that Symfony 6/7 is unverified for this release line — if our platform roadmap includes a Symfony 6+ upgrade, treat this package as a blocker to be resolved now rather than during the upgrade.

Sequencing.

1. Confirm framework and Symfony/PHP versions (blocks everything else).
2. If Laravel and only the abstraction is wanted: decide build-vs-buy on a thin stampie/stampie wrapper, or fall back to native mail.
3. If Symfony: branch, bump to ^2.1.1, run container compile (cache:clear / debug:container) to catch DI or config-schema breaks early.
4. Smoke-test a real send against a provider sandbox; verify webhook/bounce handling if in scope.
5. Roll to staging, observe for one release cycle, then production.

Operational Impact

Maintenance. Patch-level; routine dependency hygiene. Real maintenance load is tracking an upstream with sparse releases — budget a recurring quarterly check rather than assuming passive stability.

Support. Community-only, no vendor SLA. Escalation is GitHub issues; the presence of a core-contributor patch is reassuring but does not constitute a support commitment. Internal ownership should be named explicitly, ideally the team that owns outbound email.

Scaling. The bundle is a thin DI/config layer — negligible runtime overhead. Throughput is governed entirely by the provider API (rate limits, quotas, latency). Scale planning belongs at the provider contract level, not here.

Failure modes.

• Framework version drift — precisely the class of failure this release fixes; will recur at the next Symfony major.
• Provider API deprecation — an abstraction layer lags upstream provider changes, so a deprecated endpoint can surface as send failures with no code change on our side.
• Container-compile misconfiguration — config-schema errors surface at boot, not at send time; good for catching early, bad if it reaches production deploys.
• Silent degradation — if failover across providers is configured, verify error propagation actually triggers fallback rather than swallowing exceptions.
• Abandonment — no upstream activity means we inherit the Symfony-upgrade work ourselves.

Ramp-up. Low. The public surface is small (one Mailer service, one factory, one config tree). An engineer comfortable with Symfony DI needs roughly half a day to be productive; a Laravel-only engineer needs longer, because the cost is learning Symfony bundle conventions rather than this package's API — another argument for not bringing the bundle into a Laravel codebase.