Zeus Laravel Package

Getting Started

Clone it, don't require it. lara-zeus/zeus is a standalone application skeleton — a starter kit that pre-wires the Zeus family (core, admin panel, forms, tables, and the Bolt CMS/blog module) on Laravel + Livewire + Tailwind. The value is the pre-wiring, so the install path is: copy/clone the repo into a working directory, composer install, npm install, copy .env.example → .env, php artisan key:generate, point at a database, php artisan migrate --seed, then create/log in a user and land in the panel. Budget an afternoon, not a sprint.

Three files to read before you write anything:

1. composer.json — your actual contract. Confirm the Laravel constraint (v4.0.0 is a Laravel 13.x shift), minimum PHP, Livewire major, whether Filament is present and which major, and the pinned Zeus package versions. Write this matrix down; every upgrade decision hangs off it.
2. The panel provider (app/Providers/*PanelProvider.php or equivalent) — where the panel path, branding, navigation groups, pages, and resources are registered. Nearly everything you add day-to-day gets wired here, so this is the file you'll open most.
3. .env + config/ — panel path, auth guard, and any Bolt/content toggles. Settle these before you build screens so you're not building in the wrong place.

First use case: one real screen, end to end. Pick a boring internal entity — Client is the classic — and take it all the way: migration → model → table definition → create/edit form → navigation registration → asset build → verify in the browser. Time-box to a day. That single loop exercises everything the kit claims to save you and reveals in hours whether the conventions fit your team. Kill criteria: the asset build fights your pipeline, or the form/table API makes you fight the framework instead of using it.

If you don't need a blog, strip Bolt on day one — dependency, migrations, and its nav entries. Carrying a dead CMS module through your first major upgrade is pure cost.

Implementation Patterns

Model-first, screen-second — this is the daily loop. Migration + model, then a table class (columns, filters, search/sort, row and bulk actions), then a form schema (fields, validation, relation handling), then register the page in the panel provider. Keep table and form in separate classes so editing one never touches the other. This is the shape the kit is designed for; deviating from it is where the friction starts.

Keep domain logic out of the UI layer. Zeus is excellent at view plumbing and weak as a domain layer. Put business rules in models/actions/services so a table cell calls $record->recalculateTotal() rather than inlining arithmetic. This is also your exit ramp: the output stays standard Blade/Livewire, so any screen can be reimplemented by hand or in Filament without rewriting domain code. Enforce this in review — it's the single highest-leverage habit here.

Publish-then-override, and keep the override list short. Need a view change? Publish the vendor view, edit the published copy, never the vendor file. Then maintain an OVERRIDES.md listing every published file you've modified with a one-line reason. On the next major that file is your migration checklist — and because this package's cadence tracks Laravel majors, you will be doing that upgrade.

Register navigation and pages centrally. Add pages/resources in the panel provider next to the built-ins rather than inventing a parallel menu. One file stays the source of truth for "what exists in the admin," and grouping/ordering stays consistent with upstream decisions.

Seed real-shaped demo data. A DemoSeeder with 20–50 realistic rows per entity is what makes pagination, filtering, empty states, and relation dropdowns actually testable. With three rows every table looks fine; at fifty you find the truncation, the N+1, and the broken filter.

Read Bolt as documentation before you write your first relational screen. Its posts/categories/tags pages are the intended reference implementation for list + form + relation handling — worth reading even if you delete it.

For custom screens, compose rather than fork. Reuse the kit's form and table builders for bespoke pages, and layer your own Blade components beside Zeus ones rather than subclassing its internals. Check php artisan list for the zeus namespace before hand-writing boilerplate — the scaffolding commands are where the time savings actually live.

Brownfield: port patterns, don't install. The kit wants to own layout, assets, and routing. Copying its table/form class structure and panel-provider wiring into an existing app is reasonable; installing the starter kit into a live application is a framework migration wearing a package-install costume.

Gotchas and Tips

• It's a starter kit, not a component library. The 0-dependents figure is partly an artifact (starter kits get cloned, not depended on), but the practical consequence is real: you're adopting conventions and a view layer, so budget time for reading source rather than searching for answers.
• Assume the next major is breaking. v4.0.0's changelog is three PR titles (Laravel 13.x Shift + two Tailwind PRs) with no migration guide and no stated Tailwind major. Semver is the only contract. Before upgrading: freeze a green baseline, screenshot every Zeus-backed screen (index, form, table, modal, empty state, dark mode), then upgrade.
• Tailwind is the highest-risk surface. Two of three v4 PRs are CSS. If that implies Tailwind 3 → 4, config goes CSS-first and utility semantics shift — and anything you've layered on top, or published views you've edited, breaks there. The failure mode is nastier than an error: styles silently missing in the production build while dev looks perfect. Always verify npm run build and serve the compiled output, not the Vite dev server.
• Re-publish, then diff — don't blindly re-publish. Config, views, and assets may need re-publishing after a major. Diff the published copies against the new upstream so you don't overwrite your edits.
• Pin exactly and pre-write the fallback. "lara-zeus/zeus": "4.0.x", not ^4.0. With a single credited maintainer and low adoption, put an explicit fallback in the README now ("hand-roll these screens" / "move to Filament") so the decision is already made if the project stalls.
• Resolve the Filament question on day one. The vendor description says Filament-powered; other summaries describe it as an alternative. Check composer.json and the panel setup before you size anything — it changes both your mental model and your upgrade train (Laravel + Livewire + Filament + Tailwind + Vite is more moving parts than one changelog suggests).
• Don't upgrade blind on a "mostly plumbing" release. Zeus majors drag your host app's Laravel and Tailwind versions with them, so your critical path is your slowest other dependency. Confirm which 3.x patches you're forfeiting.
• Debugging: when a table or form renders wrong, drop to Livewire devtools and inspect the component's data payload before editing Blade. Most "styling" bugs are missing fields in the schema; most "missing style" bugs are a stale or unbuilt asset. Those two checks resolve the majority of issues here.
• Extension points to prefer: panel-provider registration, published views, custom Blade components placed beside Zeus ones, and your own model-level actions. Avoid: patching vendor classes or extending internal form/table base classes — those are the first things to change in a major, and the first thing to break.
• Confine it. Internal, CRUD-shaped, churn-tolerant back-office surfaces only. If a screen becomes production-critical customer-facing UI with no design-system owner and one upstream maintainer, you've drifted past the point where the trade-off was sound.