Laravel Mysqlite Laravel Package

Getting Started

laravel-mysqlite (dominion-solutions/laravel-mysqlite) registers a mysqlite database driver: a SQLite connection wrapped in MySQL-compatible schema/query grammars. The point is to run your MySQL-targeted test suite against in-memory SQLite without maintaining a parallel set of migrations or a MySQL service in CI.

Minimal setup:

composer require --dev dominion-solutions/laravel-mysqlite

Add a connection in config/database.php (the package ships a publishable config you can inspect with php artisan vendor:publish --tag=mysqlite-config):

'mysqlite' => [
    'driver' => 'mysqlite',
    'database' => ':memory:',
    'prefix' => '',
    'foreign_key_constraints' => true,
],

Then point tests at it in phpunit.xml:

<env name="DB_CONNECTION" value="mysqlite"/>

Where to look first: the package's service provider (driver registration), its schema grammar class (this is where MySQL-vs-SQLite translation lives), and config/mysqlite.php for toggles. Your first use case should be a single feature test using RefreshDatabase against the new connection — that tells you immediately whether your migrations are within the supported subset.

Implementation Patterns

Keep MySQL in production, MySQLite in tests. Do not swap the connection in application code. Leave DB_CONNECTION=mysql in .env, override only in phpunit.xml / phpunit.xml.dist, and let the test suite resolve the emulated driver.

Use RefreshDatabase per test class, not per test. In-memory SQLite is fast but the migration run is the expensive part. Standard RefreshDatabase with transactions gives you isolation without re-migrating for every method.

Prefer :memory: for unit/feature tests, a file for debugging. When a query behaves differently than expected, switch database to a temp file path so you can open it with sqlite3 and inspect the actual DDL the grammar produced. This is the single most effective debugging technique with this package.

Isolate MySQL-specific assertions. If a test genuinely depends on MySQL semantics (FULLTEXT relevance ordering, ON DUPLICATE KEY UPDATE edge cases, JSON path behavior), mark it with a group and run it only against real MySQL in a separate CI job. Don't force MySQLite to prove MySQL behavior it only approximates.

CI matrix. Run the MySQLite job on the PHP/Laravel versions you actually support, and keep one real-MySQL job as the source of truth. As of v2.0.2 the package's own CI covers Laravel 11, so that combination is a reasonable default for new projects; on older Laravel versions pin to the release line you validated.

Seeding and factories work unchanged — factories hit Eloquent, not the grammar, so only raw/schema-level MySQL syntax is at risk.

Gotchas and Tips

• Driver registration order matters. If a connection is resolved before the package's service provider boots (e.g. inside a cached config or an early-bound singleton), you'll get "Unsupported driver [mysqlite]". Clear bootstrap/cache/config.php after install and after changing the connection block.
• Config caching. php artisan config:cache in a test bootstrap can freeze the wrong DB_CONNECTION. Don't cache config in the test environment.
• Migrations are the failure surface, not models. Raw DB::statement() calls with MySQL-only syntax, FULLTEXT indexes, generated columns, and certain ALTER TABLE combinations are the usual breakages. Audit migrations that use DB::statement first.
• FULLTEXT and JSON are emulated, not equivalent. They exist so migrations apply and queries don't error — not so relevance scores, collations, or JSON path edge cases match MySQL. Assert on shape, not on MySQL-specific ordering.
• Foreign keys. SQLite needs PRAGMA foreign_keys=ON; verify foreign_key_constraints is true in the connection config or FK-violation tests will silently pass.
• Types and strictness. SQLite is dynamically typed. Column types you rely on for validation at the DB layer (e.g. rejecting a string in an INT column) won't be enforced the same way. Validate in the application layer, and don't write tests that assert MySQL strict-mode rejections.
• Dates and collation. NOW(), DATE_FORMAT, and case-insensitive LIKE differ. Use Carbon in tests and avoid asserting on DB-side date formatting.
• Extension point: the schema grammar is the intended override surface. If your app has one recurring MySQL-ism, subclass the grammar / connection and register it rather than patching vendor code — this survives upgrades and keeps the divergence in one auditable place.
• Version compatibility: v2.0.2 is a CI-only release (adds Laravel 11 to the test matrix) with no API, config, or behavior changes from v2.0.1. Safe upgrade; but treat "tested against Laravel 11" as coverage of the package's own suite, not a guarantee for your migration set — smoke-test your own suite after any minor bump.