hasinhayder/tyro-dashboard
Tyro Dashboard is a Laravel package that provides a ready-made admin dashboard with authentication, role and permission management, user administration, and customizable UI components, helping you build back-office interfaces faster.
Tyro Dashboard is not a Blade component kit — it is an admin panel framework bolted onto a Laravel app. It ships complete authentication, user management, roles/privileges (RBAC), media handling, and config-driven CRUD, all behind its own layout, routes, and middleware. Treat it the way you treat Laravel itself: read the docs, use the extension points, and don't patch the source.
Read these three things before writing code, in this order:
config/tyro-dashboard.php — the whole feature surface (auth, RBAC, media, CRUD, system settings) is toggled and shaped here. This file answers 80% of "can it do X?" questions.php artisan route:list --name=tyro (and any project-specific dashboard prefix) shows you what is already wired, what middleware guards it, and which route names you must not collide with.vendor/hasinhayder/tyro-dashboard/resources/views — this is your reference for layout section names, partial names, and CSS variables. You read them; you do not edit them.If you use an AI coding agent, the package ships agent-facing docs (skills/tyro-dashboard/SKILL.md plus a rules/ index). That is unusually valuable: point your agent at those files first and it will stop trying to edit vendor/ and start publishing sidebars like a human who read the manual.
Minimal install path:
composer require hasinhayder/tyro-dashboardphp artisan list under the tyro namespace) — it wires routes, publishes config/assets, and sets up the dashboard shell.Your first real use case should be the smallest one that proves the loop: add one app-level admin page (a "System Info" or "Environment" panel is the canonical smoke test) plus one CRUD resource. That exercises routing, middleware, layout inheritance, sidebar injection, and the resource layer all at once. Resist replacing your whole admin area on day one.
Classify every task before touching it. The package's own guidance splits work into three buckets, and the bucket dictates your freedom:
If a task lands in bucket two, ask whether a bucket-one move solves it. It almost always does.
Adding an admin page. Register the route inside the existing dashboard group, or with ['auth', 'tyro-dashboard.admin'] if you're building standalone. Name it consistently with the surrounding routes (dashboard.system.environment, not system-info). The controller returns a view that @extends('tyro-dashboard::layouts.admin') and fills the stable section names. Then add the sidebar entry — through the published sidebar partial or the menu injection point, never by editing vendor Blade.
Sidebar changes. Two publish tags matter and they are not interchangeable: tyro-dashboard-sidebar (just the admin and user sidebars) versus tyro-dashboard-essentials (admin bar, sidebars, topbar, plus resources/views/dashboard). Most projects want the narrow one. Active-state detection should use request()->routeIs(...) or the package's DashboardRoute::pattern(...) helper so a single change to the route prefix doesn't break every highlight. Keep labels short; match the icon set already in use.
CRUD resources. Check whether the local project leans on Tyro's resource config, hand-written controllers, or both — then copy the nearest example. Route names, redirect targets, and validation placement must match. Load relationships explicitly; the generic listing screens are exactly where N+1 regressions hide. Admin routes always carry the Tyro authorization layer, no exceptions.
RBAC. Authorization flows through the HasTyroRoles trait and the admin middleware, with caching layered in. Enforce in middleware and keep the trait's helpers available for in-view and in-controller checks. When you test a permission change, log out/in or clear the cache — a stale cache is the #1 "the permission didn't work" false alarm.
Settings and the env editor. Read the existing settings controller before adding a tab. Validate server-side, whitelist every key you write to .env, and never render a secret unmasked. If a setting only takes effect after a config cache rebuild, surface that in the UI (or offer a clear-cache action) — silent no-ops are worse than a scary button.
Blade overrides. Publish to resources/views/vendor/tyro-dashboard/, keep section names stable, reuse the existing CSS variables and component classes before adding styles, and verify mobile wrapping for long paths/values. php artisan view:cache is your Blade syntax check; php -l will not catch a broken directive.
Verification loop, proportional to change: php -l on edited PHP → php artisan route:list --name=<fragment> for new routes → php artisan view:cache for Blade → focused Pest/PHPUnit test when behavior is security- or API-relevant.
Never edit vendor/. Every problem in this package has an app-level solution: published view, config override, route, middleware alias, event listener, or menu hook. Editing vendor means the next composer update silently reverts your work, and you won't notice until production.
Public surface is sticky. Route names, config keys, Blade section names, view-composer variables, publish tags, command names, env keys, and public/protected method signatures are all contracts. A consuming app or a third-party plugin may depend on any of them. Before renaming anything, check whether an additive option (new config flag, new method) gets you there instead.
Config cache bites twice. Overrides in config/tyro-dashboard.php are cached in production; so are env values. Editing .env from the settings UI without config:clear produces a change that appears to work in the editor and does nothing at runtime. Bake cache-clearing into the settings flow or document it loudly.
Don't make the sidebar expensive. It renders on every admin page. Schema checks, remote calls, or unfiltered counts there will quietly degrade the whole panel. Guard anything costly behind a config flag or a cached lookup.
Publish tags are coarse. tyro-dashboard-essentials dumps a lot of files into your repo, and once published they shadow package updates forever. Publish the minimum (tyro-dashboard-sidebar first), and delete a published override the moment you stop diverging from it.
Middleware order matters. Auth, then the Tyro admin middleware, then impersonation handling — the package defines the order for a reason. Splicing your own middleware into that chain without reading rules/middleware.md is how you end up with an impersonating admin who passes a role check they shouldn't.
One pattern per concern. The rules call out "introducing a second pattern for menus, settings, CRUD, or route naming" as an anti-pattern. It is. Two ways to add a sidebar item means every future developer guesses wrong. Match the nearest existing example even if you'd have designed it differently.
The ecosystem is thin. Zero dependents and ~560 stars means you are often the first person to hit a given edge case. Budget time for reading the package source when a behavior isn't documented, and lean on the bundled rules/ files — they cover authorization, impersonation, 2FA reset, audit integrity, upgrade paths, and testing boundaries in more detail than the README will.
Be conservative with destructive commands. Migrations, seeders, queue workers, and broad test suites against a database you didn't create are how assessments turn into incidents. Read rules/agent-testing.md before running them, and prefer a scratch database.
For reviews, lead with risks in this order: authorization leaks, breaking public/plugin contracts, upgrade-path regressions, route/config/view naming drift, missing tests, and performance in shared UI or middleware. If you find nothing, say so plainly — and name the test gap you left behind.
How can I help you explore Laravel packages today?