Amp Html Bundle Laravel Package

Getting Started

First, a necessary reality check: this is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/amp-html.php auto-merge. You can't composer require ylly/amp-html-bundle into a Laravel project and expect anything to happen — the bundle class simply won't be loaded. So "getting started" for a Laravel developer really means extracting what the bundle does rather than using it.

The practical path:

1. Read the bundle's source first, specifically DependencyInjection/ and any Services/ or Converter/ classes. The conversion work is almost certainly delegated to lullabot/amp (a Masterminds/html5 + QueryPath pipeline that rewrites <img> → <amp-img>, <video> → <amp-video>, etc.). The bundle itself is thin glue.
2. Install the underlying library, not the bundle. Check its abandon status first — lullabot/amp has been unsupported for years.
3. First real use case: take a stored HTML fragment (product description, blog body, CMS article) and emit an AMP-compliant version for a separate /amp/... route, with <html ⚡>, <link rel="canonical">, and the required AMP boilerplate.

If you must integrate, wrap the converter in a small AmpHtmlConverter service bound in your AppServiceProvider, and hide it behind an interface so you can swap it later.

Implementation Patterns

• Blade directive over Twig filter. The bundle ships a Twig extension ({{ content|amp }} or similar). In Laravel, register a custom Blade directive @amp($html) that resolves your converter service and echoes the result.
• Convert at save-time, not render-time. AMP transforms are deterministic and non-trivial. Put the conversion in a queued job (ConvertContentToAmp) fired on model save, and store the result in a body_amp column. Render-time conversion will bite you on cache misses and list pages.
• Separate view + separate route. Keep a dedicated resources/views/amp/show.blade.php with the AMP boilerplate and @yield/@section for the converted body, plus a route group (e.g. /amp/{slug}) so the canonical desktop page can point to it via <link rel="canonical"> and <link rel="amphtml">.
• Register custom AMP tags explicitly. If you port the bundle's logic, replicate the converter's tag registration from its DependencyInjection/Configuration.php — custom components like amp-carousel or amp-iframe need to be whitelisted or they get stripped.
• Validate in CI. Add amphtml-validator (the official npm tool) or a PHP equivalent to your test suite and validate a handful of representative outputs. Don't trust the converter — it emits close to valid AMP, not always valid AMP.

Gotchas and Tips

• composer require will succeed but do nothing useful. The bundle's DependencyInjection extension is only invoked by Symfony's kernel. In Laravel you'll get an unused package plus dead autoload entries. Skip the bundle; take the ~30 lines of conversion glue and leave the rest.
• 0 stars, 0 dependents, abandoned dependency. This is a wrapper around lullabot/amp, which is itself deprecated. Treat it as reference code, not a dependency you want in production in 2024+.
• AMP itself is deprioritized. Google no longer requires AMP for Top Stories or mobile search. Unless you have a specific AMP-for-Email or edge/CDN requirement, question whether the pipeline is worth building at all before you spend a sprint on it.
• Config quirks when porting. Symfony config trees map to converter constructor arguments in non-obvious order, and several transforms default to off. If you copy the service definition, diff it against the converter's required args rather than assuming defaults match.
• Invalid output usually traces to input HTML, not the converter: missing <html ⚡> in templates, unescaped & in URLs, inline <style> the converter refuses to hoist, or <script> tags it silently drops. Run the validator on the raw input first when debugging.
• The Twig extension is the portable jewel. It's typically a single class with one method — port it to a Blade directive and you've captured most of the bundle's value with none of its baggage.
• Don't fork the bundle. The maintenance surface of a thin wrapper is tiny, and forks of 0-star packages rarely attract contributors. Vendor the 30 lines you need into your own codebase and own them.