Hybrid Platform Ui Assets Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package. It is a Composer-distributed asset metapackage for eZ Systems' Hybrid Platform UI (Symfony-based), whose README states the master branch contains only meta files while real dependencies exist solely in tags. There is no service provider, config, facade, or publishable-asset convention — nothing Laravel's container or asset pipeline can consume natively. In a Laravel application its only conceivable role is as a vendor directory of static JS/CSS that we would copy by hand.

Integration feasibility. Low through Composer, moderate through manual vendoring. Any composer require must pin an exact tag; dev-master resolves to a package with no payload, which fails silently rather than loudly. Since the repository is archived, tags are frozen — good for reproducibility, bad for everything else.

Technical risk.

• License: GPL-2.0 is copyleft. Redistributing or linking these assets into a proprietary Laravel product requires legal review before any code is written; this alone can kill adoption.
• Abandonment: last release 2017-07-18. No security patching, no PHP 8 compatibility statement, no maintenance.
• Compatibility: 2017-era constraints (PHP 5.6/7.x, Symfony 2/3 generation) will likely conflict with Composer 2 strictness and modern Laravel (PHP 8.2+) without testing we would have to fund ourselves.
• Supply chain: 0 stars, 0 dependents, no community scrutiny of tag contents. Asset blobs in tags are effectively unverified provenance.
• Fragility: tag-only distribution means the package's correctness depends on the consumer pinning exactly; naive version constraints produce an empty install with no error.

Key questions. Is there an existing eZ/Ibexa Hybrid Platform UI deployment we must stay visually or functionally compatible with? Which specific assets are actually required, and do maintained npm equivalents already exist? Has legal signed off on GPL-2.0 asset redistribution in our distribution model? Is there a funded successor path (Ibexa DXP packages, or an npm/Vite replacement)? Who owns the legacy UI if we choose to vendor?

Integration Approach

Stack fit. Poor for a greenfield Laravel app. Laravel's frontend story is npm plus Vite/Mix at build time; Composer is for PHP runtime code. Introducing this package creates a split-brain asset pipeline with two dependency managers, two lockfiles, and two upgrade cadences — for zero functional gain.

Migration path. Do not adopt as a runtime dependency. If parity with a legacy eZ UI genuinely requires these assets, perform a one-time extraction from a pinned tag, vendor the files into resources/ or a private artifact repository with recorded checksums and provenance, and then replace them incrementally with maintained npm equivalents before deleting the vendored copy.

Compatibility. Verify PHP and Composer constraints against the target Laravel version before any install. Assume no compatibility with Laravel 10+ / PHP 8.2+ until proven; treat the package as unsupported and plan for it to be the blocker rather than the solution.

Sequencing.

1. Legal/license review of GPL-2.0 obligations in our distribution model.
2. Asset inventory: enumerate exactly which files the legacy UI consumes and who consumes them.
3. One-time tagged extraction into a private mirror, pinned by hash, with a documented source URL and date.
4. Build a parity test of the replacement assets inside the Laravel Vite pipeline.
5. Cut over, delete the vendored copy, and record a sunset date in the dependency register.

Operational Impact

Maintenance. Effectively zero upstream maintenance — archived since 2017, no releases in eight years. Any vendored snapshot becomes internal code we own indefinitely; budget manual review cycles, not upgrade cycles.

Support. No vendor, no issue triage, no CVE process. Internal on-call absorbs all breakage. Register it explicitly as "unmaintained, accepted risk" so it surfaces in audits and incident reviews rather than being discovered during one.

Scaling. The assets are static, so CDN and build-time delivery scale trivially. The scaling risk is organizational: every additional consumer of the vendored snapshot widens the blast radius of a later license or provenance finding.

Failure modes. Empty package from a master-branch install; 404s after asset publish or cache clear; upstream tag or repository deletion (archived repos can still be removed); license contamination flagged during audit, M&A diligence, or a customer's procurement review; build breakage when Composer 2 or a PHP version bump collides with 2017-era constraints.

Ramp-up. Low technical ramp-up — it is static files and a handful of tags, learnable in an afternoon. High governance ramp-up: legal, security, and architecture sign-off dominate the timeline. Realistically days of engineering effort against weeks of approval, which is the correct ratio to surface when this gets proposed as a "quick dependency add."