Core Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony2 Focus: The package is explicitly designed for Symfony2, not Laravel. While Laravel shares some PHP/Symfony ecosystem components (e.g., Doctrine, Twig), this bundle’s tight coupling with SonataAdminBundle (a Symfony2-specific admin generator) and Symfony2’s dependency injection (DI) container makes it a poor architectural fit for Laravel.
  • Key Limitation: SonataAdminBundle is not natively supported in Laravel (or Symfony 5/6/7). Porting would require significant refactoring.
• View-Model/Composite Settings: The core value proposition (YAML-driven admin configuration without PHP) aligns with Laravel’s blade templates and service container, but the implementation is Symfony2-centric (e.g., sonata_type_model, sonata_block_service).
• Laravel Alternatives: Consider native Laravel packages like:
  • Laravel Nova (for admin panels)
  • Backpack for Laravel (Sonata-like functionality)
  • FilamentPHP (modern admin builder)
  • Custom admin builders (e.g., using Spatie Laravel Permissions + Livewire/Tailwind).

Integration Feasibility

• Low Feasibility: Direct integration is not recommended due to:
  • Breaking Changes: Symfony2’s DI container (ContainerInterface) differs from Laravel’s (Container/ServiceProvider).
  • SonataAdmin Dependency: The bundle assumes SonataAdmin’s internals (e.g., sonata.admin.abstract, sonata.block.service).
  • PHP Version: Symfony2 requires PHP 5.3–7.1; Laravel 10+ requires PHP 8.1+.
• Workarounds:
  • Partial Feature Extraction: Manually replicate YAML-driven admin configurations using Laravel’s service providers and blade views.
  • Wrapper Layer: Build a thin adapter to translate SonataAdmin’s YAML logic into Laravel’s config files + Livewire/InertiaJS.
  • Fork & Rewrite: Rewrite core logic (e.g., composite settings) for Laravel’s ecosystem (e.g., using Laravel’s config/caching and service bindings).

Technical Risk

Key Questions

1. Business Justification:
   • Why adopt a Symfony2-specific bundle when Laravel has superior alternatives?
   • Is there a strategic need to support legacy Symfony2 codebases?
2. Migration Path:
   • Would a proof-of-concept (PoC) for a Laravel-compatible fork be viable?
   • What’s the cost vs. benefit of rewriting vs. using Filament/Nova?
3. Team Expertise:
   • Does the team have Symfony2/SonataAdmin experience to debug integration issues?
4. Long-Term Viability:
   • Is Libre Informatique actively maintained? (Low stars/dependents suggest risk.)
   • Are there alternative open-source projects (e.g., AdminLTE Laravel)?

Integration Approach

Stack Fit

• Incompatible Stack:
  • Symfony2 → Laravel 10+: DI containers, routing (symfony/routing), and event systems differ.
  • SonataAdminBundle → No Laravel equivalent: Requires replacement with Nova/Backpack/Filament.
• Partial Overlap:
  • Doctrine ORM: Compatible (Laravel uses Doctrine by default).
  • Twig: Laravel supports Twig via laravelcollective/html or tightenco/ziggy.
  • YAML Config: Laravel uses PHP arrays or JSON; YAML would require symfony/yaml (adds dependency).

Migration Path

1. Assessment Phase:
   • Audit current admin panel needs (CRUD, permissions, blocks).
   • Compare feature parity between Blast CoreBundle and FilamentPHP/Nova.
2. Option 1: Replace with Laravel-Native Tools (Recommended):
   • Step 1: Migrate to FilamentPHP (modern, actively maintained).
     • Example: Replace SonataAdmin’s Admin classes with Filament’s Resource.
   • Step 2: Port YAML configs to Filament’s PHP/config files.
   • Step 3: Use Laravel’s service providers for reusable admin logic.
3. Option 2: Fork & Adapt (High Risk):
   • Step 1: Fork the repository and update composer.json for PHP 8.1+.
   • Step 2: Replace Symfony2 DI with Laravel’s bind()/singleton().
   • Step 3: Abstract SonataAdmin calls (e.g., mock sonata.admin.registry).
   • Step 4: Test with a minimal Laravel app (e.g., laravel/new).
4. Option 3: Hybrid Approach:
   • Use Laravel’s API routes to proxy requests to a Symfony2 microservice (complex, anti-pattern).

Compatibility

Sequencing

1. Phase 1: Evaluation (2 weeks)
   • Benchmark FilamentPHP vs. Blast CoreBundle features.
   • Document gaps (e.g., "Blast supports X; Filament lacks Y").
2. Phase 2: Proof of Concept (3 weeks)
   • Implement a single admin panel in Filament.
   • Compare dev time vs. Blast CoreBundle.
3. Phase 3: Migration (4–8 weeks)
   • Incrementally replace SonataAdmin components.
   • Deprecate Blast CoreBundle in favor of Filament.
4. Phase 4: Optimization (Ongoing)
   • Refactor reusable logic into Laravel service containers.
   • Add testing for admin panel edge cases.

Operational Impact

Maintenance

• High Ongoing Cost:
  • Forking: Requires continuous syncing with upstream (if any) and PHP 8.1+ compatibility fixes.
  • No Community Support: 0 dependents + inactive repo = high risk of bitrot.
  • Laravel Ecosystem Drift: Symfony2 updates may break Laravel’s PHP 8.1+ runtime.
• Alternative (Filament): Actively maintained, Laravel-first, and community-driven.

Support

• No Vendor Support:
  • Libre Informatique’s lack of activity means no bug fixes or security patches.
  • Workaround: Engage with Symfony2/SonataAdmin communities (if applicable).
• Laravel-Specific Support:
  • FilamentPHP has Slack/Discord, GitHub issues, and paid support.
  • Backpack for Laravel has commercial support.

Scaling

• Performance:
  • Blast CoreBundle: Optimized for Symfony2’s OPcache; may underperform in Laravel.
  • FilamentPHP: Built for Laravel’s optimized service container and Blade caching.
• Team Scalability:
  • Symfony2 Knowledge: Rare in Laravel teams → higher onboarding cost.
  • FilamentPHP: Lower learning curve for Laravel devs.

Failure Modes