Laravel Data Dumper Laravel Package

Product Decisions This Supports

• Feature/architecture: where "reference data" lives. Decides whether static lookup tables (roles & permissions, countries/currencies, tax rates, plan definitions, status enums, feature flags) ship as schema or as seeders. This package makes the schema-dump route viable, which is the cheaper long-term option for data that is identical in every environment.
• Roadmap: migration-squash strategy. If we adopt Laravel's schema:dump + --prune workflow, this package answers the immediate follow-up question ("what about the data those old migrations inserted?"). It removes the main blocker engineering raises when proposing a migration squash.
• Build vs. buy: keep vs. write in-house. The surface area is one artisan command extension plus a config list of tables — realistically a day of internal work. The decision is really "take a tiny, single-maintainer, zero-dependent dependency as require-dev" vs. "vendor ~200 lines." Low-stakes either way, which is itself the useful finding.
• Delivery/CI decisions. Enables php artisan migrate on a fresh database to yield a working application without a separate db:seed step — affecting pipeline design, local onboarding time, and ephemeral test-DB provisioning.
• Data governance. Forces an explicit, reviewable allowlist of "this data is versioned with the schema and must never diverge per environment." Good artifact for audits; a trap if applied to tenant- or environment-specific data.
• Environment parity. Directly reduces the recurring class of bug where staging/prod reference data drifts because a seeder was added but never back-filled.

When to Consider This Package

Adopt when:

• The app is on a supported Laravel version, uses schema:dump (or is about to), and the squashed-schema workflow is already or soon-to-be in place — the package is meaningless without it.
• You have a small set of static, deterministic, environment-agnostic tables (roughly hundreds to low thousands of rows) that every deployment needs identically.
• Onboarding time, CI DB provisioning, or "missing rows on fresh install" bugs are an actual, measurable pain.
• You are comfortable pinning it as a dev dependency and reviewing the generated schema/*.sql diff in code review.

Look elsewhere / deprioritize when:

• The data is large or volatile (full geo datasets, translations, catalogs sourced from an upstream feed). Use importers/seeders with idempotent upserts instead — a .sql schema file will bloat and churn.
• Any row is tenant-specific, environment-specific, or contains secrets/PII. Baking it into a committed schema file is a compliance problem.
• The team hasn't adopted schema dumping at all. Sequence matters: native Laravel workflow first, this package second. It is not a reason to adopt squashing by itself.
• You need data changes tracked over time (audit, upsert-on-deploy, rollback semantics). That's a migration/seeder concern; a schema dump is a snapshot, not a history.
• Maturity risk is still a real consideration, though slightly improved: adoption remains negligible (tens of stars, 0 dependents) and it is effectively one maintainer. The 1.6.0 release does confirm the project is alive and tracking upstream Laravel — Laravel 13 support landed promptly — so the "abandonware" risk is lower than the raw star count suggests, but the maintainer-response caveat still stands. Verify driver support (MySQL/Postgres/SQLite) against your stack, confirm the release targets your Laravel version, and check issue activity. Given the tiny footprint, the pragmatic fallback remains to vendor the logic and drop the dependency.
• Determinism check: confirm row ordering in the dumped output is stable, or every schema-dump run will produce noisy VCS diffs and erode trust in the workflow.

How to Pitch It (Stakeholders)

To executives: A small, free (MIT) developer-tooling package that shortens the path from "empty database" to "working application" — fewer setup steps for new engineers and CI, and fewer incidents where a fresh or staging environment is missing reference data that production has. It is dev/CI-only, has no runtime or production footprint, and can be removed in an afternoon. Cost is near zero; the payoff is reduced environment drift and faster onboarding. Frame it as a tactical enabler of an already-planned migration-squash cleanup, not a standalone initiative.

To engineering: It extends php artisan schema:dump so that INSERT statements for a configured allowlist of tables are written into the squashed schema file alongside the DDL. Result: migrate on a clean database reproduces both structure and essential reference data, with no seeder step. Install as require-dev, keep the table list short and curated, and treat the generated schema file as reviewed source. The 1.6.0 release adds Laravel 13 support, so forward compatibility is covered for teams upgrading. Caveats to accept explicitly: single-maintainer project with negligible adoption, so pin the version and be prepared to vendor it; and it only makes sense once we're committed to schema dumping. Do not use it for large, volatile, or environment-specific datasets.

Recommendation: Pilot on one service with a short allowlist (roles/permissions, countries), install as a dev dependency, and time fresh-environment setup before and after. If it holds up, standardize it in the template repo; if maintainer activity stalls, vendor the command. The 1.6.0 bump confirms the package follows Laravel releases, which modestly raises confidence in the pilot — but given the low opportunity score, keep treating this as an internal hygiene win rather than something to build a platform strategy around.