Framework Installer Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony2/Sylius Alignment: The bundle is designed for Symfony2 (legacy) and leverages Sylius patterns, which may not align with modern Laravel/PHP ecosystems (Laravel 8+). Key mismatches:
  • Dependency Injection (DI): Symfony’s DI container vs. Laravel’s Service Container (Pimple-based).
  • Event System: Symfony’s EventDispatcher vs. Laravel’s Event System (illuminate/events).
  • Configuration: Symfony’s yaml/xml config vs. Laravel’s PHP/ENV-based config.
  • Database Abstraction: Doctrine ORM (Symfony) vs. Laravel’s Eloquent/Query Builder.
• Use Case Fit: Primarily targets installer workflows (e.g., Sylius setup wizards). Laravel alternatives (e.g., laravel-installer, laravel-breeze) may suffice unless Sylius-specific logic is required.
• Legacy Risk: Symfony2 is EOL (since 2023), and the bundle lacks active maintenance (0 stars, proprietary license flip in composer.json).

Integration Feasibility

• Laravel Compatibility: Low without heavy refactoring:
  • Core Dependencies: Requires Symfony components (e.g., symfony/dependency-injection, symfony/http-kernel), which conflict with Laravel’s autoloading.
  • Bundle Structure: Symfony Bundle classes (e.g., AvooInstallerBundle) won’t register in Laravel’s AppServiceProvider.
  • Database Migrations: Sylius/Doctrine migrations won’t integrate with Laravel’s migrations table.
• Workarounds:
  • Wrapper Layer: Create a Laravel facade to expose installer logic via Symfony’s Kernel (high effort).
  • Feature Extraction: Port specific installer components (e.g., CLI commands, config validators) to Laravel-compatible classes.
  • Docker/Sandbox: Run Symfony2 in a separate container (e.g., for legacy tooling).

Technical Risk

• License Inconsistency: composer.json claims proprietary license (contradicts MIT in README). Legal risk for commercial use.
• Maturity: No tests, no dependents, and no recent activity (last commit likely pre-2020).
• Breakage Risk:
  • Symfony2’s autoload-dev may conflict with Laravel’s composer dump-autoload.
  • PHP 5.3.3 requirement is obsolete (Laravel 8+ needs PHP 8.0+).
• Security: Unmaintained Symfony2 codebase may have unpatched CVEs.

Key Questions

1. Why Symfony2/Sylius?
   • Is the goal to replicate Sylius’s installer, or leverage specific Avoo logic?
   • Are there Laravel-native alternatives (e.g., spatie/laravel-installer)?
2. Migration Scope:
   • Which installer features are critical (e.g., CLI setup, DB seeding, config generation)?
   • Can these be rebuilt in Laravel (e.g., using laravel-artisan commands)?
3. Team Constraints:
   • Does the team have Symfony2 expertise to debug integration issues?
   • Is the effort justified vs. building a custom Laravel installer?
4. Long-Term Viability:
   • Will this bundle be maintained if Avoo shuts down?
   • Are there open-source alternatives (e.g., sylius/sylius-installer for Sylius)?

Integration Approach

Stack Fit

• Incompatible Stacks:
  • Symfony2 (legacy) vs. Laravel (modern).
  • Doctrine ORM vs. Eloquent.
  • Symfony Console vs. Laravel Artisan.
• Partial Overlap:
  • PHP 5.3.3 (bundle) vs. PHP 8.0+ (Laravel 8+): Requires polyfills or container isolation.
  • MIT License (README) vs. Proprietary (composer.json): Legal review needed.

Migration Path

Compatibility

• Symfony-Specific Components:
  • Event Listeners: Replace with Laravel’s Event::listen().
  • Services: Rewrite as Laravel Service Providers.
  • Commands: Convert Symfony\Component\Console\Command to Illuminate\Console\Command.
• Database:
  • Sylius migrations → Laravel migrations (manual rewrite).
  • Doctrine entities → Eloquent models (schema mapping required).
• Configuration:
  • config.yml → config/installer.php (ENV variables preferred).

Sequencing

1. Assessment Phase:
   • Audit bundle dependencies (composer why avoo/framework-installer-bundle).
   • Identify critical vs. non-critical features.
2. Prototype Phase:
   • Isolate 1–2 installer features (e.g., DB setup) and rewrite in Laravel.
   • Test in a parallel branch.
3. Integration Phase:
   • Gradually replace Symfony components with Laravel equivalents.
   • Use adapters (e.g., SymfonyKernelAdapter to bridge DI).
4. Deprecation Phase:
   • Phase out Symfony2 dependencies (e.g., via composer remove symfony/*).
   • Replace CLI entry points (e.g., php bin/console avoo:install → php artisan avoo:install).

Operational Impact

Maintenance

• Short-Term:
  • Debugging: High effort due to Symfony2/Laravel stack divergence.
  • Updates: Bundle updates may break Laravel’s autoloader.
• Long-Term:
  • Fork Required: Likely to fix Symfony2 dependencies.
  • Documentation: Nonexistent; team must reverse-engineer logic.
• Tooling:
  • IDE Support: Poor (Symfony2 plugins may not work in Laravel projects).
  • Testing: No PHPUnit tests; manual QA required.

Support

• Vendor Lock-in: Proprietary license (despite MIT claim) limits community support.
• Community: 0 stars/dependents → no external help available.
• Symfony2 Expertise: Rare in Laravel teams; may require hiring or training.
• Alternatives:
  • Sylius: Use sylius/sylius-installer (if Sylius is the goal).
  • Laravel: Use laravel-installer or custom Artisan commands.

Scaling

• Performance:
  • Symfony2 overhead may slow Laravel’s request lifecycle.
  • Shared autoloader (vendor/) could cause conflicts.
• Deployment:
  • Monolithic: Bundling Symfony2 increases Docker image size.
  • Microservice: Isolate installer in a separate service (e.g., via API).
• Team Scaling:
  • Cross-training needed for Symfony2/Laravel hybrid codebase.
  • Hiring challenges due to niche expertise.

Failure Modes

Ramp-Up

• Onboarding:
  • Symfony2: 2–4 weeks for team to learn (if unfamiliar).
  • Laravel-Symfony Hybrid: 4–8 weeks due to context switching.
• Documentation Gaps:
  • No CONTRIBUTING.md, no architecture decisions recorded.
  • Assume "undocumented features" exist.
• Training:
  • Focus on:
    • Symfony2 → Laravel DI mapping.
    • Sylius patterns (e.g., state machines, plugins).