Platform Ui Assets Bundle Laravel Package

Product Decisions This Supports

• Feature scope for legacy admin surfaces. This bundle is the frozen manifest of frontend dependencies behind the eZ Platform (now Ibexa) admin UI — AlloyEditor, CKEditor plugins, ez-js-rest-client, handlebars helpers, and related Bower-era libraries. If a Laravel/PHP product still carries an eZ-era admin console, this is the concrete inventory you need before scoping any replacement, extraction, or freeze.
• Build vs. buy vs. vendor. Consuming a pinned tag is a "reuse" decision: you inherit a deterministic, self-contained dependency set at the cost of zero upstream maintenance. Forking a tag is the "build" path and should be reserved for a specific frontend patch that cannot be sourced from a maintained npm package.
• Keep-vs-replace roadmap calls. The tag-only asset model (master carries meta files; real content lives in tags, built by prepare_release.sh -v X.Y, with -b for 4.0+ branches) quantifies what "keeping it alive" costs — a deprecated Bower toolchain, shell-script releases, and no patch stream.
• Migration and containerization programs. For a Laravel product, this is an input to a "do we extract static assets into Vite/Mix or drop them entirely?" decision, and to any offline/CDN build that must reproduce an environment bit-for-bit.
• Risk reporting for quarterly reviews. With 0 dependents, 2 stars, last release 2017-10-31, and a formal archive, it is a clean line item for a legacy-surface-area slide — easy to quantify, easy to justify retiring.
• Documentation of historical state. When a customer escalates a build that cannot be reproduced, tagged releases here are the audit trail that lets you answer "what exactly did we ship in v3.3.0?"

When to Consider This Package

Consider it — narrowly — when:

• You are maintaining or containerizing a legacy eZ Platform installation and must reproduce its admin UI dependency set exactly.
• You need an authoritative inventory of what the current UI pulls in before committing to a migration estimate.
• You want a reusable pattern for shipping frontend assets as immutable, tagged artifacts separate from the application repo — the branch/tag split is a legitimate technique for teams without a modern registry.
• You must build without network access to Bower or external registries and are willing to vendor a specific tag.

Look elsewhere — decisively — when:

• The package is archived and unmaintained. No security patches, no dependency bumps, no PHP/Node compatibility guarantees. Do not add it to new Laravel projects.
• You would need to composer require it in Laravel. It provides no service provider, config, middleware, Blade integration, or routes. It is not a Laravel package and offers nothing a Laravel asset pipeline cannot express natively.
• You are standardizing on Bower. Bower is deprecated; new work belongs in npm/pnpm with lockfiles behind Vite. Building on this model is a dead end.
• You need support, community, or provenance tooling. Two stars and zero dependents mean no community signal; a meta-repo whose content lives only in tags defeats most SBOM and CVE scanners.
• Your target is current Ibexa. Modern versions ship their own frontend toolchain; pulling this in would be an architectural regression.

How to Pitch It (Stakeholders)

For executives: This is a small, archived bundle that stores the frontend assets for the older eZ Platform admin interface. It is not a strategic asset and not something to invest in — but it is a useful measuring stick. Because asset versions are frozen in release tags, it gives us a precise, auditable record of what our legacy UI is built on, which is exactly the evidence needed to price a migration. Recommendation: do not adopt; treat as documentation of legacy state, and fund the move to a maintained frontend toolchain.

For engineering and Laravel teams: Treat PlatformUIAssetsBundle as a read-only artifact registry, never a runtime dependency. Rules of engagement: (1) confirm it is in the tree via composer why before doing anything — it typically arrives transitively through ezsystems/platform-ui-bundle, not by direct install; (2) consume only a pinned tag, never master, which intentionally contains no assets; (3) do not patch in place — vendor or fork the tag if a frontend fix is unavoidable; (4) assume any CVE in the pinned Bower dependency tree is ours to absorb; (5) if assets are genuinely required in a Laravel product, extract only the minimal static files, record the source tag and license, and integrate them through the existing Vite/Mix pipeline with checksums rather than resolving them at install time. The longer-term ask is to replace this model with a lockfiled npm build so UI dependencies become scannable and patchable — this bundle is what we are migrating away from.