coringawc/filament-plugin-workbanch
A Filament plugin workbench that gives developers a dedicated environment for building, testing, and managing custom Filament plugins inside Laravel admin panels, streamlining plugin scaffolding and administration.
This package gives you a Testbench-powered workbench plus a Docker stub, so you can run a real HTTP server for your package instead of exercising everything through the in-memory testing connection.
Require it as a dev dependency and let the package scaffold the workbench app and Docker stub (workbench/ plus a docker-compose file / Dockerfile pair). Publish the stub rather than hand-writing one — v1.1.1 changes live in the stub, so you want the upstream version as your baseline.
Start the container (docker compose up), then confirm where SQLite actually points:
docker compose exec app php -r \
"echo config('database.connections.sqlite.database'), PHP_EOL;"
You want an absolute path on a mounted volume (e.g. /var/www/html/database/database.sqlite), not :memory:.
Run migrations/seeding once inside the container, then hit a route over HTTP (curl localhost:8000/... or a Dusk/browser-style test). That request/response cycle — not $this->get() inside a single test method — is the first use case worth validating, because it is exactly the scenario the in-memory fallback used to break.
Look first at the published Docker stub and the workbench .env; those two files determine 90% of the behaviour you'll be debugging.
Persistent-file-by-default for anything multi-request. Keep DB_DATABASE pointing at a file on a volume for the workbench container. Reserve :memory: for pure unit-style feature tests that live inside a single test method. Mixing the two in one suite is fine, but make the choice explicit per suite rather than inheriting whatever the stub happened to set.
Volume mount must match the configured path. If the stub writes to /var/www/html/database/database.sqlite, your compose volume must mount that directory — mounting a different path silently yields an empty, freshly-created database that looks like "migrations didn't run".
Mirror the stub in CI. Run the same published stub in CI so local HTTP tests and pipeline HTTP tests share one connection story. This is the main payoff of v1.1.1: the container path is now injected by the stub, so CI no longer drifts into the in-memory connection.
State-reset discipline. Because the database is now persistent across requests, be deliberate about teardown: migrate:fresh (or dropping the file) between suites, and prefer RefreshDatabase in Testbench tests over assuming a clean in-memory DB per test.
Seeding through the container, not the host. Run migrate/db:seed with docker compose exec, so the SQLite file is written by the same user and path the web process sees. Host-run commands can create a root-owned or differently-pathed file that the container then ignores.
Keep customisations in your own stub copy. If you add services, env vars, or extra mounts, treat the published stub as a starting point and track your divergences — future releases patch the stub and a --force republish will overwrite your edits.
no such table errors appeared on the second request, or a login/session flow worked in a single test method but failed over real HTTP. If you see those, check the resolved database.connections.sqlite.database first — it's usually :memory: where you expected a file.config('database.default') and the sqlite path) rather than guessing.:memory: per-connection semantics. In-memory SQLite is per-connection; anything that opens a second connection — queue workers, Octane-style workers, parallel test processes — sees a different, empty database. This is the classic reason to move to a file even in tests.database is locked under parallel requests; keep writes short, and consider PRAGMA journal_mode=WAL in your stub if you're exercising concurrent paths.How can I help you explore Laravel packages today?