Composer Bundle Migration Laravel Package

Product Decisions This Supports

• Decoupling migrations from vendor bundles: Enables cleaner project structure by moving migrations out of third-party bundles, reducing merge conflicts and simplifying dependency management.
• Standardizing migration workflows: Aligns with Symfony/Laravel best practices by consolidating migrations in a single, project-specific location (app/DoctrineMigrations).
• Build vs. Buy: Avoids reinventing migration synchronization logic, saving engineering time while maintaining control over migration organization.
• Use cases:
  • Large-scale Symfony/Laravel projects with multiple Doctrine-dependent bundles.
  • Teams prioritizing maintainability over convenience (e.g., avoiding vendor-specific migration paths).
  • Projects adopting monorepo-like structures where migrations should live alongside core logic.

When to Consider This Package

• Adopt when:

  • Your project uses Doctrine Migrations with multiple bundles contributing migration files.
  • You’re migrating from a monolithic bundle structure to a modular architecture.
  • Your team struggles with merge conflicts or vendor-specific migration paths during composer update.
  • You need consistent migration directories across environments (dev/staging/prod).

• Look elsewhere if:

  • Your project uses fewer than 3 bundles with migrations (overhead may not justify benefits).
  • You rely on custom migration tools (e.g., FlySystem, custom scripts) that conflict with this approach.
  • Your team prefers vendor-managed migrations (e.g., for plugin-based systems like eZ Platform).
  • You’re using Laravel’s native migrations (this package is Symfony/Doctrine-focused).
  • The AGPL-3.0 license conflicts with your project’s licensing (e.g., proprietary software).

How to Pitch It (Stakeholders)

For Executives: "This package automates the migration of database schema updates from third-party bundles into our project’s root directory, reducing technical debt and merge conflicts during dependency updates. By standardizing migration paths, we’ll improve deployment reliability and developer velocity—especially for teams working across multiple Doctrine-dependent bundles. The time saved here can be reinvested in core features. It’s a low-risk, high-reward tool for projects scaling beyond basic bundle usage."

For Engineering/DevOps: *"This solves a common pain point in Symfony/Laravel projects: migrations scattered across vendor directories. With a one-line Composer script, we’ll sync all bundle migrations into app/DoctrineMigrations (or a custom path), eliminating:

• Merge conflicts during composer update.
• Environment inconsistencies (e.g., missing migrations in CI).
• Debugging headaches from vendor-specific paths. It’s a drop-in solution that works alongside existing Doctrine tools. Tradeoff: minor Composer script overhead for long-term maintainability gains."*

For Developers: *"No more hunting for migrations in vendor/bundle/Resources/migrations. This tool copies all Doctrine migrations to your project root during composer install/update, so:

• Your IDE/editor treats migrations as first-class project files.
• php bin/console doctrine:migrations:execute works predictably.
• You can version-control migrations alongside your code. Downside: You’ll need to manually review migrated files for bundle-specific logic. Worth it for cleaner diffs and fewer ‘works on my machine’ issues."*