- How do I install Turbo Laravel in a Laravel app?
- Run composer require hotwired-laravel/turbo-laravel, then publish the package config with php artisan vendor:publish. Add @hotwired/turbo to your JavaScript entrypoint and import it through Vite; no other node build changes are needed. The service provider is registered automatically.
- Which Laravel and PHP versions does Turbo Laravel support?
- The package is aimed at Laravel 10/11-era Blade applications with Vite and modest JavaScript ambition, since the PHP side is thin sugar over Laravel responses and middleware. Always check the composer.json constraint matrix against your target Laravel and PHP versions before committing. Pin the version you validate, because the v1 to v2 transition carried breaking API changes.
- Is Turbo Laravel a replacement for Livewire or Inertia?
- No. It is server-rendered first and enhances the existing HTTP and Blade pipeline rather than introducing a parallel rendering model. It overlaps most with Livewire as a reactive UI choice and is deliberately redundant with Inertia, so treat it as an either/or decision per application rather than mixing all three in one codebase.
- Can I adopt Turbo Laravel incrementally instead of enabling Turbo Drive everywhere?
- Yes, and that is the recommended path. Start with a single form-heavy CRUD page using Turbo Frames, then add Turbo Stream responses for partial updates, then opt into Turbo Drive route by route. Turbo Drive can be scoped per element or route with data-turbo="false", so global Drive is a last step, not a first one.
- How do I return Turbo Stream responses from a Laravel controller?
- Use the Blade directives @turboStream and @turboStreams, or have controllers return Turbo Stream responses instead of JSON plus client-side hydration. A good practice is a thin response layer or helper trait that returns a turboStream for frame requests and a full view otherwise, using TurboMiddleware's frame detection. Always keep a plain-HTML fallback for non-Turbo requests.
- How does Turbo Laravel handle form validation errors?
- The package includes conventions for validation error handling so you can re-render the form with errors as a Turbo Stream, typically with a 422 status, instead of returning a JSON error payload. Keep the full-page fallback so non-Turbo requests still render errors correctly. This keeps controllers honest and avoids duplicating validation logic.
- How do I test Turbo Frames and Turbo Streams, and why do they fail silently?
- Unit tests will not catch the classic failure modes: frame target mismatches, redirects inside frames escaping to full page loads, and stale authenticated pages served from Turbo cache. Write feature tests that assert the turbo-frame request headers and stream responses, and verify behavior manually in a browser. Silent failures are the main technical risk with this package, not vendor risk.
- Do I need Laravel Echo or WebSockets for real-time updates with Turbo Streams?
- Turbo Streams over WebSockets are not provided by this package; you need Laravel Echo plus broadcasting glue on top. Decide explicitly whether real-time updates are in scope now or later. Without that glue, Turbo Streams still work fine for HTTP-driven partial updates.
- How do I deal with Turbo caching, logout, and stale authenticated pages?
- Turbo Drive caches pages, so plan session invalidation on logout and asset versioning deliberately. Verify that authenticated pages are not served stale after sign-out, and scope navigation with data-turbo="false" where caching is unsafe. These concerns are not caught by unit tests, so add manual checks and a rollback plan.
- Is Turbo Laravel actively maintained and safe for production?
- The release cadence is active, with the latest release dated 2026-02-28, but the project has roughly 840 stars and no formal vendor backing, so assume a single-maintainer risk profile. The v1 to v2 transition carried breaking API changes, and a v3 could land without a long deprecation runway. Pin versions and schedule upgrades deliberately.