Brp Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony Flex Bundle Pattern: The package leverages Symfony’s Flex bundle architecture, which aligns well with modular, plugin-based Laravel/Symfony applications. While Laravel lacks native Symfony Flex support, the underlying principles (autoloading, dependency injection, and plugin hooks) are transferable via Laravel Packages or Symfony Bridge (e.g., symfony/console, symfony/dependency-injection).
• Entity Schema Installation: The commongateway:install command suggests Doctrine ORM schema management, which requires Laravel’s Eloquent or Doctrine Bridge (e.g., doctrine/dbal, doctrine/orm). This introduces database coupling and may require custom migrations or schema tools like Laravel Schema Builder wrappers.
• Plugin System: The bundle’s design implies dynamic plugin registration, which could be adapted in Laravel via:
  • Service Providers (registering bundle services in config/app.php).
  • Package Discovery (Laravel’s composer.json extra.packages or bootstrap/app.php hooks).
  • Event Listeners (e.g., Booted events for plugin initialization).

Integration Feasibility

• High for Symfony Apps: Near-zero effort if already using Symfony. Laravel requires abstraction layers (e.g., wrapping Symfony console commands, DI containers, or using Laravel Symfony Bridge packages like spatie/laravel-symfony-support).
• Key Dependencies:
  • Composer: Mandatory for installation (already standard in Laravel).
  • Doctrine ORM: Optional but requires Laravel’s Doctrine integration (e.g., laravel-doctrine/orm).
  • Symfony Console: For CLI commands (Laravel’s Artisan is compatible via symfony/console package).
• Laravel-Specific Gaps:
  • No native Symfony Flex recipe system (Laravel uses composer.json hooks or laravel/new).
  • Service Container differences (Laravel’s Container vs. Symfony’s ContainerInterface require adapters).

Technical Risk

Key Questions

1. Why Symfony Flex?

   • Is the goal to standardize plugin development across a polyglot stack (Symfony + Laravel), or is this a temporary prototype?
   • Could Laravel’s Package Development (docs) suffice without Symfony overhead?

2. Database Strategy

   • How will Doctrine schemas integrate with Laravel’s migrations? (Manual sync? Custom Migrator?)
   • Are there shared entities between Laravel and Symfony services?

3. CLI Workflow

   • Should Symfony commands (commongateway:install) be rewritten as Laravel Artisan commands?
   • Example: Convert bin/console commongateway:install → php artisan commongateway:install.

4. Plugin Lifecycle

   • How will plugins be discovered and loaded at runtime? (Composer autoload? Dynamic app/Plugins/ directory?)
   • Example: Laravel’s livewire/livewire uses composer.json hooks.

5. Testing & CI/CD

   • How will Symfony-specific tests (e.g., phpunit/symfony-bundle) integrate with Laravel’s testing stack?
   • Example: Use pestphp/pest with Symfony bridges or isolate tests.

Integration Approach

Stack Fit

Migration Path

1. Phase 1: Dependency Isolation

   • Install the bundle in a separate Symfony micro-service or Laravel Symfony Bridge project.
   • Use message queues (Laravel Horizon + Symfony Messenger) for cross-app communication.
   • Example: Deploy common-gateway/open-catalogi-bundle as a Symfony API consumed by Laravel via HTTP.

2. Phase 2: Hybrid Integration

   • Wrap Symfony Components:
     • Convert Command → Laravel Artisan command.
     • Abstract Doctrine models → Eloquent or repository pattern.
   • Plugin Discovery:

     // Example: Custom PackageServiceProvider
     public function register()
     {
         $this->app->singleton('plugin.manager', function () {
             return new PluginManager($this->app['path.base'], 'config/plugins.php');
         });
     }
     

   • Schema Sync:
     • Use laravel-doctrine/orm to share migrations or implement a schema diff tool.

3. Phase 3: Full Laravel Port

   • Fork the bundle and rewrite Symfony-specific logic:
     • Replace Symfony\Component\* with Laravel equivalents.
     • Use Laravel\Console\Command instead of Symfony\Component\Console\Command.
     • Replace Doctrine entities with Eloquent models.
   • Example: Symfony to Laravel Migration Guide.

Compatibility

• Composer: Fully compatible (Laravel uses Composer).
• PHP Version: Check composer.json for PHP 8.1+ support (Laravel 9+ requires PHP 8.0+).
• Symfony Components:
  • Compatible: console, dependency-injection, http-foundation.
  • Incompatible: framework-bundle, security-bundle (avoid unless necessary).
• Laravel-Specific Conflicts:
  • Service Container: Laravel’s Container extends Illuminate\Container\Container, not Symfony’s. Use adapters like symfony/dependency-injection.
  • Routing: Symfony’s routing component may conflict with Laravel’s Illuminate\Routing. Isolate or replace.

Sequencing

1. Assess Plugin Criticality:

   • Prioritize non-critical plugins for initial integration.
   • Example: Start with a read-only catalog plugin before writing to the database.

2. Dependency Graph:

   • Map bundle dependencies (e.g., doctrine/orm → laravel-doctrine/orm).
   • Use composer why to identify transitive dependencies.

3. Incremental Rollout:

   • Step 1: Install as a Composer dependency (dev environment).
   • Step 2: Mock Symfony services (e.g., Container stubs).
   • Step 3: Replace core components (e.g., Doctrine → Eloquent).
   • Step 4: Test plugin lifecycle (install/uninstall).

4. Fallback Plan:

   • If integration proves too complex, containerize the Symfony bundle and communicate via:
     • gRPC (for high-performance needs).
     • REST API (for simplicity).
     • Shared Database (with careful transaction management).

Operational Impact

Maintenance

• Pros:
  • Modularity: Plugins can be updated independently.
  • Composer Ecosystem: Leverages Packagist for dependency management.
• Cons:
  • Dual Stack Complexity: Maintaining both Laravel and Symfony codebases.
  • Dependency Drift: Symfony updates may require Laravel adapter changes.
• Mitigation:
  • Standardize: Enforce a plugin contract (e.g., interfaces for shared services).
  • Automate: Use GitHub Actions to test plugins in both stacks.
  • Document: Maintain a **