Stampie Bundle Laravel Package

Technical Evaluation

Change since last review — v2.1.1 (patch). A single-PR release: "Fix compatibility with Symfony 5" by @stof. No new features, no breaking changes, no deprecations, no security content. This is the first release signal since the project was archived on 2022-03-30, so the maintenance posture must be restated rather than carried forward verbatim. Two readings are possible: (a) the repository has been unarchived and is receiving minimal legacy support, or (b) a drive-by contributor patch was merged without a broader revival. The release contents point to (b) — one compatibility fix, scoped to a Symfony major (5.x) that reached end-of-life in November 2023. This release does not restore a security response process, does not widen the supported version matrix to Symfony 6/7, and does not touch the Guzzle pinning that blocks modern resolution. Every conclusion from the prior assessment stands; the accurate revision is that the package is minimally maintained against a legacy line, not frozen.

Architecture fit — primary blocker, unchanged. Despite the "Laravel/PHP package" framing, henrikbjorn/stampie-bundle is a Symfony bundle. It ships a Bundle subclass and a DI extension with a Symfony config tree — constructs Laravel has no equivalent for. It cannot be registered in config/app.php, cannot be auto-discovered by Laravel's package discovery, and its services are wired through Symfony's container compiler passes. In a Laravel codebase the only workable use is bypassing the bundle entirely and instantiating the underlying Stampie\Mailer classes by hand, which means inheriting the transitive dependency without obtaining any of the value the bundle exists to provide. For a Laravel target, architectural fit remains zero.

Second architectural concern — the abstraction is superseded, unchanged. Stampie's premise — a provider-agnostic email API with per-provider mailers (SendGrid, Mailgun, Postmark, Mandrill) — is now provided natively by symfony/mailer plus its transport bridges, and by Laravel's Mail system on top of it. A third-party abstraction over a framework-owned capability adds a maintenance seam with no offsetting benefit. v2.1.1 does nothing to alter this: it modernizes a Symfony 5 wiring detail, not the value proposition.

