Content Decorator Bundle Laravel Package

Product Decisions This Supports

• Platform fit decision: Whether to layer a typed domain model and repository abstraction over Ibexa DXP's untyped content API, versus mapping content objects ad hoc in controllers and templates. Note upfront: despite the "Laravel/PHP" framing, this is a Symfony bundle for Ibexa (Ibexa 5.0 / Symfony 7.4 / PHP 8.3+ on 2.x; Ibexa 4.6 / Symfony 5.4 / PHP 8.1+ on 1.x). It provides no Laravel support.
• Build vs. buy for content modeling: If the team is writing repetitive mappers, factories, and repositories around Ibexa Content objects, this package is a candidate to replace that bespoke glue with a packaged layer that keeps a stable contracts surface (src/contracts) separate from implementation (src/lib).
• Roadmap and upgrade planning: The package's versioning is tightly coupled to the Ibexa/Symfony/PHP matrix (2.x vs. 1.x). That makes it a gating dependency in any platform upgrade plan — adopting it means our upgrade cadence is tied to a single small maintainer's release cadence.
• Feature scoping: Useful signal for estimating work on content-heavy features (catalog pages, editorial templates, listing pages) where a typed model reduces runtime errors and onboarding cost for new developers.
• Dependency risk accounting: With 2 stars, 0 dependents, and low opportunity score, this belongs on the "strategic but unproven dependency" list, not the "standard platform library" list.

When to Consider This Package

Consider adoption when all of the following hold:

• The application is built on Ibexa DXP (not Laravel, not another CMS), on a supported line (Ibexa 5.0 + Symfony 7.4 + PHP 8.3+, or Ibexa 4.6 + Symfony 5.4 + PHP 8.1+).
• The team is demonstrably spending recurring effort on mapping Ibexa content objects to application-level models.
• You value the layered bundle / contracts / lib split as an architectural guardrail and can absorb the cost of pinning to a specific platform line.

Look elsewhere (or build internally) when:

• You're on Laravel or any non-Symfony/non-Ibexa stack — this bundle will not integrate.
• You need a battle-tested dependency with a community, docs, tutorials, or a support contract. Two stars and zero dependents mean effectively no ecosystem, no third-party validation, and no safety net if the maintainer steps away.
• You cannot tolerate SemVer-pinned coupling to a narrow Ibexa/Symfony/PHP range, since widening constraints requires explicit maintainer approval.
• You need broad feature coverage today; treat this as a narrowly scoped accelerator, not a foundational layer.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed PHP library that standardizes how our application models Ibexa content — typed models and repositories instead of hand-written mapping code. It is only relevant if we run Ibexa DXP; it does not work with Laravel or other stacks. Adoption risk is high: minimal community, two GitHub stars, no downstream dependents, and a single-maintainer release cadence. Recommendation: treat it as an internal-facing accelerator, not a platform foundation.

For engineering: The package offers a clean split between a stable contracts surface and implementation details, DI wiring via a Symfony bundle, and typed repositories over Ibexa content. Quality gates are documented (composer validate --strict, CS, PHPStan, Deptrac, tag-driven releases), which is a positive signal. But it is early-stage and narrowly version-pinned. Proposal: run a short timeboxed spike on one Ibexa-based feature, measure the reduction in mapping code, and if it pays off, vendor or fork the package so we control the upgrade path. Do not commit roadmap-critical work to it without that fallback.