Twig Components Laravel Package

Product Decisions This Supports

• Platform upgrade planning (the main one). This package is an internal Ibexa DXP bundle, not a standalone library. The real decision it informs is which DXP version line you commit to — it ships parallel 4.6.x and 5.0.x branches, so the choice of platform version determines the component set you get. Treat it as an upgrade-cadence input, not a build-vs-buy input.
• Template standardization inside Ibexa. It supports decisions about consolidating ad-hoc Twig partials into registered, reusable components so editorial and admin views render consistently across bundles. The only substantive feature visible in the release trail is ibexa.Table (v5.0.7), which points at structured-data rendering — content listings, admin grids, back-office tables.
• Build vs. buy — already answered. For teams on Ibexa DXP with an active subscription, this is included; there is no separate purchase or evaluation decision. For anyone else, the answer is "build": use Blade components, Symfony UX Twig Components, or your own design system. Do not fund an integration effort to import this into a non-Ibexa stack.
• Not a lever for Laravel product decisions. Prior notes in this repo assumed a Laravel + spatie/laravel-twig integration path and attributed speed and feature claims (pagination, sorting, 30% velocity) to the package. None of that is supported by the README, the release notes, or the dependency graph. Those claims should not enter a roadmap or a business case.
• Roadmap signal quality. Release history is dominated by "no significant changes" and CI chores. That is reassuring for stability but means you should not plan roadmap work around frequent capability drops from this package; assume it moves with the platform, not ahead of it.

When to Consider This Package

Consider it when:

• You run Ibexa DXP (4.6 LTS or 5.x) under a valid Ibexa BUL subscription, or hold a TTL trial for evaluation.
• Your views are Ibexa's Twig layer and you are actively reducing copy-pasted template markup across bundles.
• You want vendor-maintained table/UI components that track platform releases rather than in-house Twig macros you must maintain yourself.
• Procurement already covers Ibexa — incremental license cost is zero.

Look elsewhere when:

• You are on Laravel, plain Symfony, or any stack outside Ibexa DXP. The README's only usage instruction is "install Ibexa DXP"; there is no standalone installation path and the bundle assumes Ibexa conventions and services.
• You need public documentation, community support, or independent adoption evidence. The repo shows 0 stars and 0 dependents; the documentation is a pointer to Ibexa's paid docs. Your confidence rests entirely on the vendor relationship.
• Licensing is unresolved. The license is BUL 2.4+ (business use, granted via subscription) or TTL 2.2+ (trial only) — flagged as NOASSERTION on the repo. Legal review is a prerequisite before embedding it in anything you distribute.
• You need rich client-side interactivity. These are server-rendered Twig components; interaction belongs to your JS layer.
• You require guaranteed table behavior (sorting, filtering, pagination). Only the component's existence is documented. Verify the actual feature surface in code before committing it to a product requirement.

How to Pitch It (Stakeholders)

For executives: "This isn't a new purchase or a new vendor — it's an internal piece of Ibexa DXP, the platform we already license. Its value is narrower than it sounds: it lets our Ibexa front ends share UI components instead of duplicating templates, which lowers maintenance cost on those projects. It has no value outside Ibexa, no independent adoption, and its license is tied to our subscription. So the framing is reduce template duplication on existing Ibexa work, not new capability or speed gain — we have no data supporting a velocity number, and I'd recommend against quoting one."

For engineering: "It's a Twig component registration/rendering bundle for Ibexa DXP. The only feature-level change in the recent release trail is ibexa.Table in v5.0.7; most releases are 'no significant changes' or CI fixes, and 4.6 and 5.x are maintained in parallel. Two asks before we commit: (1) pin to the branch matching our platform version and confirm the upgrade path; (2) read the ibexa.Table source and confirm whether it is presentation-only or actually handles sorting/pagination — the docs don't say, and I don't want it in a requirement until we know. There is no Laravel or Blade story here; if anyone proposes bridging it into a non-Ibexa app, that's unbudgeted integration work with no community support behind it."