Schema Tools Laravel Package

Getting Started

1. Install and confirm what you actually get. The package has no dependents and no published docs beyond the README, so the first job is discovery, not coding:

composer require dvrtech/schema-tools --dev
php artisan about            # confirms the service provider was auto-discovered
php artisan list | grep -i schema

Everything downstream depends on those two commands. If about doesn't list a provider, the package isn't Laravel-auto-discovery compatible and you'll need to register it manually in bootstrap/providers.php.

2. Publish config and stubs before your first run.

php artisan vendor:publish --provider="Dvrtech\SchemaTools\SchemaToolsServiceProvider"

Check config/schema-tools.php immediately for: default connection, output paths, excluded tables (migrations, telescope_*, failed_jobs), and any driver setting. This is the file you'll edit most.

3. Point it at a disposable database. Create a scratch connection in config/database.php (or a .env.testing entry) that mirrors production structure but holds no real data. Schema tooling is almost always read-heavy but migration/model generation writes files — you do not want a half-generated migration set committed against your real app by accident.

4. First use case: baseline an existing database. The highest-value day-one job for a package like this is turning a legacy or hand-managed schema into versioned Laravel artifacts:

• Dump the live schema to a snapshot file (JSON/SQL, depending on what the package emits).
• Diff it against the migrations already in database/migrations.
• Generate the missing create_* / table_* migrations so php artisan migrate:fresh reproduces production.

Do this on a branch, run migrate:fresh against the scratch DB, then re-dump and compare the two snapshots. Identical output = you have a trustworthy baseline. That single check is worth more than any feature list.

Implementation Patterns

Snapshot-and-diff in CI. Commit the generated schema snapshot to the repo and add a pipeline step that regenerates it and fails on a non-empty diff. This catches "someone edited the schema by hand" and "a migration was merged without its model change" before they reach production. It's the cheapest schema-drift guard available and doesn't require a live comparison DB.

Generate-then-review, never generate-then-commit. Treat generated migrations and models as scaffolding. Column ordering, index names, down() methods, and enum handling routinely need hand-fixing. A practical workflow: generate into database/migrations/_generated/, review the diff in the PR, then move the files into the normal directory with a conventional timestamp.

Local schema reset loop. For long-lived feature branches touching many tables, wrap the package's dump/restore in a composer script so you can reset structure without a full migrate:fresh seed cycle:

"scripts": {
  "schema:snapshot": "php artisan schema-tools:dump --connection=scratch",
  "schema:restore":  "php artisan schema-tools:restore --connection=scratch"
}

Pair it with Laravel's native inspector. Since Laravel 10/11, Schema::getTables(), Schema::getColumns(), and Schema::getIndexes() cover a lot of ground natively. Use the package for the generation/persistence layer and fall back to the native facade for ad-hoc queries inside your own commands — that keeps your bespoke code portable if the package stalls (0 stars, 0 dependents, so plan for that).

Wrap it in your own command. Rather than calling package commands directly from deploy scripts, write a thin app/Console/Commands/CheckSchemaDrift.php that shells out or calls the service class. You get one stable entry point, easy mocking in tests, and a single place to swap implementations later.

Multi-connection apps. Run per-connection explicitly (--connection=tenant) rather than relying on the default. Tenancy setups with dynamic connections will otherwise silently operate on whichever connection happens to be last configured.

Gotchas and Tips

Vendor risk is the headline issue. Zero stars, zero dependents, and a single maintainer means bus-factor 1. Pin the exact version in composer.json ("dvrtech/schema-tools": "1.2.3", no caret), install it under require-dev if it only feeds tooling, and consider vendoring or forking if it becomes load-bearing.

Verify the release metadata. The listed last release (2026-10-20) is ahead of the current date — check Packagist for the real tag list and changelog before assuming a version exists or is stable.

Driver divergence will bite. SQLite has no native ENUM, no unsigned integers, and no column comments; MySQL does; Postgres differs again on SERIAL/identity and array types. Any generated migration from a Postgres source will not round-trip cleanly onto SQLite in your test suite. Always run the snapshot → migrate:fresh → re-snapshot loop on the same driver you deploy to, and add ->comment() / enum handling manually.

Dependency ordering in generated migrations. Foreign keys and indexes frequently emit in the wrong order, or in a separate migration that runs before the table exists. Symptoms: errno: 150 on MySQL, no such table on SQLite. Fix by splitting into create_tables then add_foreign_keys phases, or disable FK checks for the baseline run.

Composite keys, spatial types, and generated columns are the usual unsupported cases. Grep the generated output for anything the tool silently skipped — a missing geometry column won't error, it just won't exist.

Never point it at production. Even read-only introspection can lock metadata tables on busy MySQL instances, and a misconfigured --write flag is unrecoverable. Enforce it with a guard at the top of your wrapper command:

abort_if(app()->environment('production'), 1, 'Schema tooling is disabled in production.');

Debugging output problems. Re-run with -vvv and check storage/logs/laravel.log — many small packages dd() or var_dump() on failure rather than throwing. If output looks truncated or empty, confirm the excluded-tables list isn't over-matching (telescope_* globs and explicit names behave differently).

Extension points to look for first. In a package this small, the class map is the documentation: read src/ for a driver/type-mapping registry, a config-driven type override array, and published stubs. Type overrides are usually the fastest fix for a wrong column type — cheaper than forking. If no override hook exists, a decorator around the package's service class in your AppServiceProvider is less invasive than editing vendor/.