Product Decisions This Supports
- Build vs. buy for migration orchestration in a modular Symfony codebase. The package targets a real, recurring infrastructure need: coordinating Doctrine migrations that live across multiple bundles (ordering, execution, per-bundle ownership). This is the kind of plumbing teams either hand-roll or adopt. The assessment here is “build/thin-fork,” not “buy.”
- Modular monolith architecture and bundle boundaries. If the roadmap includes splitting a growing Symfony app into domain bundles (or a plugin-style architecture), migration ownership becomes a design constraint. Deciding where migrations live and who runs them at deploy time is an architecture decision this package informs — even if you don’t adopt it, the problem it names is one you’ll have to solve.
- Release and deployment engineering. Cross-bundle ordering affects deploy safety (schema changes must land before dependent code). This shapes your CI/CD migration step, rollback story, and environment promotion process.
- Framework-fit gate. Flag immediately: despite the brief referring to a “Laravel/PHP package,” this is a Symfony Bundle and does not apply to Laravel. That alone resolves the decision for any Laravel roadmap item: reject, and look at Laravel’s native migration tooling (
--path, migrate --realpath, or a small custom command).
- Dependency risk posture. 2 stars, 0 dependents, a 0.04 score, and no release Since August 2023 means this is effectively unvalidated OSS. It should not enter a dependency-approval list as a standard; it can enter a timeboxed spike.
Not supported by this package: anything customer-facing, differentiation, performance, or commercial. This is internal infrastructure at best.
When to Consider This Package
Consider it only when all of the following hold:
- You are on Symfony and already using DoctrineMigrationsBundle — not Laravel, not a raw PDO setup.
- You have three or more bundles that each ship their own migrations, and you have felt real pain: wrong execution order, duplicate version numbers, or migrations that must run in a bundle-specific sequence during deploy.
- You are willing to vendor, pin, and own the fork. Assume no upstream fixes; budget for reading the source before trusting it in production.
- You are running a timeboxed evaluation spike to see whether it solves ordering better than configuration alone, not standardizing on it.
Look elsewhere when:
- You’re on Laravel. Hard mismatch; the package is a Symfony Bundle. Use native per-path/database migration configuration.
- You have a single app or a small number of migration locations. DoctrineMigrationsBundle already supports multiple paths, namespaces, entity managers, and per-configuration runs. You likely do not need this bundle at all.
- You require maintained dependencies. No dependents and a stale release mean no ecosystem pressure to fix bugs, no security response, no compatibility guarantees against future Symfony/Doctrine versions.
- You need proven multi-database, multi-tenant, or large-team behavior. There is no adoption evidence to lean on; you would be the first serious user.
- You need community support or documentation as a first-class requirement. Evaluate the alternative of a ~100-line internal command that shells out to Doctrine per bundle with an explicit order list — often cheaper to own than an unmaintained dependency.
How to Pitch It (Stakeholders)
For executives (one paragraph): This is a small, unproven open-source utility that helps a Symfony application run database migrations that are spread across multiple code modules in the right order. It is not customer-facing and not a differentiator. The strategic question is “do we adopt it as infrastructure or build the equivalent ourselves?” — and the honest answer is: we should not adopt it as a standing dependency. It has essentially no adoption (two GitHub stars, no known users), a single maintainer, and no release in roughly two years. The underlying problem it addresses is real if we pursue a modular Symfony architecture, so the recommendation is a short, timeboxed spike plus a small in-house or forked solution if we need it — low cost, fully under our control, no supply-chain exposure.
For engineering (summary): It’s a Symfony Bundle that coordinates Doctrine migrations across bundles — ordering and execution — which is a legitimate gap in vanilla DoctrineMigrationsBundle setups. Treat it as a reference implementation, not a dependency: read the source, verify it works against your current Symfony/Doctrine versions, and expect to fork. Before adopting, benchmark it against plain Doctrine configuration (multiple paths/entity managers) and against a thin internal command with an explicit bundle order list; in most apps the latter wins on debuggability and ownership. Hard blocker: it is not Laravel-compatible, so any ticket framed that way should be closed and redirected to native tooling. If we do adopt, pin the version, vendor it, and add a migration-order integration test in CI so a Doctrine upgrade fails loudly rather than silently reordering deploys.