Ux Inspector Laravel Package

Technical Evaluation

Architecture fit. symfony/ux-inspector is a Symfony UX package, not a Laravel package — the first thing a TPM must flag. It ships a browser-side inspector (dev tooling overlay) that surfaces Symfony UX component state (Twig components, LiveComponents, Turbo/Stimulus wiring) in the browser. Architecturally it is a development-time asset: a PHP bundle registering a toolbar-like panel plus a JS/CSS asset payload delivered through Symfony's AssetMapper/Webpack Encore pipeline. It does not sit in the request/response hot path of production code, which keeps blast radius low, but it also means it delivers zero runtime business capability — its value is engineering velocity and debuggability.

Integration feasibility. In a pure Laravel application, integration is not feasible without adopting Symfony UX primitives (Twig components, Stimulus controllers, AssetMapper). Laravel's equivalents (Blade, Livewire, Vite) are architecturally distinct. Realistic adoption paths are: (a) a hybrid/legacy Symfony service inside a Laravel estate where Symfony UX is already in use, (b) a Laravel package that has deliberately adopted Symfony UX components, or (c) not at all. The v3.6.0 feature — "Add a browser inspector for Symfony UX" (#3866) — is a genuinely new capability and the headline of this release, so evaluating it now is warranted even absent a prior assessment.

Technical risk. Low-to-moderate. Risks: dev-dependency leakage into production builds (inspector overlay shipping to end users), asset-pipeline coupling requiring AssetMapper or an Encore-equivalent, and version-lock coupling to the Symfony UX monorepo release train (v3.6.0 also bumps tooling deps and drops an unused version field from package.json, signalling the usual monorepo housekeeping churn). The overlay repositioning fix (#4064) confirms the panel is still maturing in layout behaviour — cosmetic, but a signal that v3.x UI is not fully settled.

Key questions. Which of our services actually use Symfony UX today? Is this package being proposed for a Symfony service or mistakenly scoped as Laravel? Can the inspector be excluded from production asset compilation by default? What is the upgrade cadence for the UX monorepo, and does our Composer constraint strategy tolerate the frequent minor releases? Who owns the dev-tooling budget for it?

Integration Approach

Stack fit. Poor-to-conditional for a Laravel-first estate; strong for a Symfony-first estate. This should be classified as a developer-experience dependency, not an application dependency. Recommend scoping it to require-dev only, and only in repositories that already consume symfony/ux-* components.

Migration path. None required — this is additive dev tooling, not a migration. Enablement is: add as dev dependency → register the bundle in the dev/test environment only → ensure asset pipeline emits the inspector payload in dev and omits it in prod → validate the overlay in a representative page using UX components. Rollback is a single dependency removal with no data or schema implications.

Compatibility. v3.6.0 is a minor release on the 3.x line with no deprecations or breaking changes declared; the changelog is three minor housekeeping PRs plus one feature and one bug fix. It is compatible with existing v3.5.x consumers by SemVer intent. Verify PHP and Symfony framework constraints against our pinned versions before adopting, since the changelog does not state them.

Sequencing.

1. Confirm whether any in-scope service uses Symfony UX (go/no-go gate — likely no for Laravel services).
2. If yes: pin ^3.6 in require-dev, register bundle for dev env only.
3. Add a CI assertion that the inspector asset is absentfrom production builds.
4. Pilot on one internal/staging service; gather developer feedback on the new browser inspector over one sprint.
5. Decide on ongoing adoption based on measured debugging-time savings; otherwise hold at current version and do not track the release train.

Operational Impact

Maintenance. Near-zero if confined to require-dev. The real cost is version-tracking: the UX monorepo ships frequent minors, and adopting it means periodic dependency bumps and occasional asset-pipeline adjustments. Budget a low, recurring housekeeping line rather than a project.

Support. No vendor SLA; community-supported open source under the Symfony organisation. Internal support burden is essentially "the developer who set it up." If the team is Laravel-centric, expect a knowledge gap in Symfony UX troubleshooting — this is the dominant support risk.

Scaling. Irrelevant in the traditional sense — the inspector is not deployed to production traffic and does not scale with user load. The scaling concern is team scaling: value increases with the number of developers working on Symfony UX components, and is close to zero for a small Laravel team.

Failure modes.

• Inspector assets leak into production bundles, exposing internals and adding payload weight.
• Asset pipeline incompatibility (Vite/Encore vs. AssetMapper expectations) causing build failures.
• Version conflict with existing Symfony/Symfony UX constraints during Composer resolution.
• Overlay rendering defects (the class of issue #4064 addressed) degrading rather than aiding the debugging experience.
• Adoption for the wrong framework, resulting in dead dependencies and maintenance noise.

Ramp-up. Low for a Symfony UX team — install, load a page, use the panel. High for a Laravel-only team: understanding the package meaningfully requires familiarity with Twig components, Stimulus and AssetMapper, which is a multi-week learning curve for a capability that duplicates what Laravel's own tooling (Telescope, Debugbar, Vite dev server) already provides.

Recommendation. Treat v3.6.0 as a notable release because it introduces the browser inspector, and log it as evaluated. Do not adopt in Laravel-primary services. For any Symfony UX service in the estate, trial as a require-dev dependency in staging and reassess after one sprint of developer feedback.