Mtt Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Specialized Use Case: The canaltp/mtt-bundle is a niche Laravel bundle designed for public transportation timetable generation (PDF/CSV exports, calendar management, and stop-point displays). It aligns well with systems requiring structured timetable visualization (e.g., bus/tram schedules, stop signage, or digital displays).
• Modularity: The bundle integrates with Symfony/Twig for templating, Doctrine for ORM, and Guzzle/AMQP for external services, suggesting a loosely coupled design. However, its tight integration with canaltp/sam-* bundles (e.g., sam-monitoring-bundle) may limit flexibility in non-CanalTP ecosystems.
• Output Formats: Supports PDF (A3/A4/A5), CSV, and PNG, making it suitable for print/physical media (e.g., bus stop signs) or digital dashboards.
• Legacy Dependencies: Relies on Twig 1.x (deprecated in favor of Twig 2/3), PHP-AMQPLib (abandoned), and Symfony 3.x/4.x patterns, which may introduce maintenance overhead in modern Laravel (v10+) stacks.

Integration Feasibility

• Laravel Compatibility:
  • Symfony Bridge: Laravel’s Symfony integration (via symfony/http-foundation, symfony/routing) allows partial adoption, but Doctrine ORM (used heavily) requires laravel-doctrine/orm or manual shimming.
  • Service Container: The bundle uses Symfony’s DependencyInjection (DI), which can be mapped to Laravel’s container via Symfony\DependencyInjection facade or a custom bridge.
  • Routing: Custom routes (e.g., /timetable/export) may conflict with Laravel’s router; prefixing or middleware isolation will be needed.
• Database Schema:
  • Assumes Doctrine entities (e.g., Calendar, StopPoint, Network). Migrating to Laravel’s Eloquent would require schema mapping or a dual-layer abstraction.
  • Cascade deletes (e.g., ON DELETE CASCADE) may need adjustment for Laravel’s migrations.
• Frontend:
  • Twig templates can be converted to Blade or used via twig/laravel bridge, but CSS/JS dependencies (e.g., GTM, jQuery) may need modernization.
  • PDF generation (via dompdf/wkhtmltopdf) is likely compatible, but A3/A4/A5 support may require custom CSS tweaks.

Technical Risk

Key Questions

1. Why Laravel?
   • Is the bundle being adopted for new development or legacy migration? If the latter, assess rewrite vs. wrapper costs.
2. Output Requirements
   • Are A3/A4/A5 PDFs strictly required, or can modern tools (e.g., barryvdh/laravel-dompdf) suffice?
3. Real-Time Needs
   • Does the system require AMQP-based eventing (e.g., real-time timetable updates)? If not, this dependency can be dropped.
4. UI/UX Modernization
   • Will the admin interface (Twig-based) be retained, or replaced with Laravel’s Livewire/Inertia?
5. Scaling Assumptions
   • The bundle assumes monolithic Symfony/Laravel deployment; how does it fit with microservices or headless APIs?

Integration Approach

Stack Fit

• Core Laravel Compatibility:

  • Recommended Stack:
    • PHP 8.1+ (for modern Twig/PHP-AMQPLib alternatives).
    • Laravel 9/10 (Symfony 6.x compatibility).
    • Doctrine ORM (via laravel-doctrine/orm) or Eloquent with mapped entities.
    • Twig 3.x (via twig/laravel bridge).
    • PDF: barryvdh/laravel-dompdf (replaces bundle’s PDF logic).
    • Queue: laravel-queue (replaces AMQP; use sync driver for simplicity).
  • Avoid:
    • Direct Symfony kernel integration (use Laravel’s middleware instead of Symfony’s HttpKernel).
    • supervisord (replaced with Laravel’s queue workers).

• Alternatives:

  • If timetable generation is the only need, consider standalone tools (e.g., spatie/laravel-pdf, custom CSV exporters) to avoid bundle bloat.

Migration Path

1. Assessment Phase:
   • Audit all bundle dependencies (e.g., canaltp/sam-monitoring-bundle) for Laravel compatibility.
   • Prototype a minimal feature (e.g., CSV export) to validate integration effort.
2. Dependency Replacement:
   • Replace twig/1.x → twig/3.x + twig/laravel.
   • Replace php-amqplib → php-enqueue/amqp-ext or Laravel queues.
   • Replace Symfony DI → Laravel service providers or symfony/dependency-injection facade.
3. Database Layer:
   • Option A: Doctrine ORM (install laravel-doctrine/orm).
   • Option B: Eloquent Mapping (write adapters for Calendar, StopPoint entities).
4. Frontend:
   • Convert Twig templates to Blade or use twig/laravel for hybrid rendering.
   • Replace jQuery/GTM with Alpine.js or Laravel Mix.
5. PDF/CSV Logic:
   • Extract core logic (e.g., timetable data structuring) into Laravel services.
   • Use dompdf for PDFs and Laravel’s excel for CSVs.

Compatibility

Sequencing

1. Phase 1: Core Logic Extraction (2–4 weeks)
   • Isolate timetable data models and generation logic from Symfony dependencies.
   • Replace PDF/CSV generation with Laravel-native tools.
2. Phase 2: UI/UX Layer (3–5 weeks)
   • Migrate Twig templates to Blade or hybrid Twig.
   • Modernize frontend dependencies (e.g., drop GTM, replace jQuery).
3. Phase 3: Integration Testing (2–3 weeks)
   • Validate Doctrine/Eloquent compatibility.
   • Test edge cases (e.g., A3 PDF rendering, CSV delimiters).
4. Phase 4: Deployment (1–2 weeks)
   • Containerize with Docker (if using Symfony/Laravel hybrid).
   • Set up Laravel’s queue workers (replace supervisord).

Operational Impact

Maintenance

• **