Laravel Sqlite Manager Laravel Package

Getting Started

The package is a local-development companion for inspecting and editing SQLite data without leaving the browser. It is not a migration or schema tool — think "SQLite browser, but Livewire and already wired into your app."

1. Require the package and let Laravel 12 auto-discovery register the service provider — no manual providers entry in bootstrap/providers.php needed.
2. Run the installer:

   php artisan sqlite-manager:install
   

3. Inspect what the installer touched before committing anything: it publishes config/sqlite-manager.php and appends package .env variables to your .env. Run git diff .env .env.example and mirror the new keys into .env.example so teammates and CI get them too.
4. Visit /sqlite-manager and pick a connection from your config/database.php SQLite connections.
5. First use case: open the users table, sort/browse a few rows, and confirm the column-aware editor renders correctly against your real schema (dates, nullables, text blobs). That one pass surfaces most of the surprises before you rely on it.

Where to look first:

• config/sqlite-manager.php — route path, middleware, table filtering patterns, defaults.
• The published .env keys — these usually control enablement and the route prefix; treat the enable flag as the production kill switch.
• Your database/database.sqlite file location, since the UI is only as useful as the connection it points at.

Implementation Patterns

Gate the route to non-production environments. The Livewire UI can create, edit, and delete rows, so it needs protecting from day one. Either restrict the package's middleware stack in config, or wrap the route behind a gate:

// app/Providers/AppServiceProvider.php
use Illuminate\Support\Facades\Gate;

public function boot(): void
{
    Gate::define('viewSqliteManager', fn ($user = null) => app()->isLocal());
}

Then add that gate's middleware to the package route in config/sqlite-manager.php (check the exact key — commonly middleware or route.middleware).

Use it as a debugging console for framework tables. The package already filters Laravel framework tables by pattern; when you're chasing a failing job, temporarily widen the pattern so jobs, failed_jobs, cache, and sessions appear, inspect the payload, then narrow it again. Persisting a permissive pattern is how you accidentally delete a cache row mid-request.

Tune preferences per workflow, not per project. Page size, visible columns, Laravel-table visibility, and nullable-field visibility are cookie-backed. That means:

• Each browser gets its own view — good for wide tables, bad for sharing a "canonical" view with a teammate.
• Use "visible columns" aggressively on tables with payload, options, or JSON blobs so the grid stays readable.
• Toggle the nullable-field visibility off on large create forms; you'll rarely want to hand-type deleted_at.

Seed-then-browse loop. Combine with factories for fast UI verification:

php artisan migrate:fresh --seed
php artisan serve
# then browse /sqlite-manager and verify create/edit forms against seeded edge cases

Include edge-case records in seeders — a row with every nullable column NULL, a row with the maximum text length, a row with timezone-sensitive datetimes. The create/edit controls are type-driven, so seeding edge cases is the cheapest way to validate that the form controls match what your model expects.

Prefer the UI for content fixes, Artisan for structural change. Use the manager to correct a bad seed value or flip a feature flag row during testing. Anything involving schema — new columns, index changes, backfills across thousands of rows — belongs in a migration or tinker/Artisan command so it's reproducible and reviewable.

Keep config in the published file. Edit config/sqlite-manager.php rather than vendor files, and commit it. If you support multiple local setups (different SQLite file paths per developer), read the connection from .env and leave the committed config pointed at that env key.

Gotchas and Tips

• Single-column primary keys only. Record create/edit/delete is limited to tables with a single-column PK. Composite-key tables (typical many-to-many pivots, and any table using a natural composite key) will be browsable but not editable. If a form silently doesn't appear, check the PK definition before assuming a bug — PRAGMA table_info(your_table); is the fastest confirmation.
• No raw SQL console. The release notes describe browsing and row editing only. Complex joins, aggregates, and EXPLAIN QUERY PLAN work still need sqlite3, tinker, or a DB tool. Don't promise stakeholders a general SQL workbench.
• Cookie-scoped state confuses handoffs. "The columns changed" or "my page size reset" is almost always cookie/session state, not a package bug. Reproduce in a private window before filing anything, and remember preferences don't travel between machines or between the app and Livewire tests.
• Installer edits your .env idempotently-ish, not magically. Re-running sqlite-manager:install after upgrading can duplicate keys. Diff .env after every install and before every commit; keys added by the installer should land in .env.example in the same PR.
• Route prefix is config-driven. If /sqlite-manager 404s, check the published config for a custom path/domain before assuming discovery failed. Also verify the route is registered at all in production-like environments — an enable flag may short-circuit it, which is the desired behavior.
• Type mapping is convention-based. Text, numeric, date, datetime, time, and textarea controls are inferred from the column definition. SQLite's dynamic typing plus Laravel's datetime casting can disagree — e.g. an integer timestamp column renders as a numeric input, and a TEXT column holding JSON renders as a plain textarea (no validation, no pretty-printing). Validate anything you hand-edit through the UI against the model's casts.
• No audit trail. Edits are direct writes. For anything you might need to explain later, capture intent elsewhere (a note, a ticket, a seeded migration) rather than relying on the UI history.
• Debugging a blank or broken table view: confirm the connection actually points at the intended .sqlite file, then clear compiled views and config — php artisan view:clear && php artisan config:clear — since packaged Livewire views and cached config are the two usual suspects after a config change.
• Extension points to lean on: the published config (table filtering patterns, route settings, defaults) is the intended surface. If you need bespoke behavior — soft-delete-aware listing, tenant scoping — build it as an authorization gate or a config-level table filter rather than patching the UI.