Admin Ui Assets Laravel Package

Product Decisions This Supports

• Admin experience / back-office branding decisions. This package is the front-end asset bundle (CSS/JS) for the Ibexa DXP Back Office. Any decision about rebranding, theming, or restyling the admin UI lands here: you either consume these assets as-is, or you fork/override them. That's a scoping decision, not a feature decision, and it should be estimated as UI/design work rather than backend work.
• Upgrade and version-pinning policy. The README ties branches to platform lines (4.x for eZ Platform 2.5.x LTS, tags cut via bin/prepare_release.sh). That makes this a release-train artifact: your decision is which Ibexa DXP version you standardize on, and this package follows automatically. It informs how you sequence platform upgrades and how much front-end regression testing to budget per upgrade.
• Build-vs-buy for the admin surface. Don't rebuild. The realistic build-vs-buy question is "custom admin theme vs. stock Back Office," and the answer is almost always "theme the stock one." This package is the raw material for that, not a candidate for replacement.
• Redistribution and licensing decisions. Dual-licensed under the Ibexa Business Use License (requires a paid DXP subscription) and GPLv2. If your product embeds or reskins the Back Office and you distribute it, GPLv2 copyleft obligations become a product-legal question, not an engineering one. This is the single highest-leverage decision this package surfaces.
• CI/CD and artifact policy. The package ships built assets produced by an npm install + npm run prepare-release flow. If you maintain a fork, you inherit that pipeline — a decision about whether you own a Node toolchain in CI at all.
• Roadmap input (limited). With 4 stars and 0 dependents, this gives you no external signal about where the admin UI is heading. Roadmap intelligence must come from Ibexa's own release notes and your account team, not from this repo.

When to Consider This Package

Consider it when:

• You are running (or evaluating) Ibexa DXP — this package is not usable standalone. It is a component of the platform, not a library you add to an arbitrary app.
• You need to theme, rebrand, or patch the Back Office UI, or you are diagnosing a Back Office front-end issue and need to trace it to the shipped assets.
• You are pinned to a specific platform line (e.g., 2.5.x LTS → 4.x branch) and need to confirm which asset version corresponds to your platform version.
• You have commercial license coverage or GPLv2 compliance sign-off already in place.
• You are building a reproducible build or fork and need the npm release tooling.

Look elsewhere when:

• You are on Laravel or a general PHP stack. Nothing here applies. Despite the "PHP package" framing, this is an Ibexa/Symfony-ecosystem asset bundle with no Laravel integration, no service provider, no reusable components.
• You want a general-purpose admin UI asset library or design system. Use a maintained design system instead; this has no independent documentation, no API surface, and no community.
• You need community support or third-party guarantees. 4 stars, 0 dependents, no external consumers — assume zero community safety net. Your only support channel is the vendor contract.
• Licensing is unresolved. NOASSERTION on the license field plus a dual commercial/GPLv2 text means legal review is a hard gate. If you cannot clear it, stop.
• You need a stable, semantically versioned public API. Release dates and branch-to-platform mapping are the only contract, and the tooling is shell-script based.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is not a product we buy or build — it is a small front-end asset bundle that ships inside Ibexa DXP to render the admin interface. Its practical significance is twofold: it determines how much design and QA effort a Back Office rebrand or a platform upgrade will cost, and it carries a dual commercial/GPLv2 license that needs legal sign-off before we redistribute or heavily customize the admin UI. There is no independent community around it (4 stars, no downstream dependents), so our support posture is entirely our Ibexa subscription. Recommendation: treat it as a versioned dependency of the platform, not a build target — no separate investment case.

For engineering (summary): Consume as a pinned transitive dependency; do not fork unless we must patch the Back Office UI, and if we do, we own an npm install + prepare_release.sh release pipeline. Branch 4.x maps to eZ Platform 2.5.x LTS — verify the version mapping against the installed DXP release before every upgrade, and add Back Office visual regression checks to the upgrade checklist. Expected effort is low and ongoing (version bumps, occasional theme overrides), not a project. Flag any customization of shipped assets to legal early, because that is where GPLv2 obligations attach.