Laravel Inky Laravel Package

Product Decisions This Supports

• Putting transactional email on the roadmap as a product surface. Receipts, password resets, shipping notifications, and onboarding sequences are among the most-opened messages a product sends — and the ones most likely to render badly. This package lets engineers author them from semantic components (<container>, <row>, <columns>, <button>) that compile to the table-based HTML Outlook and Gmail actually render. The decision it unlocks is whether to schedule an email refresh at all: cheap, low-risk iteration is the precondition for treating email design as planned work rather than reactive firefighting.
• Build vs. buy for email templating — an ownership decision, not a library choice. A code-owned compiler in Blade/Mailables keeps templates version-controlled, PR-reviewable, and shipped with deploys. A hosted template editor (SendGrid, Mailchimp, Mailgun) buys marketer self-serve editing at the cost of engineering control. Make that fork explicit on the roadmap, because it determines who owns email content for years.
• Standardizing the email framework before template count grows. Inky/Foundation vs. MJML is a standards call best made at three templates, not thirty. If the front end is already Foundation, this aligns web and email component vocabulary; if not, adopting it forces the choice. Either way, decide once.
• Converting a defect class into a measurable win. A meaningful share of "the button is broken in Outlook" tickets trace to hand-written table HTML. A compiler removes that class. Track escaped email defects per release and QA hours per template change before/after so the improvement is defensible at the next planning cycle.
• Budgeting the whole pipeline, not just the compiler. Inky is a structural compiler: it does not ship Foundation's SCSS, inline CSS, or validate cross-client rendering. The realistic budget is three line items — compiler, CSS inliner/asset pipeline, and preview/regression harness. A PM who greenlights "add the Inky package" without the other two ships unstyled tables.
• Naming an owner for a dependency with no community behind it. Zero stars, zero dependents, one maintainer. Adoption means designating an internal owner and accepting a standing tax (~1–2 engineer-days per Laravel major). That is a staffing commitment; make it consciously or not at all.
• Running a cheap, reversible experiment. The integration is thin and rollback is a one-line view swap on a single Mailable. Cost of finding out is 3–5 engineer-days; cost of being wrong later is near zero. That asymmetry favors a timeboxed pilot over more analysis.

When to Consider This Package

Adopt only when all of these hold:

• The stack is Laravel/PHP and mail goes out through Mailables and Blade views — the default posture.
• The team or inherited codebase already writes Inky/Foundation for Emails markup, or has standardized on Foundation for the front end.
• Templates should live in the repo, code-reviewed and shipped with deploys, rather than edited in a vendor UI.
• Transactional template count is growing and hand-maintained table HTML has become a visible maintenance tax.
• You will name an internal owner and pin an exact version — i.e., treat this as unvetted third-party code you now maintain.

Look elsewhere — or plan to own the integration — when:

• You're not on Laravel, or MJML's larger community and active maintenance fit better. The honest comparison is never "this package vs. nothing"; it is this package vs. wrapping the underlying inky PHP library in-house (~200–400 LOC you control) vs. MJML vs. status quo.
• Marketers need to edit templates without a deploy, or you need per-campaign drag-and-drop. That is a hosted template product, not a compiler.
• Maintenance risk is unacceptable for compliance or uptime obligations demanding a security contact and release cadence. Zero stars, zero dependents, one maintainer, unknown Laravel 10/11 and PHP 8.2+ compatibility — unproven, not merely niche.
• You're standardizing on Mail::markdown(), which is maintained upstream and accessible by default. Inky is an upgrade in layout control and a downgrade in maintenance posture; migrate only templates where layout is genuinely constrained.
• You need modern CSS, dark mode, or AMP for Email, where table-based output is limiting.

Gating questions before commitment: declared Laravel/PHP versions with CI evidence, which Inky implementation is wrapped and at what pin, last commit and license, whether compiled output is cached, partials/variables support, coexistence with Markdown mailables, and whether a render helper exists for tests and local preview. If these cannot be answered from the repo in under an hour, treat that as a signal and proceed to the fork path.

How to Pitch It (Stakeholders)

To executives: Transactional email — receipts, password resets, shipping notices — is a high-visibility surface that today costs disproportionate engineering and QA time because email clients render HTML inconsistently. This lets engineers write simple, readable templates that compile automatically into client-safe HTML, shortening the cycle from design change to shipped email and cutting "it looks broken in Outlook" defects. It is free and open source, keeps templates in our own codebase, and carries no per-seat or per-send vendor cost. The trade-off is that it is a small, lightly adopted project, so we should run it as a low-cost, easily reversed experiment: the integration is thin and swappable for MJML or a hosted editor if requirements change. Ask: one engineer, one week, one template in production, with a defined abandon trigger.

To engineering: A thin Laravel wrapper that runs Inky compilation over mail views, so templates stay in Blade and ship with deploys — no vendor lock-in, no new runtime service, and the Mail/queue/transport path is untouched. It handles structure only; we still own CSS inlining and Foundation assets. Pin the dependency exactly and assume we may fork or vendor it — the wrapper is plausibly a few hundred lines, so the fallback is cheap. Recommended sequence: a 1–2 day spike on three representative templates (receipt, multi-column marketing, nested-component edge case), diff output against canonical Node Inky as a fidelity gate, then a cross-client render check as go/no-go, then a fork-or-vendor call, then migrate one low-risk template behind the existing Mailable interface before going broad with a snapshot test per template.

To design and marketing: You get component-level consistency between web and email and faster turnaround on layout changes, because designers specify in a shared Inky vocabulary instead of negotiating table hacks. What you do not get is self-serve editing — each change is a PR and a deploy. If campaign-speed editing is a requirement, say so now; that pushes us toward a hosted template product instead, which is a different and larger budget.