Inky Extra Laravel Package

Product Decisions This Supports

• Email as a first-class product surface, not an afterthought. If email quality (onboarding, receipts, alerts, lifecycle campaigns) affects activation or support load, this package lets the email layer be versioned, reviewed, and tested like the rest of the codebase instead of living in an ESP's WYSIWYG editor. That is a strategic decision about where email lives, and this package is a cheap way to keep it in-repo.
• Build vs. buy on the templating layer (not the delivery layer). It avoids building a custom PHP-to-email-HTML pipeline while also avoiding ceding template ownership to a vendor (Postmark/Mailgun/SendGrid templates). Delivery can stay with any ESP; templating stays with us. MIT license means no lock-in and no procurement cycle.
• Consolidating on a component vocabulary. Inky gives a small set of semantic components (<container>, <row>, <columns>, <button>) that map to email-client-safe table HTML. That is a design-system decision: one vocabulary, one set of responsive behaviors, fewer one-off templates that break in Outlook.
• Roadmap enablers it makes cheaper: localization (swap layouts/strings on a locale variable), personalization and conditional content in lifecycle campaigns, A/B variants as branches rather than duplicate templates, and reusable partials for shared headers/footers/legal blocks.
• Prioritization input: it lowers the marginal cost of each additional email, which changes the calculus on "should we add this notification?" from a design/frontend scheduling question to a backend backlog item. Expect scope creep in the notification roadmap — plan for it.
• Honest scoping caveat: this is a Twig ecosystem package (Symfony/Twig), not Laravel-native. Laravel ships Blade. The real decision for a Laravel team is "do we run a second templating engine for email only?" — that's a governance and maintenance decision, not just a composer require.

When to Consider This Package

Adopt when:

• You are already on Twig (Symfony, or Laravel with TwigBridge / a dedicated Twig environment used only for email rendering). The value collapses if Twig is being introduced solely for this.
• You need responsive HTML email and your team is backend-heavy with limited frontend/design-engineering capacity.
• You want templates in the repo, in code review, in CI — not in a vendor dashboard.
• Volume and variety are both growing (transactional + lifecycle), so per-template effort matters.
• You want server-side rendering only — no client-side JS in email, no third-party rendering service in the send path.

Look elsewhere when:

• Laravel with Blade only. Adding Twig for one filter is real overhead: a second loader, cache path, escape semantics, IDE/linting story, and onboarding cost. Alternatives: precompile MJML at build time and render with Blade; Blade components plus a CSS inliner (e.g., tijsverkoyen/css-to-inline-styles); or a hosted template service if marketers need self-serve.
• Non-technical users must edit or preview templates in real time. Inky is a developer syntax. That's a headless CMS or ESP template editor problem, not a Twig filter problem.
• You need advanced client features — AMP for Email, sophisticated dark-mode handling, heavy interactivity. Inky's output is deliberately conservative; that's a feature for compatibility and a limitation for ambition.
• You need a design-first workflow (Figma-to-email, visual builders) or your designers own the email output end-to-end.

Risks to price in before committing:

• Security history. CVE-2026-46637 (XSS / pre-escaping of input on HTML-emitting filters) was fixed in v3.26.0. Pin >=3.26 and have engineering verify escaping behavior end-to-end — the fix changes how input is escaped, so any template relying on the old behavior of inky_to_html needs review. Do not let a stale lockfile ship this.
• Small footprint. ~166 stars and 0 listed dependents means little visible third-party battle-testing and a thin support surface. It is a thin wrapper over zurb/inky-php, so upstream Inky's maintenance velocity is your real longevity risk, not this package.
• Quality still requires external verification. Rendered HTML must be tested in real clients (Litmus / Email on Acid) and CSS inlined. This package does not solve deliverability, inlining, or client quirks.

How to Pitch It (Stakeholders)

To executives — the decision is small and reversible; frame it that way.

"Email is a customer-facing surface we currently maintain ad hoc. This is a single MIT-licensed dependency that lets our existing backend engineers produce responsive, on-brand emails from the same repository and review process as the rest of the product — no new vendor, no new headcount, no lock-in. The cost is roughly one dependency and a few days of integration; the upside is faster iteration on lifecycle and transactional email and fewer broken-rendering support tickets. I'm proposing a scoped pilot on 2–3 high-volume templates with a go/no-go at the end."

Set the success metrics before the pilot, and label them as targets to validate, not forecasts: dev hours per new template, email-client rendering defects per release, time from "we need an email" to "in production," and support tickets attributable to email rendering. Avoid quoting headline efficiency numbers you can't defend.

To engineering — be direct about what it is and what it costs.

"It's a Twig extension exposing a single inky_to_html filter; it compiles Inky component markup into email-safe table HTML server-side. No runtime services, no JS, no build step required. Two things to settle first: (1) whether we stand up a Twig environment for email only or use Twig more broadly — that's the actual cost, not the package; (2) escaping. Pin >=3.26.0 for CVE-2026-46637 and review how the pre-escape change interacts with our templates and autoescape settings before we write more than a couple of templates. Plan for CSS inlining and a client-testing pass as part of the definition of done."

To design and marketing — set expectations honestly.

"This does not give you a visual editor. It gives us a consistent set of responsive building blocks and a much faster loop from your design intent to a shipped email. You'll still review renders; you just won't be waiting on frontend capacity, and shared headers/footers/brand blocks become one component instead of copy-paste."

Pilot recommendation (one page, 3–4 weeks): pick two transactional templates and one lifecycle template; pin the dependency version; define the escaping and inlining conventions; run client-compatibility checks; measure against the metrics above; decide go/no-go. The decision to not adopt is cheap and should be explicitly on the table — for a Blade-only Laravel team, "no" is a legitimate and probably correct outcome.