Laravel Schema Viewer Laravel Package

Getting Started

• Install as a dev dependency: composer require laranex/laravel-schema-viewer --dev. This is a developer-facing inspection tool; it has no business shipping to production.
• Publish the config: php artisan vendor:publish --tag="schema-viewer-config" (fall back to a plain php artisan vendor:publish and pick the package provider if the tag name has moved).
• Generate the snapshot: php artisan schema:generate. This writes a JSON representation of your database to a configurable path (database/schema.json by default). It connects to the database at generation time only — the viewer itself reads the file.
• Open the UI at the configured route (defaults to /schema-viewer) and browse tables, columns, indexes, and foreign keys.
• First use case: point it at an inherited or legacy database. Run php artisan migrate (or connect to a restored dump), run schema:generate, and read the table list and relationships before you write a single query. It is the fastest way to answer "what does this orders table actually look like, and what references it?"

Where to look first: config/schema-viewer.php for enabled, path, middleware, and the snapshot file location; then the generated schema.json directly — it is plain, greppable JSON and often faster to query than the UI.

Implementation Patterns

• Chain it into your local bootstrap. Add schema:generate to a composer script or custom app:setup command after migrate:fresh --seed so the snapshot is never stale on a fresh clone.
• Commit the snapshot and review it in PRs. This is the highest-leverage pattern: check database/schema.json into git and regenerate it in the same PR as your migration. Reviewers diff the JSON and see added columns, changed nullability, dropped indexes, and new foreign keys without mentally parsing every migration file. It catches the classic bug where foreignId('user_id')->constrained() silently didn't create the constraint you assumed.
• Drift detection in CI. After running migrations against a throwaway database:

  php artisan schema:generate
  git diff --exit-code database/schema.json
  

  A non-empty diff means someone changed the schema without committing the regenerated snapshot — or a migration didn't apply as intended on that driver.
• Lock it down with middleware, not hope. 'middleware' => ['web', 'auth'] (or a specific gate) plus 'enabled' => env('SCHEMA_VIEWER_ENABLED', app()->isLocal()). Do both; the env switch protects you if middleware config drifts.
• Onboarding and pairing. Use the relationship/diagram view to explain a domain to a new team member, and share deep links to specific tables in Slack rather than screenshots.
• Pair with Artisan's built-ins. php artisan db:show and db:table <name> are quicker for a single lookup in the terminal; the viewer wins for the relational, whole-schema picture. Use each for what it's good at.
• Multi-connection apps. The snapshot reflects whichever connection was active during generation. If you support more than one, generate deliberately against the connection you care about rather than assuming the default is right.
• External consumers. Because the output is a stable-ish JSON file, it doubles as documentation for analytics teams or downstream services that need to know the shape of your data.

Gotchas and Tips

• It is a static snapshot, not a live view. If the UI looks wrong, you almost certainly forgot to re-run schema:generate after your last migration. Make that reflex.
• There is no auth out of the box. Default configuration exposes your full schema to anyone who hits the route. Set SCHEMA_VIEWER_ENABLED=false in production envs, keep the package in require-dev, and add auth middleware for shared/staging environments.
• Config and route caching bite. Changing path or middleware has no effect on a cached deploy until you run php artisan config:clear and route:clear.
• Re-publish config on upgrades. Config keys and defaults have shifted across versions. Publish to a temp location and diff rather than assuming your old file still matches — then clear caches.
• Driver differences distort the picture. SQLite reports foreign keys, index names, and enum/json types differently from MySQL or Postgres. Generating locally on SQLite can misrepresent a MySQL production schema — generate against the same engine you deploy on when accuracy matters.
• Views, materialized views, and generated columns may be missing or rendered oddly. Don't treat the viewer as authoritative for those; verify against the database.
• Big schemas get unwieldy. Past ~100 tables the listing is hard to navigate; fall back to db:table <name> or grep the JSON directly.
• Commit churn. Column ordering and formatting can vary by driver/PHP version. Regenerate in CI on the same stack as developers to avoid meaningless diffs in schema.json.
• Extension point: the JSON file is the real API. It's straightforward to build your own linting on top of it — e.g. assert every *_id column has a matching foreign key, or feed it into a Mermaid ERD generator for docs.
• On v1.4.2 specifically: the patch release carries no changelog entries, so there are no migration steps, breaking changes, or new config expectations flagged. A safe bump — but if you're coming from anything below 1.4, re-publish and diff the config file as above.