Twig Components Laravel Package

Technical Evaluation

Architecture fit

ibexa/twig-components is not a general-purpose component library — it is a split-out subpackage of Ibexa DXP, a commercial Symfony-based DXP. The README states plainly: "This package is part of Ibexa DXP. To use this package, install Ibexa DXP." Its actual function is dynamic Twig component registration and rendering inside the Ibexa kernel (Symfony DI container, Twig extensions, Ibexa design engine/theming). The only concrete component surfaced in the release history is ibexa.Table (v5.0.7, IBX-10990).

This means the architecture fit question is really "are we an Ibexa DXP customer?" If yes, this package is already in the dependency graph and the assessment is about upgrade planning and template standardization. If no, there is no viable adoption path — it is not independently installable, and pulling it into a plain Symfony or Laravel app would drag in ibexa/* kernel dependencies it cannot run without.

Technical risk

Key questions

1. Do we hold an active Ibexa DXP subscription (BUL) or a trial grant (TTL)? Without one, this evaluation terminates.
2. Which DXP line are we on — 4.6 LTS or 5.0 — and does our upgrade roadmap land on a version where ibexa.Table is available?
3. Are we consuming this transitively via the ibexa/dxp meta-package (recommended) or pinning it directly? Direct pinning creates upgrade friction.
4. What does our current template layer look like — are we already using Ibexa's design engine and component conventions, or do we have bespoke Twig macros that would collide?
5. What is the exit cost if we leave Ibexa? Any template built on these components is non-portable.

Correction to prior internal assessments: earlier drafts framed this package as a Laravel/Blade candidate with spatie/laravel-twig bridging and "30% faster UI delivery." That framing is not supportable from the source material. There is no Laravel integration, no Blade interop, and no documented pagination/sorting/data-binding API. Those claims should not be used in any stakeholder material.

Integration Approach

Stack fit

Requires PHP + Symfony + Twig + Ibexa DXP kernel. It is a non-fit for Laravel, Blade, Vue, or React stacks and a non-fit for standalone Symfony applications. The realistic adoption scope is: existing Ibexa DXP projects, or a DXP selection decision where component-based templating is a scored criterion.

Migration path

• Greenfield / new DXP build: adopt Ibexa's component conventions from day one; use ibexa.Table for tabular views instead of hand-rolled Twig macros.
• Existing DXP install: do not retrofit mid-cycle. Bundle the change into the next planned DXP upgrade so component registration, theming overrides, and regression testing happen once.
• Non-Ibexa stack: no migration path. Record as evaluated-and-rejected with the license and platform-coupling rationale.

Compatibility

Match the package line to the DXP line (4.6.x with DXP 4.6 LTS, 5.0.x with DXP 5.0). Consume transitively; if a direct Composer constraint is unavoidable, pin to the DXP-matched minor and treat upgrades as paired with DXP upgrades. PHP version constraints and Twig major version follow the DXP baseline, not this package.

Sequencing

1. License/procurement confirmation (blocking gate).
2. Confirm DXP baseline version and whether ibexa.Table is in scope on that line.
3. Inventory current Twig templates and macros; identify duplication that components would remove.
4. Pilot ibexa.Table in one low-traffic, high-visibility view (e.g., an admin listing) to validate theming override effort and rendering cost.
5. Establish a template override convention through the design engine before broad rollout.
6. Expand to additional views only if the pilot's override effort is lower than the macro code it replaced.

Operational Impact

Maintenance

Low churn, zero control. The package is maintained by Ibexa in lock-step with DXP; our maintenance obligation is really DXP upgrade participation, not package-level patching. Budget for re-testing component-rendered views during every DXP upgrade, since behavioral changes may not be enumerated in this repo's release notes.

Support

Vendor support is the only support channel and it is subscription-gated. With 0 stars and 0 dependents there is no community knowledge base, no third-party tutorials, and no Stack Overflow corpus. Any internal ramp-up material must be written by us.

Scaling

Rendering cost is standard Twig compilation; the incremental load is dynamic component registration and template resolution. Profile once during the pilot with realistic dataset sizes for ibexa.Table, then rely on Twig template caching. This is not a horizontal-scaling concern at typical DXP page volumes.

Failure modes

• License lapse or non-renewal — the most consequential failure mode; it removes both upgrade rights and support, and there is no fallback fork available under BUL/TTL terms.
• Version skew — package pinned ahead of or behind the DXP baseline, causing component registration or rendering failures that surface at template render time, not at boot.
• Template override collisions — custom theme overrides silently shadowing vendor component templates after an upgrade.
• Vendor roadmap change — Ibexa re-absorbs or renames the split package (the repo lineage traces back through eZ Systems), invalidating our pinned references.

Ramp-up

Engineer ramp-up on the package itself is days, not weeks — the surface is small and, on current evidence, essentially one component. The real cost is DXP-wide context: Symfony DI tagging conventions, Twig component registration, and the design engine's override mechanism. Plan for one developer to own the component/template layer and to write the internal usage notes, because none exist externally.

TPM leverage summary

This is a procurement and upgrade-planning lever, not an engineering velocity lever. Its value in a roadmap review is threefold: (1) it strengthens the case for standardizing on Ibexa's component conventions rather than bespoke Twig macros; (2) it is a concrete, low-risk deliverable to attach to a DXP upgrade milestone; (3) it is a legitimate input to a DXP selection scorecard. It should not be presented as a cost-saving or acceleration initiative on its own — the measurable benefit is reduced template duplication inside an environment we are already paying for.