- What is hampe/inky and what problem does it solve?
- hampe/inky is a Laravel-friendly PHP package that implements Zurb Inky-style email templating. It lets you write semantic email markup such as container, row, and columns instead of hand-written table HTML, then compiles it into responsive, email-client-friendly tables. The package is a single-purpose transform: Inky markup in, table-based email HTML out.
- How do I install hampe/inky in a Laravel app?
- Install it with Composer using composer require hampe/inky. The package has no service provider, facade, or config file, so there is nothing to register or publish. You instantiate or call the transform class directly in your application code.
- Does hampe/inky support Laravel 10, 11, or 12?
- hampe/inky has no Illuminate coupling, so it is not tied to Laravel's service container or package discovery. That makes Laravel integration mechanically simple, but you must still verify its PHP and dependency constraints in composer.json. The bigger compatibility risk is the underlying PHP HTML parser line, which may conflict with newer PHP versions before Inky itself does.
- How do I compile Inky tags in a Blade email view?
- Author your email in a Blade view using Inky components, render that view to a string, then pass the rendered HTML through hampe/inky's transform method before handing it to your mail transport. Keep the transform as one seam between Blade rendering and transport. Escape any dynamic content before the transform step rather than after it.
- What are alternatives to hampe/inky for Laravel email templates?
- Alternatives include using Zurb Inky through its Node-based build tooling, using MJML with a separate compilation step, or staying with Laravel's own Markdown and Blade mail components and hand-written tables. hampe/inky's advantage is that it keeps the Inky transform inside PHP without a Node build. Its disadvantage is that you inherit an aging parser dependency and a small maintainer footprint.
- Will hampe/inky work on PHP 8.2 or PHP 8.3?
- That is not guaranteed from the package description alone. The release notes for 1.3.6.2 mention an update to PHPHtmlParser 1.7.0, an older parser line that is a likely source of PHP 8.2 or 8.3 constraint conflicts. Test composer require or composer update in a throwaway branch and inspect the full transitive dependency tree before committing.
- What known bugs or regressions does hampe/inky have?
- The supplied evaluation notes that 1.3.6.0 broke nested spacers and that there is a reported issue about style tags being stripped out. Those are layout-affecting defects that reached users, which suggests the upstream regression suite does not cover the full component matrix. Budget for your own golden-file tests around the components and nesting patterns you actually use.
- Is hampe/inky actively maintained?
- It appears to be a single-maintainer project with sporadic rather than proven release cadence. The 1.3.6.2 release includes a dependency bump and references tracked issues, which is evidence of a live maintainer, but it does not establish a roadmap or regular releases. Treat it as a bus-factor-one dependency and keep an interface plus a fork or vendor contingency.
- Is hampe/inky safe for rendering user-supplied content?
- Do not treat it as a sanitizer. The parser runs on rendered template strings, so the safe pattern is still escape first, transform second, and never pass raw untrusted HTML into the transform. The pure-PHP parser reduces classic libxml external-entity exposure, but it adds an aging third-party component inside your trust boundary that you should review or pin deliberately.
- How should I test hampe/inky output across email clients?
- Use golden-file tests that snapshot the compiled HTML for each component and nesting pattern you rely on, because point releases have shipped layout regressions. Supplement those with quarterly Litmus or Email on Acid validation against your real client matrix. Unit tests alone will not prove output fidelity in Outlook, Gmail, or Apple Mail.