Hybrid Platform Ui Assets Laravel Package

Getting Started

First, calibrate expectations: this is not a Laravel package. There is no service provider, no config/ file, no facade, and no PHP API surface. It is a Composer-distributed static asset bundle that ships the prebuilt JavaScript/CSS (and Bower-style dependencies) required by the legacy eZ Platform Hybrid Platform UI (the React-based admin console used in eZ Platform 1.x/2.x). You "use" it the same way you would use a vendored font or a precompiled admin theme — by getting the files onto your web root and referencing them.

Minimal steps:

1. Confirm you actually need it. If you are not maintaining an eZ Platform install that depends on the Hybrid Platform UI, stop here — pulling it into a Laravel app gains you nothing.
2. Install a tagged version, not dev-master. The README is explicit: the master branch contains only meta files. The payload lives in tags. Inspect the tag list on the repo/Composer and pin accordingly:

   composer require ezsystems/hybrid-platform-ui-assets:<tag>
   

   Use a concrete version constraint (~1.x.y style) rather than dev-master, or you will install an empty directory.
3. Look first at three places: the repository's tag list (what actually exists), the package's own composer.json (for any extra install hints), and — most important — the consuming eZ Platform project's composer.json/assets:install setup, which is what historically published these files into web/.
4. First use case: expose the asset directory to the browser. In a Symfony/eZ context that is php bin/console assets:install --symlink. In a Laravel context, copy the tagged payload once into your public root (see patterns below) and reference it from a layout.

Look at vendor/ezsystems/hybrid-platform-ui-assets/ immediately after install — if the directory is thin or empty, you installed the master branch and need to redo step 2.

Implementation Patterns

Treat it as a passive asset vendor, not a build dependency. The entire point of the package is that you do not need Node/npm/Bower at install time — the artifacts are already compiled and committed in the tag. Do not try to run a frontend build against it.

Symfony/eZ Platform pattern (the intended one). Let the framework's asset installer symlink the package's public directory under the web root, then reference those paths from the admin layout. This is the only "supported" path and the one the Hybrid Platform UI expects. Keep it in composer.json as a normal dependency and let assets:install do the work on deploy.

Laravel pattern (adaptation). Since there is no Laravel integration, wrap the publish step yourself:

• Add a Composer post-install-cmd / post-update-cmd script, or a tiny artisan command, that copies vendor/ezsystems/hybrid-platform-ui-assets/<tag>/** into public/vendor/hybrid-platform-ui/.
• Reference the copied files from your Blade layout with asset('vendor/hybrid-platform-ui/...').
• Keep the copy step idempotent and cache-busted (hash the tag into the destination folder) so redeploys don't serve stale bundles.

Version-lock the trio. These assets are only meaningful alongside a matching Hybrid Platform UI version. Pin the assets package, the UI package, and the eZ kernel together in composer.lock, and upgrade them as a set — not independently.

Container/CI pattern. Bake the tagged assets into the image during build (composer install --no-dev at build time) so runtime containers never touch the network. Because the payload is static, this is safe and reproducible.

Customization pattern. Never edit files under vendor/. If you need to change behavior, override at the consuming application layer (your own CSS/JS loaded after these, or a fork of the UI package). The package has no extension points of its own.

Gotchas and Tips

• dev-master is a trap. The master branch is deliberately meta-only. A composer require ...:dev-master yields a directory with no assets, and the failure mode is a blank or unstyled admin UI rather than an install error. Always pin a tag.
• Archived and abandoned. Last release 2017-07-18, zero stars, zero dependents, repo archived. There will be no fixes for browser-compat issues, CVEs in bundled JS, or PHP/Composer version drift. Treat it as frozen legacy code and budget for eventual replacement.
• GPL-2.0 license. This is copyleft, not MIT. If you redistribute a product containing these assets, you inherit GPL obligations. Flag this for legal review before shipping a commercial admin console.
• Version mismatch symptoms. If the asset version doesn't match the Hybrid Platform UI version, expect JS console errors, missing React components, or a half-rendered admin — the UI assumes exact file names and bundles.
• Debugging checklist: (1) ls the installed tag directory to confirm files exist; (2) confirm the symlink/copy landed where the web server serves it; (3) check the browser Network tab for 404s on bundle paths; (4) verify the layout references match the filenames the UI expects.
• Composer cache masking. A failed or partial tag checkout can persist in Composer's cache. If assets look stale or incomplete after a reinstall, run composer clear-cache and reinstall the pinned tag.
• No extension points. There is nothing to hook into — no events, no config merge, no service overrides. Any customization must live entirely in the consuming application.