Mjml Bundle Laravel Package

Product Decisions This Supports

• Transactional email templating: build vs. buy. This release keeps the MJML compiler integration current with MJML 5 (BinaryRenderer adapted for the MJML 5 binary). That matters for the "build vs. buy" call on responsive email: teams can keep authoring emails in MJML and relying on the upstream compiler rather than hand-maintaining table-based HTML per template.
• Roadmap: email template modernization. If a roadmap item is "move our transactional emails off brittle hand-coded HTML onto a component-based MJML system," this package is the PHP-side plumbing that makes that migration a template-authoring exercise rather than a rendering-infrastructure project.
• Design-system / brand consistency. MJML's component model gives product and design a shared vocabulary (sections, columns, buttons) that renders consistently across clients — supporting decisions to standardize email UI the same way we standardize web UI.
• Upgrade sequencing. The release is a compatibility patch for a major upstream (MJML 5). It informs when to schedule the MJML 5 upgrade: the PHP wrapper is ready, so remaining risk sits in our own templates and in the Node/runtime binary on our hosts.
• Localization and multi-market rollouts. Templating-layer emails make per-locale and per-market variants a content problem, not a code problem — de-risking international expansion timelines.
• Not a deliverability decision. This package renders HTML; it does not send, authenticate, or monitor. Sending infrastructure (ESP, SPF/DKIM/DMARC, bounce handling) remains a separate buy decision.

When to Consider This Package

Adopt when:

• You are on PHP/Symfony (this is mjml-bundle — a Symfony bundle, not a Laravel-native package). Laravel teams should treat it as a reference implementation and pair it with a plain MJML PHP wrapper or a small compile step, rather than assuming a drop-in.
• Your team already authors or wants to author email in MJML, and you want compilation inside the application build/deploy path instead of a manual design-tool export.
• You can guarantee a Node runtime or MJML binary on your build and production hosts (the BinaryRenderer shells out to the MJML CLI). If you cannot, prefer a hosted rendering API or precompiled templates checked into the repo.
• You want to ride upstream MJML 5 without owning the compiler integration yourself.

Look elsewhere when:

• You need a fully managed email platform (templates + sending + analytics + compliance). This is a compiler integration, not an ESP.
• You are Laravel-first with no Symfony tolerance — the integration points (bundle config, Twig-oriented assumptions) will fight your stack; the effort saved is smaller than it looks.
• You have very few, rarely changing emails — hand-maintained HTML plus an email-testing service is cheaper than adding a Node dependency to your deploy pipeline.
• You cannot accept a runtime binary dependency in production (e.g., locked-down containers, no Node allowed) — compile at build time instead, or use a SaaS renderer.
• You need visual editing for marketers. MJML is a developer/designer authoring format; non-technical self-serve editing implies a different product choice.

How to Pitch It (Stakeholders)

For executives: Email is a revenue and trust surface that is usually built ad hoc and breaks quietly in Outlook. This release is small — it aligns our PHP-side email rendering with MJML 5, the current version of the open-source standard for responsive email — but it is the signal that this dependency is actively maintained and tracking upstream. The business case is cost avoidance and speed: one templating approach instead of per-campaign hand-coded HTML, fewer client-specific rendering bugs, and faster localization rollouts. Cost is low (open-source library; engineering time is the real investment). Risk is contained: no breaking changes here, and the main dependency — a Node binary on our build hosts — is an infrastructure choice we control.

For engineering: v3.11.0 adapts BinaryRenderer for MJML 5. It is a compatibility release, not a feature release — no public API changes called out, so upgrading from 3.10.x should be a version bump plus a regression pass. Action items: confirm the MJML 5 CLI is pinned and available wherever BinaryRenderer executes (CI and production), re-render the full template suite against MJML 5 since major-version compiler changes can shift output, and re-run cross-client checks (Outlook desktop, Gmail app) rather than trusting the compiler upgrade alone. Treat the binary as a first-class deploy dependency: pin the version, fail the build loudly if it is absent, and prefer build-time compilation so production never depends on a shell-out. If we are Laravel-only, budget a small adapter layer — this is a Symfony bundle — or evaluate a lighter wrapper before committing.