- Is ezsystems/hybrid-platform-ui-assets a Laravel package?
- No. It is a Composer-distributed asset metapackage for eZ Systems' Hybrid Platform UI, which is Symfony-based. It has no service provider, config, facade, or publishable-asset convention, so Laravel's container and asset pipeline cannot consume it natively. In a Laravel app its only possible role is a vendor directory of static JS and CSS that you copy by hand.
- Why does composer require ezsystems/hybrid-platform-ui-assets install an empty package?
- The README states that the master branch contains only meta files and that the actual dependencies are available only in tags. If you use dev-master or a loose constraint, Composer can resolve to a package with no asset payload and fail silently rather than loudly. You must pin an exact tagged release to retrieve the frontend dependencies.
- Does ezsystems/hybrid-platform-ui-assets support Laravel 10 or PHP 8.2?
- There is no compatibility statement for modern Laravel or PHP 8.2. Its 2017-era constraints target PHP 5.6/7.x and Symfony 2/3 generation tooling, which will likely conflict with Composer 2 strictness and current Laravel versions. Treat the package as unsupported until you fund and complete your own compatibility testing.
- What license does ezsystems/hybrid-platform-ui-assets use, and can I use it in a commercial Laravel app?
- The package is GPL-2.0, which is a copyleft license. Redistributing or linking these assets into a proprietary Laravel product requires legal review before any code is written. This licensing issue alone can block adoption, so do not assume it is safe for commercial distribution.
- How do I install ezsystems/hybrid-platform-ui-assets in a Laravel project?
- Adopting it as a runtime dependency is not recommended for a Laravel application. If legacy parity genuinely requires the assets, require an exact tag, verify PHP and Composer constraints against your target Laravel version, and then copy the static files into resources or a private artifact repository. A one-time extraction with recorded provenance is safer than leaving Composer to resolve it.
- What are alternatives to ezsystems/hybrid-platform-ui-assets for a Laravel frontend?
- Laravel's frontend story is npm plus Vite or Mix at build time, so maintained npm equivalents are the natural replacement. If you must match a legacy eZ Hybrid Platform UI, enumerate exactly which JS and CSS files are consumed and replace them incrementally. Ibexa DXP packages or a modern npm/Vite asset set are the likely successor paths.
- Is ezsystems/hybrid-platform-ui-assets maintained or secure?
- No. The repository is archived, the last release was 2017-07-18, and there is no security patching, CVE process, or vendor support. It has zero stars and zero dependents, so tag contents have had no community scrutiny. Register it explicitly as unmaintained accepted risk so it surfaces in audits and incident reviews.
- Can I use dev-master for ezsystems/hybrid-platform-ui-assets?
- No, because the master branch contains only meta files and no actual frontend assets. A Composer require must pin an exact tag; naive version constraints can produce an empty install without any error. The tags are frozen because the repository is archived, which helps reproducibility but not maintenance.
- Should I vendor ezsystems/hybrid-platform-ui-assets assets into my Laravel app?
- Only if parity with a legacy eZ UI genuinely requires those exact files. Perform a one-time extraction from a pinned tag, vendor the files into resources or a private mirror with checksums, and document the source URL and date. Then replace them incrementally with maintained npm equivalents and delete the vendored copy. You will own that snapshot indefinitely, so budget manual review cycles.
- How should I test a Laravel app that uses ezsystems/hybrid-platform-ui-assets?
- First verify the package's PHP and Composer constraints against your target Laravel version; assume no compatibility with Laravel 10+ or PHP 8.2+ until proven. Build a parity test of the replacement assets inside the Laravel Vite pipeline and confirm exactly which legacy files are consumed. Plan for the package to be the blocker rather than the solution, and record a sunset date in your dependency register.