Inky Laravel Package

Technical Evaluation

Architecture fit. The package is a small, single-purpose PHP library that ports ZURB's Inky template transformer (the layer that converts Foundation for Emails grid/component tags such as <row>, <columns>, <callout> into table-based HTML). Architecturally it is a plain Composer library with one entry-point class, Hampe\Inky\Inky, exposing releaseTheKraken($html) plus alias and custom-component-factory extension points. It has no Laravel service provider, facade, config file, or Blade integration, so "Laravel fit" is really "PHP fit" — you can composer require it and call it from a Mailable, command, or job, but you own the wiring. The extension model (a ComponentFactoryInterface registry keyed by tag name) is reasonable and would let a team add house-specific email components without forking.

Integration feasibility. Low-to-moderate. The package has 1 star, 0 dependents, and "readme"-level maturity, meaning there is no evidence of a test suite, changelog, tagged releases, CI, or PHP-version matrix. More concerning is provenance: the package is published as filipegar/inky but the README, examples, and namespace are all Hampe\Inky, strongly suggesting this is a re-publish/fork of another author's library with the upstream identifiers left intact. That is not disqualifying for an internal spike, but it means you are depending on code whose maintainer-of-record, security posture, and update path you cannot verify. The README itself contains a missing semicolon in the addAlias example — a small signal that nothing is exercising the docs.

Technical risk. High. Key exposures:

• Upstream dependency decay. The parser is built on PHPHtmlParser\Dom, a library that has been effectively unmaintained for years. Any Laravel/PHP 8.2+ upgrade path inherits that abandonment, including potential deprecation warnings under PHP 8.3/8.4 and no fixes for parser edge cases.
• Spec drift. Inky is a moving target alongside Foundation for Emails. With no release history or changelog, you cannot tell which Inky version this port tracks, whether the default 12-column grid and component semantics match current ZURB output, or whether newer components (<button> variants, spacing helpers) are supported.
• Output correctness. The real risk in email templating is not "does it parse" but "does the emitted HTML survive Outlook/Gmail." Without a golden-file test suite comparing output against the reference JS Inky, every release or PHP upgrade is an unverified regression risk.
• Bus factor. One publisher, zero dependents, no issue triage. Assume you will own this code.

Key questions to resolve before adoption.

1. Which upstream Inky version does this track, and can we diff its output against the reference Node implementation?
2. Does PHPHtmlParser install cleanly under our current PHP and Laravel constraints, or does it force a downgrade/conflict?
3. Is this a fork of hampe/inky? If so, why not depend on the upstream package directly, and which one has more activity?
4. Are there any tests at all, and what is the license/attribution chain from ZURB through the PHP port to this fork?
5. Where in our pipeline would compilation run — build-time asset step or per-send in PHP — and what is the p95 latency on our largest template?

Integration Approach

Stack fit. Good at the language level, absent at the framework level. If the stack is Laravel, plan to bind Inky as a singleton in a service provider you own, inject it into a small EmailTemplateCompiler service, and call it from a Mailable's build() or a queued job. It does not hook into Blade, Laravel Mail's Markdown renderer, or Mail::send automatically; there is no config/inky.php, no facade, no publishable assets. Treat it as a vendor utility, not a framework package.

Migration path. The realistic paths, in order of increasing ownership:

• Reference toolchain: use ZURB's Node-based Inky/Foundation for Emails CLI in a build step, committing compiled HTML. Highest fidelity, adds Node to CI.
• This package at build time: run releaseTheKraken() in an artisan command or CI step, cache compiled output, ship static HTML. Best risk/effort tradeoff if the parser proves faithful.
• This package at send time: wrap in a compiler service with an output cache keyed by template hash. Simplest to adopt, but puts an unmaintained parser on the hot path of every email send.
• Vendor/fork: copy the source into app/Support or a private package, replace the Hampe\ namespace, and own the tests. Recommended if the PoC passes and the library is genuinely useful.

Compatibility. Assume compatibility only with Foundation for Emails 2-era Inky syntax; do not assume MJML, Tailwind-style email, or modern component-based frameworks are in scope. Watch for conflicts on PHPHtmlParser and any transitive Composer constraints, which is the most likely install failure mode on Laravel 10/11. Verify against your supported PHP matrix, including 8.3+ deprecation noise.

Sequencing.

1. Spike (1–2 days): install in a scratch Laravel app, compile 3–5 representative templates (a 12-column grid, a callout, a button, a nested row), and diff output against the reference Node Inky.
2. Contract tests: capture golden HTML fixtures for each component, including a full email rendered in Litmus/Email on Acid or equivalent.
3. Decide ownership: if the diff is clean, fork/vendor and pin; if not, fall back to the Node build step.
4. Wrap: expose a single EmailCompiler interface so the implementation is swappable without touching Mailables.
5. Roll out: behind a feature flag on one low-risk transactional template before widening.

Operational Impact

Maintenance. This is the dominant cost. The package is effectively unmaintained: no dependents, no release cadence, no visible issue activity, and a namespace that reveals it is a fork-of-a-fork. Budget for someone to own it — pinning a commit, tracking upstream ZURB Inky releases manually, and re-running golden-file tests on every PHP/Laravel upgrade. If the team cannot name that owner, do not adopt.

Support. Community support is effectively zero. ZURB's documentation covers the JavaScript Inky, not this port, so questions about PHP-specific behavior, alias handling, or custom ComponentFactoryInterface implementations will go unanswered. Internal documentation and the golden-file suite become the support surface.

Scaling. The parser is CPU-bound PHP string manipulation over a DOM, so cost scales with template size and email volume. At build-time compilation with cached output, scaling is a non-issue — you compile once per template version. At send-time compilation, expect single-digit-to-tens of milliseconds per template for typical layouts, with larger grid-heavy templates and deep nesting as the tail risk; queue-based sending absorbs this, synchronous request-path sending does not.

Failure modes.

• Install/dependency failure: Composer conflict or abandonment warnings from PHPHtmlParser blocking a framework upgrade.
• Parse failure: unhandled exceptions or silently dropped tags on unsupported components, producing emails that render acceptably in one client and collapse in Outlook.
• Output drift: templates that pass in Gmail but degrade in Outlook/Lotus-era clients because the port's table output diverges from reference Inky.
• Hidden divergence on upgrade: a PHP minor-version bump changes DOM parsing behavior with no upstream fix available.
• Ownership gap: the one person who understood the fork leaves, and no one can safely upgrade or debug it. Mitigations: golden-file output tests with real client rendering checks, a compiler abstraction so the dependency is swappable, build-time compilation with cached artifacts, and a hard rule that no email-critical template depends on this package without a maintained fallback.

Ramp-up. Developer ramp-up is low: the API is a constructor, releaseTheKraken(), addAlias(), and optionally addComponentFactory(). A mid-level PHP developer is productive in under a day. Domain ramp-up is the real cost — understanding Foundation for Emails constraints, which components exist, and how table-based output interacts with email clients. That knowledge is transferable to the Node toolchain and is worth building regardless of whether this package survives. Net recommendation: treat as a PoC candidate, not a production dependency until the fork decision, golden-file tests, and named owner exist; the opportunity score is attractive, but the maturity, provenance, and single-maintainer signals put this firmly in "evaluate, then vendor or replace" territory.