Hermes Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony bundle, not a Laravel package — this remains the single most important fact. 2lenet/hermes-bundle is a mail management layer: Doctrine-backed Mail / Recipient entities, Twig + MJML templating, CKEditor-authored bodies, attachments, CC sublists, unsubscribe links, cancel-send, resend-per-recipient, status filtering, and a CruditBundle admin dashboard with translations. Delivery is delegated to Symfony Mailer. The durable product value is the template + recipient state model and admin workflow, not the send mechanism. For a Laravel codebase, only the data model and the cancel/resend semantics are portable; the DI wiring, entities, Twig rendering, and admin UI are all framework-specific glue you would rebuild.

The 1.14.5 patch sharpens this conclusion rather than softening it: the fix for mail status accounting for CC recipients landed in the Crudit integration (crudit#668), alongside a new Twig partial — not in the domain entity. Status derivation, in other words, is partly owned by the admin layer. That is presentation-adjacent logic you would have to reimplement anywhere Crudit is absent.

Integration feasibility. The transport layer is not the blocker — Laravel's mailer already sits on symfony/mailer, so MTP/API transports are shared. Real blockers, in order of severity:

1. Doctrine ORM entities and mappings (Laravel default is Eloquent) — requires standing up Doctrine or porting entities.
2. Symfony DI extension / config tree — no Laravel service provider, no facade, no publishable config.
3. Twig + MJML + CKEditor rendering path — Blade has no equivalent; you'd add a Twig bridge or reimplement, and 1.14.5 adds another Twig partial to that surface.
4. Hard dependency on CruditBundle (a Symfony admin panel) — the dashboard, filters, and actions do not exist outside it, and status computation for CC recipients now lives there too.

Net: this is a port, not an integration. There is no adapter that makes it a Laravel package.

Technical risk.

Key questions.

1. Do we actually run Symfony + CruditBundle? If no, this is disqualified regardless of merit.
2. Is email management (templates, recipients, resend, unsubscribe) a product surface we need, or is it a solved problem via Mailables + a small admin resource?
3. Where does mail/recipient status derivation live — entity or Crudit layer — and can it be consumed headless (API/console) without the admin UI? 1.14.5 suggests not cleanly.
4. How are sends batched and queued — synchronously in a controller, or via Messenger? What is the blast radius of a mid-batch failure?
5. Where do attachments live (local FS vs. object storage), and what is the retention/GC policy?
6. What is the maintainer's commitment level, and are we prepared to fork on a 1.14.x pin if releases stop?
7. Does the unsubscribe flow satisfy our compliance obligations (signed URLs, list-unsubscribe headers, audit trail)?

Integration Approach

Stack fit.

• Good fit: Symfony 6.4/7.x/8.x applications already running CruditBundle, Twig, and Doctrine, where an admin needs to author, schedule, cancel, and resend templated mail. Symfony 8 compatibility landed in 1.9.0 and the bundle has since moved through 1.12–1.14, so it is current with the framework.
• Poor fit: any Laravel application; any Symfony app without Crudit (you inherit the UI dependency for no benefit — and now also lose the CC-aware status logic); any product needing advanced campaign features (A/B, analytics, journeys) — that's a dedicated ESP, not this bundle.

Migration path — Symfony + Crudit (recommended, if applicable).

1. composer require 2lenet/hermes-bundle, run the Flex recipe, register the bundle.
2. Apply the shipped Doctrine migrations; review Mail / Recipient schema for PII and indexing.
3. Configure the Mailer DSN and pick a real transport (do not ship with null://).
4. Author base Twig/MJML templates; decide CKEditor vs. MJML-only for the editable regions.
5. Wire the unsubscribe route and verify signed-link behaviour (a fix shipped in 1.8.6).
6. Expose the Crudit dashboard sections behind an admin role; re-verify status display for To/CC mixes on 1.14.5.
7. Smoke-test send, cancel, resend, attachment deletion, and CC-only / CC-failure status in staging before enabling for real recipients.

Indicative effort: 1–2 weeks to a first production send for one engineer familiar with Symfony.

Migration path — Laravel (recommended: do not port). Build a first-party equivalent on native primitives: Mail/Mailable + Markdown or Blade views, a mail_templates table with versioning, a queued SendMailJob per recipient, Filament/Nova resource for admin CRUD, signed unsubscribe URLs, and the transport of your choice. Explicitly model status across To and CC independently — 1.14.5 is a useful pointer that single-recipient status flags are an easy thing to get wrong. This preserves the only concepts worth keeping — template-as-data and per-recipient status — without importing Doctrine, Twig, or Crudit.

Compatibility notes.

• Pin exactly (1.14.x). The release cadence is frequent and small (1.14.4 → 1.14.5 is a single PR), so unpinned upgrades invite churn from upstream releases that touch the admin templates.
• Twig and Blade cannot share a rendering path cheaply; do not attempt a dual-engine setup.
• Config lives in Symfony YAML/services.yaml; there is no config/mail.php analogue to publish.
• Crudit itself is now a moving dependency; 1.14.x fixes are keyed to Crudit issue numbers, so Crudit version becomes part of your compatibility matrix.

Sequencing (Symfony path). Spike in a branch → schema migration + PII review → template authoring → transport/queue configuration → unsubscribe/compliance sign-off → admin permissions and CC-status verification → staged cutover. Do the queue decision before template authoring; it changes how resend and cancel behave.

Operational Impact

Maintenance. The project is actively released (1.14.5 latest, 1.11.0 translatable emails, 1.9.0 Symfony 8 support) with PHPStan and PHPUnit CI — better hygiene than most 2-star bundles. But it is agency-maintained with a very small contributor pool and 0 dependents, meaning you will be an early adopter and should budget for a pinned internal fork. 1.14.5 is a good-news signal — a one-line-ish correctness fix merged promptly — but it is also a reminder that you are tracking a fast, small-changelog release train. Treat "we can maintain this ourselves" as a prerequisite, not a fallback.

Support. No commercial support, no SLA, GitHub issues only. Expect to self-diagnose. The source is readable, which partially offsets thin documentation — the README defers to docs/index.md, and the 1.14.5 notes are a raw PR title, so release-note quality is low and you will need to read diffs for anything affecting status logic.

Scaling. Delivery scales fine — swap the Symfony Mailer transport for SES/Postmark/SendGrid. The scaling risk is on your database: one Recipient row per address, per-recipient error strings, resend actions, and CC sublists all imply write-heavy batch semantics. With CC recipients now folded into status, the per-mail status recomputation touch-points grow with CC list size — worth profiling on high-CC-volume mail. Above roughly 10k sends/month, verify batching and queuing before committing, and consider offloading recipient bookkeeping to a purpose-built ESP.

Failure modes to design around.

• Partial batch failure — per-recipient error capture exists (since 1.7.16), but you must define retry vs. abandon policy.
• Status misreporting on mixed To/CC mail — the pre-1.14.5 behaviour undercounted CC recipients; any dashboards or exports you build should be regression-tested against 1.14.5 rather than assumed correct.
• Cancel-send race — cancelling a mail while a worker is mid-flight; verify the state machine guards this.
• Attachment orphaning — attachment delete shipped in 1.9.3; confirm storage GC and object-store support if not local disk.
• Unsubscribe correctness — historically fragile (fixed in 1.8.6); regression-test it, since a broken unsubscribe is a compliance incident, not a bug.
• Admin-layer logic drift — fixes landing in the Crudit integration rather than the domain mean a fork that drops Crudit silently drops correctness fixes. Assign an owner.
• Fork drift — once forked, upstream security and correctness fixes (like 1.14.5) require manual cherry-picks.

Ramp-up. For a Symfony/Crudit team: roughly 1–2 days for a mid-level engineer to be productive, mostly on template authoring conventions and Crudit admin wiring. For a Laravel team: weeks of adapter work plus a permanent maintenance obligation — the correct TPM call remains to decline adoption, harvest the data-model ideas (including explicit CC-aware status), and build the thin equivalent on native Laravel mail primitives.