Laravel Drift Laravel Package

Getting Started

Because dashed/laravel-drift has no dependents and effectively no community footprint, treat the repository itself — not blog posts or docs sites — as the source of truth. Budget 15 minutes to read README.md, composer.json, and the tests/ directory before installing anything.

1. Install and pin.

   composer require dashed/laravel-drift --prefer-dist
   

   Immediately lock the exact version in composer.json (drop the caret if the package follows semver loosely). With a 0-star package you want reproducible installs, not floating minors.

2. Confirm auto-discovery. Laravel will register the service provider via extra.laravel.providers if the package is well-behaved. Check composer.json in the package for that block; if absent, add the provider manually in config/app.php (or bootstrap/providers.php on Laravel 11+).

3. Publish config early.

   php artisan vendor:publish --tag=drift-config
   

   If no tag exists, look for vendor/dashed/laravel-drift/config/ and copy it manually. Skim every key — for a small package the config file is usually the best documentation of intended behavior.

4. Read the tests before your first run. The test suite is where the real contract lives. Look for what the package considers "drift," what the comparison target is, and what the assertions check. This tells you faster than the README whether it fits your use case.

5. First use case — pick the narrowest one. The natural first run is a single artisan command (something like php artisan drift:check) against a non-production database, or a facade call in php artisan tinker:

   \Dashed\Drift\Facades\Drift::check();
   

   Verify the command name and facade alias in the provider's boot()/register() methods rather than guessing.

Implementation Patterns

Scheduled drift detection. The most durable integration is a scheduled command in routes/console.php (or Kernel::schedule()) that runs a check and alerts on non-empty results:

Schedule::command('drift:check')->dailyAt('02:00')
    ->onFailure(fn () => /* notify */);

Keep the output machine-parseable — pipe to a log channel rather than relying on human-readable console text.

CI gate. If the package exposes a non-zero exit code on drift, wrap it in your pipeline as a pre-deploy step. This is the highest-value pattern: catch unintended schema/content divergence before it reaches production. If exit codes aren't documented, check them yourself in a throwaway branch.

Baseline-and-diff workflow. Mature "drift" tools work best when you snapshot a known-good state once, then compare future runs against it. Look for a --baseline, --snapshot, or equivalent flag; if it exists, generate the baseline immediately after a clean deploy and commit it (or store it in your DB).

Environment pairing. Run the check twice — once against staging, once against production — and diff the two outputs manually rather than trusting a single environment's view. Small packages rarely compare environments for you.

Programmatic use over CLI. If a facade is exposed, prefer calling it from your own command or job so you control retries, logging, and notification. Treat the artisan command as a debugging convenience, not the integration surface.

Thin wrapper. Isolate the package behind one small service class (DriftService) in your app. Given its maturity level, you want a single file to change if you swap it out later.

Gotchas and Tips

• Adoption risk is the headline issue. Zero stars and zero dependents means no battle-testing across Laravel versions. Check composer.json for the illuminate/* constraints and confirm they actually cover your Laravel major — not just the one the author develops on.
• The most recent release date can be misleading. A 2025-11-21 tag on an otherwise quiet repo often signals a single-author first or second cut. Read the commit history: if the initial commit and the release are close together, expect rough edges.
• Config caching bites. After publishing or editing config, always php artisan config:clear before debugging. A stale cached config is the single most common cause of "the package ignores my settings."
• DB-driver differences. Anything that inspects schema or compares data will behave differently across MySQL, PostgreSQL, and SQLite. Run the tests on your actual driver; the package author may have only tested one.
• Name your assumptions explicitly. Confirm whether "drift" here means schema drift, content drift, or environment drift before wiring it into anything important. The namespace (Dashed\Drift) and repo name are the only clues; verify against the source.
• Debug with verbosity. Add -vvv to artisan commands and, if the package emits events, listen for them (Event::listen('*', ...)) to trace what it's doing. With sparse docs, event and log inspection is your debugger.
• Extension points are likely the facade, config, and any published views/migrations. Grep the source for bind, singleton, and interfaces to find override seams before you fork.
• Vendor the source if it's critical. If you depend on this in production, either pin aggressively or copy the few files you need into app/Support/. The MIT license permits it, and you avoid supply-chain surprises from an inactive repo.
• Watch the issue tracker and release cadence. On a package this young, an unmaintained repo is a real outcome. Set a calendar reminder to re-evaluate in 3–6 months; if there's no movement and no forks, plan the exit.