Platform Ui Assets Bundle Laravel Package

Getting Started

This is not a Laravel package. It is a tagged asset vendor for the eZ Platform admin UI: master contains only meta files (bower.json, prepare_release.sh, README), and the actual JS/CSS dependency sets exist only inside version tags. There is no service provider, no config, no routes, no Blade, no artisan command. Day-to-day, you either (a) consume a pinned tag's static files, or (b) never touch it at all.

Minimal steps for a developer who has confirmed they need it:

1. Confirm it is actually in play. Do not add this to a Laravel app speculatively.

   composer why ezsystems/platform-ui-assets-bundle
   composer show ezsystems/platform-ui-assets-bundle --all
   

   If it does not appear as a transitive dependency of ezsystems/platform-ui-bundle, stop here.

2. Pick the exact tag. Reproduce a historical environment by tag, never by branch:

   git ls-remote --tags https://github.com/ezsystems/PlatformUIAssetsBundle.git
   git clone --branch v4.0.0 --depth 1 https://github.com/ezsystems/PlatformUIAssetsBundle.git vendor-ez-assets
   

3. Read the manifest inside that tag. bower.json lists the pinned frontend packages and versions — this is your source of truth and the reason the tag exists.

4. First use case: extract, don't install. Copy only the static files you need into your own asset tree (e.g. resources/vendor/ez-platform-ui/) and record the source tag in a VENDORED.md next to them:

   resources/vendor/ez-platform-ui/SOURCE.md
   → repo: ezsystems/PlatformUIAssetsBundle
   → tag:  v4.0.0
   → extracted: <date>
   → files: <list>
   

5. Wire it into your existing pipeline (Vite or Mix). Do not try to make bower install part of your build.

The whole onboarding is under an hour if you already know which assets you need. The expensive part is discovering that, and that work happens in PlatformUIBundle, not here (the README explicitly defers testing to that repo).

Implementation Patterns

Pattern 1 — Vendored static tree (recommended). Clone the tag, copy relevant files into resources/vendor/, commit them with a SOURCE.md. Vite/Mix then treats them as ordinary source files. Deterministic, no network at build, no Bower. This is the only pattern that survives Bower's deprecation.

Pattern 2 — Build-time fetch, pinned and checksummed. If you refuse to commit assets, fetch the tag archive in CI and verify a hash before unpacking:

assets:
	curl -fsSL -o /tmp/ez-assets.tar.gz \
	  https://github.com/ezsystems/PlatformUIAssetsBundle/archive/refs/tags/v4.0.0.tar.gz
	echo "<sha256>  /tmp/ez-assets.tar.gz" | sha256sum -c -
	tar -xzf /tmp/ez-assets.tar.gz -C resources/vendor/ --strip-components=1

Add resources/vendor/ez-platform-ui/ to .gitignore. Keep the hash in version control so the build is reproducible.

Pattern 3 — Inventory / audit workflow. When scoping a migration away from the legacy admin UI, diff tags to see what actually changed and why:

git diff v3.3.0 v4.0.0 -- bower.json

Release notes here are terse (EZP-27650: + button not visible in RichText), so bower.json diffs are often the only reliable signal of what dependency caused a UI change. This is the bundle's real day-to-day value.

Pattern 4 — Side-by-side during migration. Run the legacy admin UI assets and your new Laravel admin UI in separate bundles during transition, and pin the legacy set in a subdirectory with a clear legacy/ prefix. Do not attempt to merge the two dependency trees — the Bower-era versions will conflict with modern npm packages.

Integration tips.

• Expose vendored files to Vite via a static copy step rather than importing them from JS, so hashed filenames don't break any legacy URL expectations.
• If a consuming app expects assets at a specific web path, publish them with php artisan vendor:publish-style copy into public/ behind a stable path like /legacy-admin/.
• Keep the tag reference in a single constant/config (config/legacy_ui.php → 'assets_tag' => 'v4.0.0') so upgrades are one-line changes plus a re-vendor.
• For local experiments with newer Bower deps, the README's bower install path exists but is dev-only and not something to put in CI.

Gotchas and Tips

• master has no assets. Cloning or requiring the default branch gives you a README and a shell script. This is the single most common first-day mistake. Always specify --branch <tag>.
• Do not composer require this into a Laravel app. It has zero PHP surface area; adding it pollutes composer.json with an archived, 2-star package and gains nothing. Extract files instead.
• bower install is unreliable. Bower's public registry and many git remotes used in these old manifests are increasingly flaky or gone. If you must run it, expect to override URLs and pin git refs manually; don't make it a required build step.
• No SBOM / CVE coverage. Assets live only in tags, so scanners that read the default branch see an empty package. You must document provenance yourself (which is why SOURCE.md above is not optional).
• No upstream fixes, ever. The repo is archived and last released 2017-10-31. Any vulnerability in the bundled AlloyEditor / CKEditor / YUI / ez-js-rest-client versions is yours. Treat "vendor and patch locally" as the default, not the exception.
• prepare_release.sh is for maintainers, not consumers. -v X.Y sets the version, -b B selects the branch (from 4.0 onward). You will never run this unless you are cutting a fork.
• Debugging asset drift. When a legacy admin screen renders differently than expected, git diff <tagA> <tagB> -- bower.json localises it faster than reading release notes. Version bumps in ez-js-rest-client, AlloyEditor, or the CKEditor plugin set are the usual suspects.
• License review is on you. Each tag embeds third-party libraries under their own licenses. Because there is no package-level license file enumerating them, audit the tag contents before shipping.
• Extension points: effectively none. There is no plugin API, no config merge, no event hook. Customisation means forking the tag or patching vendored files — budget for that when planning any UI tweak.
• Symfony version noise. Release notes mention Allow Symfony 3 (v3.0.1) — a reminder this is dated to a specific PHP/Symfony era. If you're on modern Laravel/PHP, cross-check Node/browser compatibility of the pinned JS before relying on it.
• Prefer maintained replacements. Where a bundled library has a current npm equivalent (React, CKEditor 5, etc.), swap it in rather than vendoring the 2017 build. Reserve vendoring for genuinely irreplaceable legacy behaviour.