Ux Inspector Laravel Package

Getting Started

symfony/ux-inspector is a Symfony UX bundle, not a Laravel package — there is no service provider, no config/ publish tag, and nothing to wire into AppServiceProvider. If you are working in a Laravel codebase this package is not applicable; if you maintain a Symfony app alongside Laravel services (or are evaluating it for a Symfony frontend), it belongs in the dev toolchain.

Minimal steps:

composer require --dev symfony/ux-inspector

With Symfony Flex the recipe registers the bundle in config/bundles.php and the asset is exposed automatically. Without Flex, add it manually:

// config/bundles.php
Symfony\UX\Inspector\UxInspectorBundle::class => ['dev' => true, 'test' => true],

Where to look first:

1. config/bundles.php — confirm the bundle is scoped to dev/test only.
2. The rendered page itself — the inspector surfaces as a browser overlay/panel, so the fastest validation is loading any page that uses a UX package (Stimulus controller, Turbo frame, Live Component).
3. bin/console debug:container --tag=… / debug:event-dispatcher if you need to confirm it booted.

First use case: open a page with a Stimulus controller attached, open the inspector panel, and confirm the controller, its element, and its values/state are visible. That alone replaces a lot of console.log round-trips when debugging UX wiring.

Implementation Patterns

Dev-only by construction. Install with --dev and never let the bundle be enabled in prod. The overlay ships JS; even a few KB of debug tooling in production is a smell, and the panel can expose internal component state. Verify with composer install --no-dev --optimize-autoloader in a staging build that the asset is absent.

Pair it with the profiler, not instead of it. symfony/web-profiler-bundle answers "what happened during the request"; the UX inspector answers "what is live in the DOM right now". Use the profiler for the data collector view and the inspector for client-side controller/component state.

Adopt it as the default debugging loop for UX work. Typical workflow when a Live Component or Turbo frame misbehaves:

1. Open the inspector, confirm the controller is actually attached and instantiated.
2. Compare the values the controller sees against what the template rendered.
3. Only then reach for console.log or the profiler.

Asset pipeline awareness. If you use AssetMapper, the bundle's assets land under assets/vendor/; if you use Webpack Encore, they come through the bundle's package. Either way, after install run bin/console cache:clear and, for AssetMapper, bin/console asset-map:compile in build environments. In dev the assets are served dynamically, so no compile step is needed locally.

Version-lock the whole UX family. Keep every symfony/ux-* package on the same minor. The inspector reads component metadata produced by sibling UX packages; a 3.6 inspector against a 3.4 Live Components install is an unsupported combination and produces confusing empty panels rather than a clean error.

Gate it behind a role in shared dev environments. If you run a shared staging/dev box that non-developers can reach, add whatever access control your app uses (security.access_control on the profiler/inspector routes) so the overlay is not visible to stakeholders.

Gotchas and Tips

• The overlay z-index fight. The panel is positioned in the viewport, and it is the thing that was fixed in 3.6.0 (#4064 — reposition overlays when the panel opens or closes). If you pinned 3.5.x you will see the panel drift out of place after toggling; upgrade rather than CSS-patching it. If your own modals sit at a very high z-index, expect the inspector to render underneath them.
• This is 3.6.0's headline feature, so treat it as young. The inspector itself was introduced in this release (#3866). The API surface for extending it is not yet battle-tested — if you build custom panels, pin the version and re-read the changelog on every bump.
• Empty panel is almost always a missing recipe. The most common failure mode is the bundle booting but the JS never being injected because Flex did not run the recipe. Check config/bundles.php and that the asset is present in the rendered HTML before debugging anything else.
• Do not add it to require in a package you redistribute. A library that pulls in a debug overlay as a hard dependency will surprise downstream apps. require-dev only.
• CI cost. The bundle is harmless in test, but if you build assets in CI make sure the inspector asset is not included in the production manifest — diff public/build/manifest.json between an environment with and without the package the first time you enable it.
• Symfony-only. There is no Laravel equivalent here — no Debugbar bridge, no config/ux-inspector.php to publish. If a teammate asks "where does this go in Laravel", the answer is "it doesn't"; use Laravel Debugbar plus Vue/React devtools for the equivalent workflow.
• Debugging a silently dead inspector: bin/console debug:container UxInspector to confirm the service exists, then check the browser network tab for a 404 on the bundle's asset. A 404 after a deploy is nearly always a stale asset manifest — cache:clear and recompile.