Integration feasibility — low, unchanged. The hard transitive dependency on an older Guzzle generation (Stampie is built around Guzzle 5/6-era client interfaces) is untouched. Composer resolution against Laravel 10/11/12 or Symfony 6/7 will still fail on php/symfony/* constraints before runtime, pushing you toward --ignore-platform-reqs and latent runtime type errors. Note the direction of the fix: Symfony 5 compatibility is a step toward the versions we need to leave behind, not toward the ones we run. Against a Laravel 11/12 application (Symfony 7 components), this release moves the package no closer to installable.

Technical risk — high, with one line item revised:

• Maintenance status: minimal, legacy-scoped (revised from "archived"). One PR merged, targeting an EOL Symfony major. Treat as low-activity legacy support with no stated security process, no CVE triage commitment, and no release cadence. The correct planning assumption remains: a public advisory in the bundle, Stampie, or its pinned Guzzle is yours to fork and fix. A single patch release is not a governance commitment.
• Frozen provider coverage — unchanged. Transactional email APIs move (SendGrid v2→v3, Mailgun regional endpoints, Postmark payload revisions). v2.1.1 shipped symfony-config wiring, not provider API work. A 2022-era provider integration with a 2023-era Symfony compatibility patch is still a bet that no provider contract you depend on has changed.
• Near-zero ecosystem signal — unchanged as of the available data. ~25 stars, 0 dependents, composite score 0.34. One patch release from one contributor does not constitute an ecosystem: there is still no downstream corpus to absorb bugs, no forks carrying forward-compat patches, and no Stack Overflow surface.
• New minor risk introduced by this release: an unarchived-but-barely-maintained project produces maintenance theater — the appearance of upkeep that suppresses the "replace this" conversation while the underlying version constraints and security posture stay untouched. Do not let v2.1.1 be read as a green light.

Key questions for the requesting team:

1. Is the target application Laravel or Symfony? (If Laravel, this evaluation ends — reject. The Symfony 5 fix is irrelevant to a Laravel 10/11/12 stack.)
2. If Symfony: are we on 5.x (where this patch is meaningful but the branch is EOL) or 6/7 (where it is still inert)? Does composer require resolve without --ignore-platform-reqs?
3. Has the repository actually been unarchived, and is there a named maintainer with a stated support window? Ask this directly rather than inferring from one merged PR.
4. What is the business driver — provider portability, legacy code already using Stampie, or an inherited dependency?
5. Which providers are in scope today, and do their current API versions match what the frozen mailers emit?
6. Is there production traffic through this library, or is this greenfield?
7. Who owns the fork if a CVE lands in this dependency chain — and has that owner been named, not assumed?

Integration Approach

Stack fit. None for Laravel — unchanged, and unaffected by v2.1.1. For a Symfony application the fit is historically correct but currently obsolete, and specifically obsolete-and-patched-for-an-EOL-major: v2.1.1 improves Symfony 5 compatibility only. Treat "fits our stack" and "fits our stack's current version" as separate gates; this passes only the first, and now passes it narrowly.

Recommended path (Laravel): do not integrate. Use Mail with an API transport — symfony/mailgun-mailer, symfony/postmark-mailer, symfony/sendgrid-mailer, symfony/amazon-mailer — configured through config/mail.php. Same provider-abstraction benefit the bundle was created to provide, with framework-level support, active security maintenance, and no Guzzle pinning conflict. If provider portability is an explicit requirement, encode it as a thin internal MailTransport interface implemented by Laravel's mailer, so provider swaps stay a config change.

Migration path (if legacy Stampie usage exists) — sequence unchanged. (1) Inventory every call site reaching the bundle's mailer services; (2) define an internal EmailSender port expressing your actual send semantics — single, batch, templated, attachment, provider webhook; (3) write an adapter over the existing Stampie path so behavior is pinned by tests; (4) implement a second adapter over Symfony Mailer or Laravel Mail; (5) cut over by configuration, provider by provider, keeping the old adapter as rollback for one release cycle; (6) remove the dependency. This decouples "get off the dead library" from "migrate the provider account," which are different risk profiles and should not ship together.

v2.1.1 migration action for existing consumers: none required. It is a drop-in patch on the 2.1.x line with no breaking changes or deprecations. Accepting it is safe; accepting it is not a substitute for the replacement plan above. Teams still on Symfony 5 should take the patch as a hygiene update while the retirement work proceeds.

Compatibility work to verify before any commitment: exact php constraint, exact symfony/* constraint (v2.1.1 confirms 5.x is supported; confirm whether 6/7 are claimed or merely unresolved), Guzzle major version, and open security advisories on any direct dependency. Verify the provider mailers against current provider API docs, not the library's own tests.

Sequencing guidance. Greenfield: skip. Inherited: schedule replacement, do not schedule adoption. Fund it as planned technical-debt retirement in the next one to two quarters rather than waiting for a CVE or provider deprecation trigger. Do not re-open the adoption decision on the strength of a single patch release.

Operational Impact

Maintenance. Low-activity legacy support. The correct operational assumption is unchanged in substance: the source of truth is effectively our fork, because a one-PR release cadence with no stated security process cannot be planned against. Budget for dependency drift as PHP and framework versions advance, provider API drift, and periodic security review of the Guzzle/Stampie chain. With 0 dependents, this cost is borne entirely by you with no amortization across a community. Revision to carry forward: v2.1.1 slightly lowers the risk of an immediate hard break on Symfony 5, and does nothing for Symfony 6/7 or Laravel 10+.

Support. Effectively none, but no longer accurately "no releases at all." There is a contributor who merged a compatibility fix; there is still no maintainer triage commitment, issue-response expectation, or release cadence to plan against. Internal engineers remain maintainers of record on day one. Institutional knowledge risk persists: a bundle nobody else uses is a bundle nobody else has written about, so onboarding and debugging rely on source reading. The one public data point — a recognized Symfony contributor touching the config wiring — is a reason to watch the repo, not a reason to depend on it.

Scaling. Not a concern in the usual sense. The bundle is a thin DI/config layer; real throughput characteristics belong to the provider's HTTP API and Guzzle's connection handling. Send volume, rate limits, retries, and webhook ingestion are provider-side. The scaling risk is organizational: the ceiling is how much undifferentiated maintenance the team will absorb, not requests per second.

Failure modes, ranked by likelihood:

1. Composer resolution failure against modern PHP/Symfony/Laravel — surfaces immediately, cheap to detect, blocks adoption outright. v2.1.1 does not help here; its fix targets Symfony 5.
2. Silent provider API drift — the library emits a payload the provider no longer accepts; sends fail at runtime with provider-specific errors, often in production first because tests mock the HTTP layer. Lowest observability, highest blast radius on transactional mail (password resets, receipts, notifications).
3. PHP deprecation and type errors on upgrade — noisy, non-fatal, gradual erosion of log signal.
4. Unpatched security advisory in the chain — no fix path except internal forking under time pressure. A minimal-maintenance project with no triage process does not discharge this risk.
5. False reassurance from v2.1.1 (new) — a patch release is cited internally as evidence the dependency is healthy, the retirement plan loses its slot, and the project remains on an EOL-adjacent, near-zero-adoption library for another cycle.
6. Bus-factor collapse — the one engineer who understood the wiring leaves.

Mitigations that actually matter: contract-test sends against the real provider sandbox on a schedule, not just mocked unit tests; alert on transactional email failure rate as a first-class SLO; keep the provider-swap interface in place so failure mode 2 is a config change rather than an incident; and record explicitly in the decision log that patch releases do not reopen the adoption question.

Ramp-up. Low technical curve on the code — small API surface, and the bundle does little. The cost is the absence of external documentation, examples, and community answers, which pushes every question into source reading. Days to productivity for a competent PHP engineer on the code itself; the real ramp-up cost is the ongoing tax of maintaining a minimally-maintained dependency.

Bottom line for the decision record: do not adopt. v2.1.1 is a Symfony 5 compatibility patch with no bearing on a Laravel target, no security content, no provider API work, and no evidence of restored maintenance governance. The package remains the wrong artifact for Laravel, duplicates framework-owned capability, and has essentially zero public production adoption. If it is already in the dependency tree, accept the patch as hygiene, classify the dependency as technical debt with a scheduled low-risk retirement path, and do not treat this release as a candidate for expanded use.