Hybrid Platform Ui Assets Laravel Package

Product Decisions This Supports

• Legacy stack triage and migration planning. This package is the asset-bundling layer for the eZ Systems Hybrid Platform UI (the eZ Platform admin interface). Its value to a PM today is as an inventory artifact: it tells you which third-party frontend libraries a circa-2017 admin UI depended on, which feeds migration scoping to Ibexa DXP or an alternative platform.
• Build vs. buy vs. vendor. The package embodies a "vendor the frontend deps" decision — it ships external JS/CSS dependencies through Composer tags rather than a modern npm/Webpack pipeline. Reviewing it clarifies whether your product should own asset compilation or consume a vendor-blessed bundle.
• End-of-life and support-window decisions. Last release July 2017, archived, zero dependents. This is a signal, not a feature: it supports a roadmap decision to freeze, replace, or formally retire any capability that still relies on it.
• Security and license compliance posture. GPL-2.0 plus a pinned, stale set of frontend libraries is a compliance and vulnerability-surface consideration. Useful input to a "do we keep shipping this?" risk register entry.
• Reproducibility of historical builds. For audit, incident response, or contractual "rebuild exactly what was shipped" obligations, the tagged asset sets are the reference point.
• It does not support new feature investment, competitive differentiation, or performance roadmap decisions — it is a mirror of someone else's assets, with no product surface of its own.

When to Consider This Package

Consider it only when:

• You are sustaining a legacy eZ Platform / Hybrid Platform UI deployment pinned to roughly 2017 and need the exact tagged asset versions to reproduce or patch a build.
• You are compiling an SBOM or dependency inventory for a legacy install and need to account for how frontend libraries entered the stack.
• You need forensic/reference material to understand what a predecessor team vendored, before replacing it.

Look elsewhere — decisively — when:

• You are starting any greenfield project, or working on a currently supported eZ/Ibexa release; modern Ibexa asset tooling does not route through this package.
• Your product is proprietary and license-sensitive; GPL-2.0 obligations on a bundled asset distribution need legal review, and there is no vendor actively maintaining it.
• You need maintained, patched, or security-updated frontend dependencies. Nothing here has moved since 2017, and the repository is archived with zero dependents — there is no community to absorb a CVE.
• You expect support, documentation, or upgrade paths. It ships with a README, releases, and nothing else.
• Practical alternatives exist: consume the underlying libraries directly via a lockfile you control, mirror them in a private Composer/npm registry, or migrate to the vendor's current asset pipeline.

How to Pitch It (Stakeholders)

For executives: This is a frozen artifact from a discontinued product line, archived since 2017, with no maintainers and no downstream users. There is no investment case and no strategic upside. The only business reason to touch it is risk containment: if anything we still run depends on it, we should know, document it, and schedule its removal. Treat it as a line item on a technical-debt register, not a component of a roadmap.

For engineering: Do not add this to new work. If you encounter it in an existing build, pin it exactly, capture the resolved tag in your lockfile and SBOM, note the GPL-2.0 and the age of the bundled libraries, and plan a replacement path — either vendoring the individual libraries through your own asset pipeline or moving to the current Ibexa tooling. Budget the effort as migration work, not maintenance work; there is no upstream to send a patch to.

One-line recommendation: Document, pin, and plan the exit. The package is a historical record of a dependency decision, and its most useful property is that it makes an old decision visible.