- How do I install abr4xas/clarity-laravel in a Laravel application?
- Install it with Composer using composer require abr4xas/clarity-laravel. The package is a thin wrapper that only injects the Microsoft Clarity JavaScript snippet, so there are no migrations, service providers to register manually, or database tables involved. After installing, publish the config file and set your Clarity project ID, then confirm the script appears in your rendered layout.
- Where do I configure my Microsoft Clarity project ID?
- The package ships a publishable config file where you set your Clarity project ID, normally sourced from an environment variable so each environment can use a different project. Publish it with php artisan vendor:publish and select the clarity-laravel provider, then add the value to your .env file. Because v3.0.0 was a major refactor with sparse release notes, diff the published config against v2 before rolling it out to every environment in case keys or variable names were renamed.
- Which Laravel and PHP versions does clarity-laravel v3 support?
- The v3 line raised its testbench dependency from ^10.8 to ^11 and the release notes mention Laravel 13 maintenance, which signals a minimum-version floor increase. In practice that likely means applications on Laravel 10 or 11 are outside the supported matrix for v3, while Laravel 12 and 13 are the target. There is no published upgrade guide, so verify the composer.json constraints of the exact tag you install against your own framework version before upgrading.
- Is there a Blade directive for injecting the Clarity script?
- Yes. Besides automatic injection, the package exposes a Blade directive so you can render the Clarity snippet explicitly inside your layout's head section. This is useful when you only want tracking on certain views or when you want to control ordering relative to your own scripts. Check the README for the exact directive name in the version you install, since the v3 refactor may have changed it.
- Does clarity-laravel provide an artisan command?
- The package has historically shipped a ClarityCommand alongside the publishable config and the snippet injection. v3.0.0 refactored that command, so its class name, signature, options, and output or exit codes may have changed. If you invoke it from CI, deploy scripts, or scheduler entries, re-verify those call sites against the new version before switching.
- How do I disable Clarity tracking in local or testing environments?
- Because tracking is controlled entirely by config, you can leave the project ID empty or toggle injection off per environment, which keeps recordings out of local and test runs. This is the same mechanism teams use for consent gating: only render the snippet once a visitor has accepted analytics cookies. Confirm the current config keys after upgrading to v3, since renamed keys would silently stop the gating from working.
- What does the native buffering change in clarity-laravel v3 mean for my app?
- The v3 release title implies the Clarity payload is now buffered rather than injected inline during the request, which could change when the script reaches the browser. Watch for interactions with output buffering, streamed responses, and early-terminated requests, and test under Laravel Octane's long-lived workers specifically. This is the highest-uncertainty part of the release, so validate it on a short-lived branch before merging.
- How do I upgrade from v2 to v3 safely?
- Treat v3 as unproven until validated: pin ^2 on your main branch and stand up v3 on a separate branch. The migration is a verification exercise rather than a rewrite, so diff the published config file, diff the rendered HTML before and after, and run the artisan command in a scratch environment. If only emit timing changed, it is a same-day upgrade; if config keys moved, plan a config and env audit across every environment.
- Does clarity-laravel send any data server-side or affect performance?
- The package is a convenience wrapper around the client-side Clarity snippet, with no persistence, queue, or domain-model footprint, so it adds essentially no server-side cost. Data collection happens in the browser through Microsoft's script. Still, verify for v3 whether anything is transmitted server-side, and pair the package with your own consent layer if you have a strict third-party-script or CSP posture.
- Should I use this package or just paste the Clarity snippet into my Blade layout?
- The package saves you from hand-maintaining the snippet and gives you config-driven toggling plus a Blade directive, which is convenient for server-rendered Laravel apps. For API-only services, SPAs served outside Laravel, or teams that must wrap every third-party script in a consent layer, a small hand-rolled Blade partial is often the simpler and more durable choice. The integration is edge-of-lifecycle and cheap to replace either way, so adoption risk stays low.