Inky Laravel Package

Product Decisions This Supports

• Build vs. buy for transactional email markup. Inky lets authors write semantic tags (<container>, <row>, <columns>, <button>) and compiles them to table-based, email-client-safe HTML. That means your team writes email templates like normal templates instead of hand-maintaining nested tables and Outlook conditional comments — a real reduction in the cost of every new notification your product ships.
• Roadmap sequencing for notification-heavy features. If your next two quarters include onboarding sequences, order/receipt emails, digests, or multi-tenant white-label templates, a compiler like this shortens the loop between design and send. It is an enabler for those features, not a feature itself.
• Where template authoring lives. Because it's a server-side PHP parser, templates can be rendered from Blade views, database rows, or per-tenant storage and compiled at send time — which supports a product decision to let non-engineers edit email content without a deploy or a Node build step.
• Toolchain decisions. Adopting it implies no Node.js in CI for email compilation. That's a legitimate simplification argument for a PHP-only team, and it's the strongest product-level reason to pick a PHP port over the canonical ZURB Node package.
• Output fidelity is a shipped-product concern, not a library detail. The 1.3.6.2 patch fixes two defects with direct customer-visible impact: <style> blocks being stripped from compiled output (email-level CSS silently disappearing) and a regression introduced in 1.3.6.0 that broke nested spacers (layout collapse on multi-section emails). Both are reminders that a compiler bug here is a rendering bug in a customer's inbox, and that the 1.3.6.0 line shipped a breaking regression.
• Decisions it does not unlock. Dark-mode-safe email, modern client quirks (Gmail clipping, Apple Mail privacy proxy), or a WYSIWYG editor for marketers. The Inky tag vocabulary still requires someone who knows the spec, and the compiled output reflects Foundation for Emails as of ~2016.

When to Consider This Package

Consider it if all of the following hold:

• You're on Laravel/PHP and want to keep the email pipeline in one language with no Node build artifact.
• Your design system is already Foundation for Emails, or your emails are simple enough that the 2016 baseline covers your client matrix.
• Your emails are internal-facing or low-stakes (internal alerts, simple receipts) where a client-rendering edge case is an annoyance, not a revenue event.
• You're running a short spike and are willing to pin or fork.
• You pin to 1.3.6.2 or later — 1.3.6.0 is known-broken for nested spacers and 1.3.6.2 also bumps the PHPHtmlParser dependency to 1.7.0, so the transitive tree needs a lockfile review before you commit.

Look elsewhere if any of these are true — and note that with 44 stars, 0 dependents, and a single bugfix patch (1.3.6.2) following a release gap stretching back to 2016-08-30, the default answer for new work should still be "elsewhere":

• Maintenance risk is unacceptable. The 1.3.6.2 patch is a sign of life, not a maintenance commitment: two bugfixes and a dependency bump, no PHP 8 compatibility declaration, no dependent packages, no downstream validation, no CI or test signal. There is still no one contractually on the hook to patch a parser bug or a PHP deprecation. Treat a single patch after years of dormancy as evidence the project can be fixed quickly, not that it will be maintained.
• You need modern email capability. MJML has a broader, better-maintained feature set and tooling; hosted template builders (SendGrid/Mailgun/Postmark, Litmus) handle previews and client testing.
• You still want the Inky authoring model. lorenzo/pinky is a more actively maintained PHP port of the same spec; pairing it with a maintained CSS inliner (tijsverkoyen/css-to-inline-styles) gives you the same workflow without the dead-dependency problem. This is the pragmatic middle path and the one I'd evaluate first.
• You need vendor support, SLAs, or a security review trail. MIT license is fine, but an unmaintained parser still parses untrusted-ish input, and this release pulls in a newer PHPHtmlParser — that upgrade path should be treated as a supply-chain review item, not a footnote.

Decision rule: treat hampe/inky as a prototype dependency. The 1.3.6.2 patch slightly lowers the fork cost (you now have a recent, working base that fixes the two worst known rendering bugs) but does not change the ownership math. Budget a fork-and-own cost — roughly a few days per year of maintenance plus PHP upgrade work — if you adopt it; if that cost isn't fundable, don't adopt it.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed PHP library that lets us write responsive emails in simple markup instead of hand-coding table layouts, which shortens delivery time on every customer-facing email we ship. It's free and has no vendor lock-in. A new patch (1.3.6.2) fixes two real rendering bugs — styles being stripped and broken nested layout — which is good news, but it's the first release after a gap going back to 2016, with no downstream users. It is still unmaintained in any meaningful sense, so we should treat it as a time-boxed spike, not a foundation, and we have a maintained alternative (lorenzo/pinky) that gives the same workflow.

To engineering: It's a server-side Inky compiler — render your Blade template, compile it to email-safe HTML, hand the result to Laravel's mailer. The wins are no Node in CI and templates that live in the repo or the database. The new 1.3.6.2 patch fixes stripped <style> tags (#7), a 1.3.6.0 regression breaking nested spacers (#6), and bumps PHPHtmlParser to 1.7.0 — so pin at or above 1.3.6.2 and avoid 1.3.6.0. The costs are unchanged: an unmaintained dependency, still no declared PHP 8 compatibility, a transitive dependency we now inherit at a newer version, and a likely fork if we keep it. Recommendation: spend half a day evaluating lorenzo/pinky plus a CSS inliner alongside it; the patch makes hampe/inky a more viable fallback than it was, but not the default choice.