Evo Ui Laravel Package

Product Decisions This Supports

• Build vs. buy (really: adopt vs. hand-roll) for admin UI. This package decides whether every manager module owns its own shell, CSS bundle and JS glue, or consumes a shared Livewire + DaisyUI foundation. That is a platform-ownership decision, not a component shopping decision.
• Roadmap sequencing for the manager modernization program. The package documents a migration order — sArticles and dIssues live today, sLang and sSeo are next. That gives you a defensible phasing plan and a definition of "done" per wave.
• Scope-cutting lever for every admin-facing feature. Config-driven tables and forms (filters, sorting, pagination, inline/modal edit, drag reorder, row actions) mean a PM can scope list/detail CRUD to declarative config rather than bespoke Blade. Use it to argue down estimates on CRUD-shaped work and to reserve custom engineering for genuinely novel screens.
• Legacy deprecation decisions. Every adopted module is a step toward removing jQuery, Bootstrap, main.js, tabpane.js, Roboto and CDN assets from the manager. That is a quantifiable maintenance-cost reduction you can put on a roadmap as a line item with an end date.
• Platform constraint decisions with real blast radius. Livewire 4 and PHP 8.4 (raised in v1.1.0) and Evolution CMS 3.5.7+ become portfolio-wide upgrade prerequisites. This package forces the "when do we take the PHP 8.4 / Livewire 4 jump" conversation — better to own it than discover it mid-sprint.
• Invest in shared primitives vs. one-off components. The primitive coverage matrix, design tokens, component catalogue and localized docs are evidence for funding a component library instead of re-solving the same table/modal/editor in each module.
• UX consistency as a product outcome. Theme sync across evolight, evolightness, evodark, evodarkness plus shared interaction contracts for save feedback, dirty-state protection and tab refresh turn "each module looks slightly different" into a standard you can hold teams to.
• Representative use cases: manager modules with list/detail CRUD, settings and configuration screens, redirects/activity tables, issue and kanban workspaces, rich-text and image fields, and any screen that needs session-persistent filters and views.

When to Consider This Package

• You are on Evolution CMS 3.5.7+ and building or rewriting a manager module. That is the only population for which this is even a candidate.
• You have more than one module to build or port. The value is amortized across modules; the setup cost (provider registration, layout, asset publishing, preset contracts) rarely pays back on a single screen.
• You are prepared to take PHP 8.4 and Livewire 4. These are hard floors, not aspirations.
• You accept the iframe document model. x-evo::layout owns the manager document; modules stop owning their own shell. Teams that insist on full control of the outer page will fight this.
• You want config over handcrafted views. The table/form contracts are the point. If your screens are declarative-friendly, adoption is cheap.
• You can commit to a clean cut per screen. The package's own release gate says no new screen should mix evo-ui with legacy manager UI bundles. If you can only half-migrate a screen, don't start it.
• Look elsewhere if any of these hold: you are not on Evolution CMS or are on an older release; you need public-facing front-end UI rather than manager screens; your screens are highly bespoke (complex editors, non-CRUD dashboards) where config-driven tables and forms become a straitjacket; you require a vendor-backed support contract or a large ecosystem — 2 stars and 0 external dependents means this is a single-maintainer, in-house-shaped project, and you should plan to treat it as owned strategic infrastructure with an internal fork/support assumption rather than a third-party dependency you can lean on.
• Soft flag on non-symlink hosting. vendor:publish falls back to copying, which reintroduces stale-asset risk after upgrades. Workable, but it needs to be a known operational cost, not a surprise.

How to Pitch It (Stakeholders)

To executives: this is a platform consolidation bet, not a UI experiment. Today each manager module rebuilds its own admin shell and drags along jQuery, Bootstrap, CDN assets and a bespoke theme layer. Adopting evo-ui replaces that with one shared, tested foundation — config-driven tables and forms, one component catalogue, one theme-sync story across all four manager themes. The return is structural: less duplicated front-end code, fewer per-module regressions, faster delivery of CRUD-shaped screens, and a credible path to deleting the legacy asset stack entirely. The cost is a coordinated migration per module plus a PHP 8.4 / Livewire 4 upgrade we would have to take eventually anyway. The honest risk assessment: this is a small, actively released but thinly adopted codebase, so we should own it, pin it, and keep an internal fallback plan — but the alternative is continuing to pay the legacy tax on every module we touch.

To engineering: Livewire 4 + DaisyUI foundation for manager screens, rendered inside the manager iframe with locally published (symlinked) assets and no legacy bundle. We get a shell (x-evo::layout), a Livewire bridge for manager routes/sessions/CSRF/assets, config-driven module tables and forms with session state persistence, and shared Blade primitives. The v1.1.0 component registry (EvoUI::registerComponent(), EvoUI\Components\Component) gives us a boundary that keeps consumer packages off direct Livewire imports — worth using from day one so a future Livewire bump stays contained. Quality bar is documented rather than implied: 56 tests / 1500 assertions, PHPStan level 5 clean plus a level 8 strict probe, a release gate spanning four modules, and a documented consumer-drift check. Migration path per module: add the dependency, render an evo-ui-owned manager document, publish assets, declare table/form presets, then delete the legacy views and assets in the same change. Measure us on time-to-new-manager-screen, count of remaining legacy asset dependencies per module, and post-release regression rate on migrated screens.