- Can I use gheb/data-migrations-bundle in a Laravel application?
- No. Despite occasional mislabelling as a Laravel/PHP package, this is a Symfony bundle built on Symfony's DI container, Console component, and kernel lifecycle, plus Doctrine ORM/DBAL and the Doctrine migrations stack. It has no Laravel service provider, no Eloquent integration, and does not hook into Artisan, so shimming it into a Laravel workflow is not practical. Laravel teams should keep data changes in native migrations or a small first-party runner.
- What is gheb/data-migrations-bundle used for?
- It manages data migrations as versioned, ordered changes that sit alongside your schema migrations, so ad-hoc scripts are replaced with tracked data transformations. Each migration is recorded in a ledger so it is not run twice, and the distinction between one-time and repeatable data changes is preserved. The goal is auditable, repeatable data changes rather than SQL-diff schema changes.
- Is gheb/data-migrations-bundle still maintained?
- No. The repository is archived, has roughly 4 stars, 0 dependents, and no visible maintainer activity, CI, or issue traffic. That means no CVE handling, no PHP minor-version fixes, and no dependency bumps. Treat any transitive advisory in it as your own incident.
- What Symfony, PHP, and Doctrine versions does it require?
- Expect constraints along the lines of php ^7.x, symfony ^3.4|^4.x, and doctrine/* ^2.x. Modern PHP 8.2+ with Symfony 6/7, or Doctrine DBAL 3/4, will likely fail Composer constraint resolution outright. DBAL 3 also removed APIs such as fetchAll and changed execute and Statement behaviour that older code relies on.
- Does it work with Doctrine DBAL 3 or 4?
- Almost certainly not without patching. The bundle predates the DBAL 3 API removals, including fetchAll and the changed execute signatures and Statement behaviour, so code paths that touch the connection will break or behave differently. If you need DBAL 3/4 support, plan on forking and porting rather than expecting an upstream fix.
- How do I install and configure it?
- In a Symfony 3.4/4.x project with Doctrine 2.x you would require it via Composer, register the bundle in AppKernel or bundles.php, and point it at your Doctrine connection and migration paths. Because the repository is archived, you should vendor or fork it rather than depend on Packagist resolution. Verify the configuration against the source, since there is no maintained documentation or recipe.
- How does it track which data migrations have already run?
- It records executed migrations in a ledger table so the same migration is not applied twice, mirroring how schema migration runners track versions. That ledger is also what gives you an audit trail of when each data transformation ran. This versioned, ledger-recorded ordering is the durable pattern worth copying even if you do not use the bundle itself.
- Does it have tests or a CI pipeline?
- There is no evidence of a test suite or CI in the repository. For code that mutates production records, unverified correctness is a larger risk than version drift, because a bug here is a data-integrity bug rather than a build failure. Any adoption should include writing your own characterisation tests around the runner before it touches real data.
- Is it safe to use in a production deploy path?
- That is a high-risk position for any third-party component, and this one is unmaintained and archived. Whatever you adopt sits between a schema change and the new application code serving traffic, which is a high blast-radius spot. If you have audit, PII, or zero-downtime requirements, an unpatched component in the deploy path is usually categorically unacceptable; fork it with a named owner and a funded maintenance line instead.
- What are the alternatives to gheb/data-migrations-bundle?
- In Symfony, most teams either put data transformations into Doctrine migrations or build a small first-party runner with a ledger table, ordered files, and one console command. In Laravel, native migrations are already arbitrary PHP, so DB::table(...)->update(...) can be interleaved with schema calls in a single file. The bundle's real value is the pattern, not the product, and the pattern is roughly a sprint of internal work.