- What does dashed/laravel-drift actually do?
- Laravel Drift is positioned as a drift detector: it compares your declared schema source of truth, such as your migration files or a model introspection layer, against the live database and flags unexpected columns, indexes, and tables. The intended outcome is catching divergence before it causes surprise migration failures. Because the package has no independent review, treat the exact comparison semantics as an assumption and confirm them by reading the source. In practice it is a read-only diagnostic that sits beside your application rather than inside the request path.
- How do I install dashed/laravel-drift in a Laravel application?
- Install it with composer require dashed/laravel-drift, pinning an exact version or commit hash rather than a floating constraint. Then check whether the package ships a service provider with auto-discovery or requires manual registration in config/app.php. Verify whether a config file needs publishing and which artisan command exposes the check. Confirm the install adds no post-install scripts or outbound network calls before you run it.
- Does dashed/laravel-drift support MySQL, PostgreSQL, and SQLite?
- This is unconfirmed and must be verified during a spike, since the package has zero dependents and no corroborating usage evidence. Schema introspection differs per driver: MySQL and PostgreSQL expose information_schema, while SQLite requires pragma-based table and index inspection. Test it against every driver you run, including SQLite for your test suite. A package that only handles one driver will fail fast and cheaply, which is a useful early signal.
- Which Laravel versions does dashed/laravel-drift support?
- Check the illuminate/support and php constraints in the package's composer.json before assuming compatibility, and test against both your current and next LTS. Verify the package resolves cleanly on a fresh Laravel skeleton with your PHP version. If constraints are narrow or missing, plan for a fork or a version bump in your private registry. Do not rely on the README alone for supported versions.
- Is it safe to run dashed/laravel-drift in production?
- A well-built drift checker is a read-only diagnostic, which is the most favorable shape for an unvetted dependency, but you must confirm it is genuinely read-only in the source. Expect it to need access to schema metadata, so use a least-privilege database user rather than an elevated one where possible. Keep it out of the production request path and run it in CI or against staging snapshots. Only promote it to production checks after auditing queries and confirming no writes.
- Can I run dashed/laravel-drift in a CI pipeline?
- That is the primary intended use case: run the check in CI to keep every environment in sync. Verify that it exposes an artisan command or injectable service you can call programmatically and that it returns a non-zero exit code when drift is detected. Without a failing exit code the check cannot gate a pipeline. Also confirm it works against a freshly migrated database so a clean schema reports clean.
- How reliable is drift detection, and what about false negatives?
- Comparison logic is where subtle wrongness hides, and false negatives are far more dangerous than false positives because they create false confidence in the migration hygiene you are trying to enforce. Deliberately introduce drift in a test schema by adding an extra column, an index, and a whole table, then confirm each is reported. Also test renames, default values, and nullability changes if the tool claims to compare them. Record the observed false-negative rate for your spike owner before adoption.
- Is dashed/laravel-drift actively maintained and trustworthy?
- It has zero GitHub stars, zero dependents, and a single publish event dated 2025-11-21, which means no independent review and no issue history to learn from. MIT licensing is permissive and low concern, but confirm the LICENSE file exists and matches the composer metadata. Pin to an exact version or commit hash, audit the source for post-install scripts and network calls, and vendor-fork into a private registry if you adopt it. Assume no upstream fixes and budget accordingly.
- How is this different from migrate:status or Doctrine-based schema tools?
- Migrate status tracks which migration files have run, not whether the live schema matches what those migrations declare, so it cannot detect manual schema edits or out-of-band changes. Drift detection compares actual database structure against a declared source of truth. Whether Laravel Drift reads migrations directly or relies on a model introspection layer determines what it can and cannot catch, so verify that in the source. Compare its output against a manual information_schema diff on a deliberately drifted database.
- Can I fork dashed/laravel-drift and maintain it internally?
- MIT permits forking and internal maintenance, so yes, provided the LICENSE file is present and matches the composer metadata. Given the single-maintainer profile and no dependents, a fork is a realistic exit plan rather than an edge case. Decide upfront who owns the fork, which drivers and Laravel versions it must support, and how you will add tests around the comparison logic. Keep the fork in your private registry and pin applications to it explicitly.