composer require wyattcast44/laravelschema --dev
php artisan list | grep -i schema # confirm the exact command signature
The package ships a single artisan command that parses your migration files and writes human-readable schema descriptions to disk. In the 2021 release the entry point is php artisan schema:generate, and output lands in a configurable folder (typically database/schema/). Because releases stopped in early 2021, confirm the command name and output path against the installed source rather than trusting the README:
php artisan vendor:publish --provider="Wyattcast44\LaravelSchema\LaravelSchemaServiceProvider"
cat config/laravelschema.php # output path, file extension, excluded tables
php artisan schema:generate -v
ls database/schema/
First use case: run it once on an existing project, commit the generated files, and point new hires (and your own future self) at database/schema/ instead of asking them to reverse-engineer 200 migrations or spin up a database just to answer "what columns does orders have?". That alone justifies the dev dependency.
Documentation snapshot, not runtime code. Keep this as a --dev dependency and treat the output as review artifacts. It belongs next to docs/, not in app/.
Freshness gate in CI. The highest-value pattern for a package like this is drift detection:
# .github/workflows/schema.yml
- run: php artisan schema:generate
- run: git diff --exit-code database/schema/ || (echo "Regenerate schema docs" && exit 1)
This forces every PR that touches a migration to also refresh the readable snapshot, so the two never diverge silently.
Composer script for local hygiene.
"scripts": {
"schema": ["@php artisan schema:generate"],
"post-migration": ["@schema"]
}
PR review aid. In review, diff the generated file alongside the migration. A one-line $table->string('status') in a migration is easy to miss; seeing orders.status — varchar(255) added in context makes column-level changes obvious.
Pair with other generators. Feed the output into model docblocks (barryvdh/laravel-ide-helper) or API docs. If you have a custom attribute-typing convention, the generated file is a cheap source of truth to script against.
Pre-refactor baseline. Before a column-rename or type-change sweep, generate and stash the folder. Afterward, regenerate — the diff is your change audit, independent of what the DB actually did.
Environment discipline. Generate against migrations only, so the output is reproducible on any machine without a live DB. If the package supports per-connection generation, run it per connection rather than relying on the default.
It reads migrations, not the database. Anything applied outside migrations — manual ALTER TABLE, seeders that mutate structure, DB::statement('...') inside a migration — will not appear. If the generated schema disagrees with SHOW CREATE TABLE, the database is right and the file is stale.
Squashed migrations are a real risk. Laravel 8+ php artisan schema:dump collapses migrations into a single .sql file; a migration-file parser may see nothing or only the post-squash migrations. Test explicitly after any squash, and consider whether this package still earns its keep on a squashed repo.
Unmaintained since March 2021. Assume incompatibility with newer Laravel and PHP versions until proven otherwise. Test on your target version before adopting; if it breaks, the fix is usually a one-line namespace or illuminate/support constraint in a fork — pin the fork in repositories rather than waiting for an upstream release.
Complex migration closures are the failure mode. Schema::create with conditional logic, loops over column arrays, if (Schema::hasColumn(...)) guards, or dynamic table names will be mis-parsed or skipped. Skim the generated output for missing tables after the first run; add anything it can't see to excluded/annotated files manually.
File churn. Ordering of keys or tables may not be deterministic across runs, producing noisy diffs. Check whether the command sorts output; if not, diff a couple of runs before wiring it into CI, or the git diff --exit-code gate will fail on unrelated changes.
Exclusion list. Pivot tables, telescope_*, failed_jobs, and framework tables usually add noise. Most such packages expose an ignore/only config — use it rather than deleting generated files by hand (they'll come back).
Debugging. Run with -v for per-file parse output, verify write permissions on the output directory, and check storage/logs/laravel.log for parser exceptions — the command may swallow errors on individual migrations and continue.
Extension points. Config-published output path/extension and the vendor stubs (if published) are the practical hooks. Beyond that, fork — there is no plugin API worth relying on, and the codebase is small enough to patch directly.
How can I help you explore Laravel packages today?