Container Aware Migration Laravel Package

Product Decisions This Supports

• Data-migration strategy: services vs. raw SQL. This package exists to answer a recurring product question — when we backfill or transform production data, do we re-use domain logic (slug generators, pricing rules, search indexers, notification senders) or hand-write SQL that silently drifts from the code? A container-aware migration makes the "re-use domain services" option technically cheap, which is usually the correct product decision because it keeps business rules in one place.
• Build vs. buy for internal migration tooling. The capability is worth having; the package is a ~1-star, 0-dependent, effectively unmaintained artifact. The real decision is "do we need this capability?" (yes, for any project doing non-trivial data migrations) and "do we take this dependency?" (no — the bridge is small enough to own).
• Roadmap: operational readiness for backfills and cutovers. If the roadmap includes pricing changes, schema/data splits, taxonomy reworks, or search reindexing, migrations that can call application services materially reduce release risk and rollback cost. This supports investing in a migration harness rather than treating migrations as a one-off script dump.
• Platform choice signal: Symfony/Doctrine vs. Laravel/Eloquent. For a Laravel codebase this package is a non-fit — Laravel migrations already have app() available, so container access is free. Its existence is a reminder that Doctrine/Symfony teams pay a tax for the same ergonomics, and that a framework-standardisation or migration-away-from-Doctrine decision changes the value of this whole category.
• Deployment and release process. Container-aware migrations enable the pattern "ship code, then run a data migration that calls the newly shipped service," which is far safer than "ship code with a raw-SQL migration that duplicates it." That has a direct bearing on how we sequence releases and who owns data changes (app team vs. DBA/ops).
• Vendor and maintenance risk policy. A 1-star, 0-dependent package is a useful concrete case for setting a written bar (maintenance signals, security disclosure path, licence, bus factor) before adding any third-party dependency to the deploy path — migrations are especially sensitive because they run in production with elevated credentials.
• Prioritisation of internal developer tooling. Weigh a day of engineering for an in-house base class and MigrationFactory against the recurring cost of hand-rolled SQL data fixes, incident reviews, and "the backfill didn't match the app logic" bugs.

When to Consider This Package

Consider the capability if all of the following hold:

• The stack is Symfony with Doctrine Migrations (this package is not usable from Laravel's Eloquent migrator, and offers nothing Laravel doesn't already give you via the service container).
• Migrations genuinely need application services, not just the EntityManager/connection — e.g. a backfill must re-run a pricing calculator, slugger, indexer, or domain event flow.
• The team is small and the alternative is ad-hoc scripts, mysql sessions in production, or copy-pasted SQL that duplicates business rules.
• You are willing to vendor, fork, or reimplement the ~one-class bridge rather than depend on upstream: 1 star and 0 dependents is not a maintenance signal, and migrations run with production credentials, so supply-chain and abandonment risk must be priced in.
• You can verify compatibility with your Symfony/Doctrine versions during a short spike — the ContainerAware* idiom this is built on is legacy-era Symfony, so expect it to need adaptation on modern versions.

Look elsewhere (or build in-house) when:

• The project is Laravel — use app() inside migrations or a small base migration class; adopt nothing.
• Migrations are schema-only. If you never touch data, this adds a dependency and a production-container surface for no benefit.
• You work in a regulated or high-assurance environment where every production-path dependency needs an owner, CVE process, and SLA — an unmaintained single-author package will not clear review; write the 50–100 lines yourself (a base migration plus a custom MigrationFactory that injects a service locator).
• The real requirement is repeatable, idempotent, observable data transforms — that is closer to a job/command with batching, logging and dry-run than to a migration. Reach for a queued command or a backfill tool, and keep migrations for the schema plus a thin trigger.
• You need rollback guarantees for data changes. Container-aware migrations make it easier to do rich data work, which makes irreversible migrations easier to write; if the roadmap needs reversible data steps, the tooling decision is broader than this package.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source helper that lets database migrations call our application's business logic instead of hand-written SQL. The underlying idea is sound and reduces a real class of release bugs — data fixes that drift from product rules — but the specific package is effectively unmaintained (1 star, no downstream users), and it only applies to our Symfony/Doctrine services, not Laravel. Recommendation: do not adopt the dependency; instead we spend roughly a day of engineering to build the same ~100-line bridge in-house, which we control, can patch, and can audit. If we standardise further on Laravel, this category becomes moot because the framework already provides the capability. Net: a small, low-risk tooling investment that improves release safety for pricing, taxonomy and search changes on the roadmap, with no third-party production dependency.

For engineering leads: Adopt the pattern, not the package. Concretely: a base migration class plus a custom MigrationFactory that hands migrations a constrained service locator; restrict which services are exposed; forbid raw SQL duplicating domain rules in review; require idempotency, batching and dry-run flags for any data migration over N rows; and keep data migrations behind the same deploy/approval path as schema changes. Budget ~1 day to build and test, plus a lint rule or review checklist to stop the container becoming a back door into arbitrary services during migrations. Note also that the original package targets legacy ContainerAware-era Symfony, so any fork needs version-compatibility verification before it runs anywhere near production.