sp/fixture-dumper
sp/fixture-dumper is a Laravel package for capturing database data as reusable fixtures. Dump selected tables into fixture files, then reload them in tests or seeders for fast, consistent database setup without hand-writing sample records. Ideal for reproducible test suites and local development.
sp/fixture-dumper is a small, single-purpose library: give it a database connection and a table name, and it emits the table's rows as a fixture file you can commit and reload later. It was written in the Doctrine/Symfony ecosystem (last release January 2017), so on a Laravel project you are using it as a standalone CLI/utility, not as a framework integration.
Minimal steps:
composer require sp/fixture-dumper — expect to pin it and accept that you are on your own for PHP 8 compatibility (see Gotchas). If it fights your platform, --ignore-platform-reqs on a throwaway install is a reasonable way to evaluate it before committing.README.md first, then src/ — you are looking for the dumper class (constructor takes a PDO/DBAL connection) and the format writer. With 9 stars and no recent activity, the source is the documentation.countries or categories (tens of rows), and open the output. Confirm the file format and how types/NULLs are represented before you dump anything large.If you want it inside Laravel, the sane shape is a thin Artisan command (php artisan fixtures:dump countries currencies) that news up the dumper with DB::connection()->getPdo() and writes to database/fixtures/. Keep the library behind that command so a future replacement is a one-file change.
Dump-on-demand command. Wrap the dumper in an Artisan command with an explicit table whitelist and a --connection option. Never let it walk SHOW TABLES blindly — you will capture jobs, failed_jobs, sessions, cache, and migrations.
Reference data vs. test fixtures. Use two output directories. database/fixtures/reference/ is committed and loaded on install; tests/fixtures/ is regenerated from a curated scenario database and is often gitignored. The dumper does not know the difference; the directory convention does.
Deterministic output. Sort by primary key (or by a natural key) before writing so re-dumping an unchanged table produces an empty diff. If the dumper preserves auto-increment IDs, strip or remap them on the way out — tests that assert on id = 1 are the classic source of flaky suites. Prefer loading fixtures by natural key (where slug = ...) rather than by ID.
Round-trip through a loader you control. Do not assume the library has a matching loader worth using. Read the dumped file (YAML/PHP array), then insert with DB::table($table)->insert($rows) inside a transaction, disabling FK checks for the duration. This keeps the loading semantics in your code where you can cast types, rewrite timestamps, and null out environment-specific columns.
Selective column dumping. For tables containing created_at/updated_at/deleted_at, strip or normalize timestamps on dump. For PII (users, orders), dump a masked subset — either a --columns whitelist in your wrapper or a post-processing pass over the parsed output.
Refresh workflow. A common loop: seed a local DB with realistic data → exercise the app → dump the tables you care about → commit → CI loads them. Treat the dump step as a build artifact step, not something a developer runs by hand for 40 tables; script it.
CI usage. In CI, create a schema-only database (migrate --pretend-style or a squashed schema dump), load the committed fixtures, then run tests. This is faster than factories for large reference sets and gives you realistic data shapes for query tests.
It is effectively abandoned. Last release 2017, single-digit stars, zero dependents. Expect PHP 8 deprecation noise, each()-era idioms, and no typed properties. Do not put it on a hot path in production code; confine it to dev tooling and scripted fixture generation. Budget an afternoon for a fork-and-patch if it does not install cleanly.
Doctrine assumptions. The library predates and ignores Eloquent. It talks to a connection and reads rows; it has no concept of models, casts, accessors, global scopes, or soft deletes. It will happily dump deleted_at rows and raw JSON strings while your application expects hydrated models. Anything your model layer does (encryption, casting, mutators) is invisible to the dump — which is either exactly what you want or a silent correctness bug depending on the table.
Foreign keys and ordering. Dumps are per-table and order-agnostic. Loading them back needs FK checks disabled and a stable insertion order, or you will chase constraint violations that have nothing to do with the data.
Type fidelity loss. Expect everything to arrive as strings: booleans become "1"/"0", decimals lose precision context, NULL may be indistinguishable from empty string in some writers. Write an explicit per-table cast map in your loader rather than trusting the file.
Escaping and binary data. Blobs, binary UUIDs, and multi-line text with YAML-sensitive characters are where hand-rolled dumpers break. Test with a table containing newlines, quotes, backslashes, and an emoji before you trust it on anything important. If a table has blobs, exclude the column.
Character set. Dump through a connection with explicit UTF-8 (charset=utf8mb4); a mismatch silently produces mojibake that only surfaces when a test asserts on a name.
Debugging. Start with a one-row table. If output looks wrong, check the connection's PDO::ATTR_STRINGIFY_FETCHES and ATTR_EMULATE_PREPARES settings — these change what the dumper sees. Log the SQL it issues if the library exposes that; older dumpers sometimes build SELECT * without a limit, which will happily try to stream a million rows into memory.
Extension points are thin. With a package this size there is usually a single formatter/writer seam. If you need custom value rendering (e.g. dates as now(), IDs as sequence markers), look for a protected formatValue/dumpRow-style method to override via subclass before you consider forking. That is the cheapest customization point; everything else is a fork.
Sizing. Fixture files in git grow monotonically and diffs get noisy. Cap dumped tables at a few thousand rows, or chunk output per table into multiple files, and add a CI check that fails when a fixture file exceeds a size threshold. Without this, the workflow degrades into "never re-dump because the diff is enormous."
Have an exit plan. Given the maintenance status, isolate the library behind your own FixtureDumper interface. The replacement (a 150-line PDO loop over SELECT * FROM $table) is trivial, and having the seam means the decision to drop the dependency later costs nothing.
How can I help you explore Laravel packages today?