Looly Gutenberg Laravel Package

Product Decisions This Supports

• Informs adoption/expansion of Twig-based templating in a Laravel application, especially where product features depend on customizable views, emails, notifications, admin-editable layouts, or tenant-specific templates.
• Release 1.0.9 adds object support in Twig templates, reducing the need for custom extensions or array-normalization glue when passing view models, DTOs, or domain objects into templates.
• Supports build-vs-buy decisions: use the package as the Twig integration layer rather than building and maintaining a custom Laravel/Twig bridge.
• Raises a product-design consideration: object exposure in templates should be intentional. Prefer read-only DTOs/view models and allowlists over exposing sensitive Eloquent models directly.

When to Consider This Package

• Consider it when the product needs Twig as a first-class templating option in Laravel, the team has Twig familiarity, and templates need access to structured object data rather than only arrays/scalars.
• 1.0.9 is relevant if prior adoption was blocked by weak object support or required custom glue for passing view models/DTOs into templates.
• Validate package maintenance, Laravel/PHP version compatibility, documentation for object access, sandbox/security posture, and test coverage before committing.
• Look elsewhere if Blade is sufficient, there is no Twig requirement, strict template sandboxing forbids object exposure, or the product needs commercial support/SLA and performance guarantees beyond what the package documents.

How to Pitch It (Stakeholders)

• Executive summary: 1.0.9 is an incremental capability release, not a reported breaking change. It makes the package more usable for object-oriented template data, which can reduce custom development and unlock customizable template use cases.
• Engineering summary: Twig templates can now receive supported objects, enabling cleaner passing of DTOs/view models. Adopt via a small pilot, document which objects are template-safe, add tests for object rendering and access boundaries, and avoid exposing sensitive domain models without an allowlist or read-only wrapper.