Directory Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony 2.x Legacy: The bundle is tightly coupled to Symfony 2.1–2.3-dev, which is deprecated (EOL since 2017). Integration with modern Symfony (5.x/6.x) or Laravel would require major refactoring or a rewrite.
• Monolithic Design: Relies on SonataAdmin (legacy ORM-based admin) and KnpMenu (alpha-stage), increasing complexity. No clear separation of concerns (e.g., no API-first design).
• Laravel Incompatibility: Built for Symfony’s dependency injection (DI), templating (Twig), and bundles—Laravel uses service containers, Blade, and packages. Direct porting is non-trivial.
• Use Case Alignment: Fits directory/listing systems (e.g., producer databases, local business directories) but lacks modern features like graphQL, real-time updates, or headless CMS compatibility.

Integration Feasibility

• Symfony 2.x → Laravel Migration:
  • High effort: Requires rewriting core components (e.g., SonataAdmin → Laravel Nova/Backpack, KnpMenu → custom navigation).
  • Database Schema: Doctrine ORM entities would need conversion to Laravel Eloquent (migrations, relationships).
  • Frontend: Twig templates → Blade; JavaScript (if any) would need adaptation.
• Symfony 2.x → Symfony 6.x Upgrade:
  • Possible but risky: Symfony 6.x dropped backward compatibility; bundle would need major updates (e.g., Symfony UX, API Platform).
  • Dependency Hell: knp-menu:2.0.0-alpha1 and dev-master dependencies are unmaintained and may break.
• Feature Extraction:
  • Modular Approach: Could extract search/filter logic, category/location taxonomies, or user management (via ccetc/directory-user-bundle) into reusable Laravel components.
  • API Layer: Wrap existing functionality in a REST/gRPC API (e.g., using Laravel Sanctum or Lumen) for gradual adoption.

Technical Risk

Key Questions

1. Business Justification:
   • Why not use modern alternatives (e.g., Laravel Scout for search, Spatie Media Library for assets, or FilamentPHP for admin)?
   • Is the bundle’s legacy Symfony codebase a hard requirement, or can functionality be rebuilt?
2. Team Expertise:
   • Does the team have Symfony 2.x experience? If not, rewrite effort will be higher.
   • Is there capacity to maintain a fork of untested dependencies?
3. Scalability Needs:
   • Will the directory need real-time updates (WebSockets) or global scaling (queue workers)?
   • Are there third-party integrations (e.g., payment gateways, maps) that must be preserved?
4. Data Migration:
   • What’s the volume of existing data? Can it be incrementally migrated?
   • Are there custom business rules in the bundle that must be preserved?
5. Long-Term Viability:
   • Is the GPL-2.0 license acceptable for the project?
   • What’s the exit strategy if the bundle becomes unsustainable?

Integration Approach

Stack Fit

Migration Path

Option 1: Full Rewrite (Recommended)

1. Phase 1: Feature Extraction
   • Isolate core logic (e.g., directory listings, search, categories) into Laravel services.
   • Example: Convert Doctrine entities → Eloquent models; Symfony forms → Laravel Form Requests.
2. Phase 2: Admin Panel Replacement
   • Replace SonataAdmin with FilamentPHP or Backpack.
   • Migrate CRUD operations and custom fields.
3. Phase 3: Frontend Adaptation
   • Rewrite Twig templates to Blade.
   • Integrate with Laravel’s Blade components or Livewire for interactivity.
4. Phase 4: Dependency Replacement
   • Replace KnpMenu with a custom navigation system or package like laravel-menu.
   • Replace FOSUserBundle with Laravel Breeze.
5. Phase 5: Testing & Optimization
   • Write Pest/PHPUnit tests for extracted logic.
   • Profile and optimize queries (SonataAdmin often generates N+1 issues).

Option 2: Hybrid Approach (Symfony 2.x Microservice)

1. Containerize the Bundle:
   • Deploy Symfony 2.x as a Dockerized microservice (e.g., using symfony/symfony-docker).
   • Expose functionality via REST API (e.g., using FOSRestBundle).
2. Laravel as Frontend:
   • Use Laravel for authentication, UI, and modern features.
   • Call Symfony API via HTTP clients (Guzzle).
3. Gradual Migration:
   • Migrate one feature at a time (e.g., start with user management).
   • Deprecate Symfony service over time.

Option 3: Fork & Modernize (High Risk)

1. Upgrade Dependencies:
   • Update symfony/* to Symfony 5/6 (breaking changes likely).
   • Replace knp-menu:alpha with a stable version or alternative.
2. Convert to Symfony Bundle:
   • If staying in Symfony, refactor for Symfony 6.x (e.g., use Symfony UX).
3. Assessment:
   • Not recommended due to high maintenance burden and low community support.

Compatibility

• Database:
  • Doctrine schema can be exported to Laravel migrations (use doctrine/dbal tools).
  • Watch for unsupported Doctrine features (e.g., custom DQL, event listeners).
• Authentication:
  • FOSUserBundle → Laravel Sanctum/Passport for API auth.
  • Session auth → Laravel’s built-in auth.
• Assets:
  • Twig {% asset %} → Laravel mix-manifest.json or Vite.
  • CSS/JS bundles may need recompilation.

Sequencing

1. Discovery & Planning (2 weeks):
   • Audit bundle codebase; document dependencies.
   • Define MVP scope (e.g., "search + listings only").
2. Feature Extraction (4–6 weeks):
   • Isolate business logic from framework-specific code.
   • Write adapters for Laravel services.
3. Admin Panel Migration (3–4 weeks):
   • Set up FilamentPHP/Backpack; migrate models.
4. Frontend Rewrite (3–5 weeks):
   • Convert Twig to Blade; integrate with Laravel UI.
5. API/Integration Layer (2–3 weeks):
   • Expose extracted logic via Laravel API resources.
6. Testing & Deployment (2–4 weeks):
   • Write tests; perform data migration.
   • Deploy in stages (e.g., admin → frontend → features).