- Does ezsystems/platform-ui-assets-bundle work with Laravel?
- No. It is not a Laravel package: it ships no service provider, no config file, no routes, no middleware, and no Blade or asset pipeline integration. It is a versioned artifact store for eZ Platform UI frontend dependencies, originally consumed through Bower. Putting it in a Laravel composer.json gains you nothing at runtime and creates a misleading dependency line.
- Why does the master branch contain almost nothing?
- By design, master holds only meta files such as bower.json and the prepare_release.sh script. The actual frontend dependencies are committed exclusively in git tags, generated by the release script. That means a normal Composer or Git checkout of the default branch gives you no usable assets at all.
- How do I install it with Composer?
- You generally should not. There is no meaningful version constraint story for a Laravel application, and the package provides no PHP code to autoload. If you need the assets, treat it as a one-time extraction: pick a specific tag, pull only the static files you require, and record the tag hash, licence, and upstream URL. Never add it as a runtime dependency.
- Is the package still maintained?
- No. The repository is archived, has roughly two stars and zero dependents, and its last release was 2017-10-31. There is no release cadence, no security patching, and no compatibility guarantees against current PHP, Node, or browsers. All maintenance obligations transfer to your team the moment you vendor anything from it.
- What assets does it actually contain?
- The tags bundle the external frontend libraries the eZ Platform UI needs, such as AlloyEditor, CKEditor plugins, YUI3, ez-js-rest-client, and Handlebars helpers, resolved via Bower. These are static frontend files, not PHP classes. You must inventory which of them your product genuinely requires before considering reuse.
- Can I use these assets with Vite or Laravel Mix?
- Only by manually copying files, not by installing the package. The bundle assumes a deprecated Bower workflow, while a modern Laravel project expects npm or pnpm with a lockfile feeding Vite or Mix. Extracted files can be placed in your own asset directory so they flow through your existing build, but transitive frontend dependencies will need manual verification.
- Are there maintained alternatives?
- In most cases yes. The libraries this bundle pins, including AlloyEditor, CKEditor, and Handlebars, have maintained npm equivalents that are easier to audit and lock. Prefer an npm package wherever one covers the same dependency and drop the extracted file entirely. Only vendor a residual file when no maintained equivalent exists, and log it as technical debt with a replacement target date.
- What licensing and provenance issues should I check?
- Tag-only assets defeat most automated SBOM and CVE scanners, so provenance and licensing must be established by hand. Confirm the licences attached to the exact pinned tag and verify compatibility with your product before reuse. Record the tag hash, upstream URL, and licence text in a provenance note alongside the vendored files.
- What is the security risk of using it?
- High and largely non-remediable. Archived status means no security patches, no dependency bumps, and no browser compatibility fixes. The realistic danger is not an immediate breakage but silently carrying stale, unpatched frontend libraries into production. Treat any vendored file as your own code and schedule regular manual review.
- When would adopting this bundle make sense?
- Only if a product requirement genuinely depends on eZ Platform UI behaviour and no maintained alternative exists. Even then, scope it as a spike: inventory the minimum assets, complete licence and security review, vendor the residual files with checksums, and confirm the build is reproducible from a clean clone. For a standard Laravel application, the correct answer is to skip it entirely.