Weave Code
Ux Inspector Laravel Package
symfony/ux-inspector
Symfony UX Inspector provides a developer-friendly toolbar and panel for inspecting Symfony UX components, Stimulus controllers, Twig components, and live frontend interactions, making it easier to debug behavior and templates during development.
Browser inspector for Symfony UX components: Stimulus, LiveComponent and Turbo
Frequently asked questions about Ux Inspector
- Is symfony/ux-inspector a Laravel package?
- No. It is a Symfony UX package that ships a browser-side inspector overlay for Twig components, LiveComponents, Stimulus controllers and Turbo interactions. It depends on Symfony UX primitives and Symfony's asset tooling, which have no direct Laravel counterpart. Laravel's equivalents are Blade, Livewire and Vite, so the inspector will not surface anything useful in a standard Laravel app.
- What exactly does symfony/ux-inspector let me debug?
- It adds a developer toolbar and panel in the browser that shows Symfony UX component state, including Twig component props, LiveComponent wiring, and Stimulus controller and Turbo activity. The goal is to make it easier to see why a frontend interaction or template behaves the way it does without sprinkling dump calls everywhere. It is purely a development aid and adds no runtime business capability.
- How do I install symfony/ux-inspector with Composer?
- Add it as a dev dependency with composer require --dev symfony/ux-inspector, then register the bundle only in your dev and test environments. You also need to make sure your asset pipeline emits the inspector's JS and CSS payload during development. Because it is tooling rather than application code, it should never be a production requirement.
- Does it work in a Laravel application with Livewire?
- No. Livewire and Blade are architecturally distinct from Symfony UX, Twig components and AssetMapper, so the inspector has nothing to hook into. The only realistic paths are a hybrid or legacy Symfony service inside a Laravel estate, or a Laravel package that has deliberately adopted Symfony UX components. For a Laravel-first codebase the answer is simply not to adopt it.
- How do I keep the inspector out of production builds?
- Put the package in require-dev, register the bundle only for the dev environment, and confirm your asset compilation omits the inspector payload in production. A practical safeguard is a CI assertion that fails if the inspector asset appears in a production build. This matters because the overlay is a browser asset and would otherwise ship to end users.
- Which asset pipeline does symfony/ux-inspector require?
- It expects Symfony's asset flow, typically AssetMapper or Webpack Encore, to deliver its JavaScript and CSS payload. That coupling is one of the real integration constraints: if your project uses Vite or another pipeline, you will need an equivalent wiring path before the panel renders. It is not a drop-in asset for arbitrary frontend build setups.
- Which Symfony and PHP versions are supported?
- The v3.6.0 changelog does not state framework or PHP constraints, so check the composer.json requirements against your pinned versions before adopting. v3.6.0 is a minor release on the 3.x line with no declared deprecations or breaking changes and is intended to stay compatible with v3.5.x consumers by SemVer. Verify explicitly rather than assuming, since minor releases on the UX monorepo train ship frequently.
- Is symfony/ux-inspector stable and actively maintained?
- It is maintained as part of the Symfony UX monorepo release train, and v3.6.0 introduced the browser inspector itself, so it is a genuinely new capability rather than a long-settled one. A follow-up fix for panel repositioning shows the overlay UI is still maturing in layout behaviour. Treat it as evolving dev tooling and expect regular minor releases with housekeeping churn.
- Should it go in require or require-dev?
- Always require-dev. The package is developer experience tooling, not an application dependency, and it has no role in your production request and response path. Scoping it to dev also limits blast radius and avoids leaking the overlay into shipped assets. Rollback is a single dependency removal with no data or schema implications.
- What are the alternatives to symfony/ux-inspector for debugging frontend components?
- For Symfony projects, the Symfony profiler, VarDumper and the standard browser DevTools cover a lot of the same ground, and dedicated frontend devtools extensions help for framework-specific inspection. In Laravel, the usual picks are Laravel Debugbar, Livewire's own debugging output and browser DevTools. If you are not running Symfony UX components, one of those is almost certainly the better fit.
Weaver
How can I help you explore Laravel packages today?