- Is mvrhov/phinx-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle. The package ships a Bundle class, a dependency-injection extension, compiler passes, and console commands wired into Symfony's FrameworkBundle, and it never touches Laravel's service providers, facades, or Artisan. Laravel integration is not part of its design, so treating it as a Laravel package leads to a mis-scoped dependency.
- Can I install mvrhov/phinx-bundle in a Laravel application?
- Composer may allow it, but it is a poor architectural fit. You would pull symfony/framework-bundle, symfony/dependency-injection, symfony/http-kernel, and symfony/console in as first-class runtime dependencies and bootstrap a kernel just to register migration commands, while Laravel already provides schema migrations natively. It is only defensible if the host application is legacy Symfony 2.8 or 3.4 on PHP 7.x.
- Which PHP, Symfony, and Phinx versions does mvrhov/phinx-bundle support?
- The last release was 2017-12-28, so its constraints almost certainly target robmorgan/phinx around 0.6 to 0.8, Symfony 2.8 or 3.x, and PHP 5.6 or 7.0. Modern Phinx, now cakephp/phinx 0.16.x, reorganized classes, changed the AbstractMigration contract, and requires PHP 7.4 or newer. Check the exact composer.json pins before any commitment, because pinning Phinx below 0.9 makes the bundle effectively a museum piece.
- How do I install and register mvrhov/phinx-bundle with Composer?
- Install it with composer require mvrhov/phinx-bundle and, in a Symfony app, register the bundle in AppKernel or bundles.php so the DI extension loads. You then supply Phinx configuration through the Symfony config tree and parameters instead of a standalone phinx.yml. There is no Laravel equivalent: no package discovery, no service provider, and no config/database.php integration.
- What console commands does the bundle add for running migrations?
- It exposes Phinx migrate, rollback, status, and seed as Symfony console commands, so they run through bin/console rather than an Artisan entry point. These commands are thin wrappers around the upstream Phinx manager, which the bundle exposes as a DI service. In a Laravel app you would be invoking Symfony console, not artisan, which is a real maintenance and documentation mismatch.
- How is Phinx configured inside the Symfony service container?
- Configuration is loaded from Symfony parameters and service definitions, and the bundle supports multiple database connections plus environment-specific settings. That means adapters, migration paths, and seeds are declared in YAML or PHP config processed by the DI extension. Laravel's equivalent lives in config/database.php and the migrations directory, so adopting this bundle means maintaining two parallel configuration systems.
- Does mvrhov/phinx-bundle work with modern Phinx or cakephp/phinx releases?
- Almost certainly not without patching. Phinx moved classes and changed the AbstractMigration contract, including reversible change() inference and up()/down() semantics, after the bundle's last 2017 release. Composer will either refuse to resolve or pin you to a Phinx version from the same era, which also rules out PHP 8.x.
- Is mvrhov/phinx-bundle still maintained, and what is the production risk?
- It has roughly six stars, zero dependents, and no release since December 2017, which predates PHP 7.4, PHP 8.0, Symfony 5 and 6, and Phinx's own namespace migration. Zero dependents means no downstream production evidence and no issue corpus to search when something breaks. The MIT license is the one clear positive: you can vendor, fork, and patch without legal friction, but you would become the maintainer of record for security fixes in the pinned Phinx and Symfony versions.
- What Laravel-native alternatives replace Phinx for schema migrations and seeding?
- Laravel's own illuminate/database migrations handle schema versioning, rollback, and seeding through artisan migrate, migrate:rollback, migrate:status, and db:seed. They are PHP class based, version-controlled alongside your code, and supported by the framework you already run. If you must preserve an existing corpus of Phinx migrations, running standalone Phinx as a CLI tool is cleaner than dragging a Symfony bundle into Laravel.
- How should I test a Phinx migration workflow before committing to this bundle?
- Start with a spike: run composer require in a throwaway branch, check whether constraints resolve against your PHP version, then boot the Symfony kernel and run migrate, rollback, and status against a scratch database. Capture PHP 8.x deprecations and fatals from the bundle's Symfony 3-era code paths, since dynamic properties and nullable parameter ordering will surface. Only commit if the requirement is genuinely a legacy Symfony host or an existing Phinx migration corpus you cannot rewrite.