Mousetracker Laravel Package

Technical Evaluation

Architecture Fit

• Symfony-Centric: The package is a Symfony bundle, not a standalone PHP library. While Laravel and Symfony share some foundational PHP patterns (e.g., Doctrine ORM, dependency injection), this package is not natively Laravel-compatible without significant abstraction or middleware layers.
• Event-Driven Model: The tracker relies on client-side JavaScript (vanilla JS, no jQuery) to capture events (mousemoves, clicks, scrolls) and batch them to Symfony endpoints. This is not a Laravel-specific concern but requires a Laravel-compatible frontend integration.
• Database Schema: The package introduces three tables (tracker__client, tracker__page, tracker__data) via Doctrine migrations. Laravel’s Eloquent and migrations would need to be mapped to these tables, which could introduce schema drift if not carefully managed.
• Backend UI: Includes a Symfony Twig-based replay UI under /tracker/back/, which would need to be replaced or adapted for Laravel’s Blade templating system.

Integration Feasibility

• Frontend Integration:
  • The JavaScript tracker (tracker.js) must be injected into Laravel Blade templates (e.g., via @stack('scripts') or a service provider).
  • The mouse_tracker_service.build() Twig function would need a Laravel equivalent (e.g., a Blade directive or helper).
• Backend API:
  • The /tracker/createClient and /tracker/addData endpoints must be exposed as Laravel routes (e.g., via Route::post('/tracker/createClient', ...)).
  • The Doctrine entities (Client, Page, Data) would need to be ported to Laravel Eloquent models.
• Configuration:
  • Symfony’s mouse_tracker: YAML config would need to be mapped to Laravel’s config/mouse_tracker.php.
  • The UST.settings JavaScript configuration would need to be exposed via Laravel’s asset pipeline (e.g., via a data-tracker-config attribute).

Technical Risk

Key Questions

1. Is this a "must-have" feature, or can we use a Laravel-native alternative (e.g., Laravel Analytics, Hotjar API, or Plausible)?
2. How will we handle the Symfony-Laravel integration gap? Options:
   • Option A: Build a Laravel wrapper around the Symfony bundle (e.g., via a custom MouseTrackerServiceProvider).
   • Option B: Fork the package and rewrite Symfony-specific code for Laravel.
   • Option C: Abandon this package and build a lightweight Laravel-native tracker (e.g., using Laravel Echo for real-time events).
3. What is the data retention policy? The package stores raw DOM snapshots and form values, which may include PII. How will we anonymize or purge this data?
4. How will we test the integration?
   • Unit tests for the Laravel service layer.
   • End-to-end tests for the /tracker API endpoints.
   • Manual verification of the replay UI (if adapted for Blade).
5. What is the upgrade path? The package is actively maintained (last release: 2026-05-23), but breaking changes (e.g., v2.0) may require significant refactoring.

Integration Approach

Stack Fit

Migration Path

1. Phase 1: Proof of Concept (2-3 weeks)

   • Fork the repository and replace Symfony-specific code (e.g., AbstractController, #[Route]) with Laravel equivalents.
   • Create Laravel Eloquent models for Client, Page, and Data.
   • Implement Doctrine migration alternatives (e.g., Laravel Schema Builder or raw SQL).
   • Test the /tracker/createClient and /tracker/addData endpoints with a mock frontend.

2. Phase 2: Frontend Integration (1 week)

   • Publish tracker.js to Laravel’s public/js/ directory.
   • Create a Blade directive (e.g., @mouseTracker) to replace {{ mouse_tracker_service.build() }}.
   • Inject the tracker script before </body> in Laravel’s app.blade.php.

3. Phase 3: Backend UI Adaptation (2 weeks)

   • Replace Twig templates in /tracker/back/ with Blade equivalents.
   • Adapt the replay UI JavaScript (if needed) to work with Laravel’s asset pipeline.
   • Implement Laravel middleware to secure /tracker/back/*.

4. Phase 4: GDPR & Compliance (1 week)

   • Add a consent banner (e.g., using Laravel Cookie Consent).
   • Implement data anonymization for PII in recordings.
   • Add IP filtering via Laravel’s Request object.

5. Phase 5: Testing & Optimization (2 weeks)

   • Write Pest/PHPUnit tests for the Laravel service layer.
   • Test performance under load (e.g., 1000+ concurrent recordings).
   • Optimize database indexing for the tracker__data table.

Compatibility

Sequencing

1