- How do I install mauricius/laravel-htmx?
- Install it with Composer by running composer require mauricius/laravel-htmx. The package supports Laravel auto-discovery, so the service provider is registered automatically and no manual wiring is required. If you need to customize behavior, you can optionally publish the config file and register the middleware in your HTTP kernel or bootstrap file. There is no database migration, queue, or external service involved.
- Which Laravel and PHP versions does laravel-htmx support?
- The package tracks Laravel's annual major releases, and v0.10.0 is specifically a framework compatibility release that raises the supported Laravel version. Because it is a pre-1.0 package, the exact floor can shift between minor versions, so check the composer.json constraints for the tag you intend to install rather than assuming. Confirm the minimum PHP version at the same time, since Laravel 13 support likely raises both floors. If you are on an older LTS such as Laravel 10 or 11, verify compatibility explicitly before upgrading the package.
- How do I detect an HTMX request in Laravel with this package?
- The package ships HTMX-aware middleware plus helpers that inspect the HX-Request header so you can branch between full-page and partial responses. That lets a single controller return a complete Blade view for normal navigation and a fragment for boosted or AJAX-style requests. Detection is handled at the edge of the request lifecycle, so your controllers and models stay unaware of HTMX specifics. You can also use the same signal for redirect handling, since HTMX expects different redirect semantics than a browser.
- How do I set HX-* response headers in Laravel?
- It provides a fluent response builder for emitting HX-* headers such as HX-Redirect, HX-Trigger, HX-Reswap, and HX-Push-Url without hand-writing header arrays in every controller. You chain the desired header onto the response and return it as usual, which keeps header logic readable and consistent across the app. For one-off cases you can always fall back to the standard Laravel response header methods. This is the main reason to adopt the package rather than scattering header strings through controllers.
- What Blade directives does mauricius/laravel-htmx provide?
- The Blade directives emit hx-* attributes, so you can declare HTMX behavior in your templates instead of writing raw attributes by hand. They cover the common attribute set used for GET/POST requests, targeting, swapping, and triggering. Because they compile into plain attributes, the rendered markup is standard HTMX and works with any HTMX version that supports those attributes. Remember that compiled Blade views are cached, so run php artisan view:clear after upgrading the package if markup looks stale.
- Does laravel-htmx support Laravel validation errors with HTMX?
- The package includes validation support so error responses can be returned as partial fragments that HTMX swaps into the page rather than triggering a full-page 422. This lets you render the same Blade error partial you already use for standard form submissions. The exact helper names and behavior can change between 0.x minors, so check the source for your pinned version. Pair it with a documented pattern in your app so error handling stays consistent across forms.
- How does laravel-htmx handle redirects for HTMX requests?
- HTMX follows redirects differently from a browser, so the package's middleware normalizes redirect behavior and can return the appropriate HX-Redirect header instead. Without this, a redirect from a controller can result in HTMX swapping the redirected page into the target element instead of navigating. The middleware resolves that at the request layer, which keeps controllers free of HTMX-specific branching. Verify the behavior on your target version with an end-to-end smoke test, since redirect semantics are easy to get subtly wrong.
- Is laravel-htmx a good alternative to Livewire?
- They solve overlapping problems with different mental models: this package is a thin convenience layer over HTMX and Blade, while Livewire is a full component framework with its own state and lifecycle. It is a good fit for Laravel monoliths and server-rendered Blade apps that want partial-page updates with minimal custom JavaScript. It is a poor fit if your team is already committed to Livewire, Inertia, or a React/Vue SPA, because mixing paradigms fragments the codebase. Pick one approach per feature area rather than combining them.
- Is it safe to use a pre-1.0 package like laravel-htmx in production?
- The risk profile is favorable because the package is a thin layer at the edge of the architecture: it does not own the request lifecycle, the view layer, or any state, so the worst case is removing it and hand-writing hx-* attributes and HX-* headers. That is hours of work, not sprints. The real risks are versioning and bus factor, since 0.x semver allows breaking changes in minor releases and the project is effectively one maintainer plus Laravel Shift automation. Pin the minor version, route dependency bumps to manual review, and keep hand-written attributes as a documented fallback so no feature is blocked on the package.
- How do I upgrade mauricius/laravel-htmx from 0.9.0 to 0.10.0?
- The v0.10.0 changelog lists framework compatibility updates rather than feature or API changes, so it should be a Composer constraint bump. Verify that assumption instead of trusting it: diff the composer.json constraints between tags and check src/ for changed public method signatures or Blade directive names. Run php artisan view:clear afterward, because stale compiled directives are a common source of confusing old-markup symptoms. Sequence the package upgrade and the Laravel upgrade together rather than treating them as independent tickets.