Ux Vue Laravel Package

Technical Evaluation

What actually shipped in v3.6.0. This is symfony/ux-vue, the Symfony UX integration layer for Vue 3 (component registration, Twig-rendered Vue components, SSR hooks, and AssetMapper/importmap wiring). Three changes: a tooling-dependency refresh (#4086), a Composer conflict rule with symfony/asset-mapper >= 8.2 (#3919), and a README placeholder fix (#3907). No public API changes, no deprecations, no breaking changes. Release risk is negligible; it is a patch-level maintenance bump wearing a minor version number.

Architecture fit — the honest answer is poor for a Laravel-first estate. Laravel's canonical Vue path is Vite + laravel/vite-plugin + Inertia (or plain Blade + a mounted SPA island). This package's value proposition is inseparable from Symfony's Twig + AssetMapper + UX component model. Adopting it in Laravel means importing a second framework's asset pipeline and templating assumptions to get a capability Laravel already provides natively. Fit is therefore: greenfield Laravel — no; polyglot Laravel + Symfony shop — conditional; Symfony app that also ships Vue — yes.

Integration feasibility. Low for Laravel-only. Moderate if (a) you already run Symfony somewhere and want a shared Vue component contract, or (b) you run Twig inside Laravel (rcrowe/twigbridge and similar) and want Symfony-style component islands — a niche, lightly maintained configuration and not a foundation I'd build on. Note the conflict fix in this release is a Symfony-side unblock: teams stuck on 3.5.x were pinned below symfony/asset-mapper 8.2. That is a real operational signal about how tightly this package is coupled to Symfony internals.

Technical risk. Release risk: low. Strategic risk: moderate-to-high. The package is Symfony-controlled with no Laravel maintenance incentive, its release cadence is tied to Symfony's trains, and the #3919 fix demonstrates the failure mode — a dependency it doesn't own shipped a version that broke it, and the remedy was a Composer conflict rule rather than a compatibility shim.

Key questions before any commitment.

1. Do we need Symfony UX semantics (Twig component islands, importmap-driven assets, UX SSR conventions) or just Vue 3 inside Laravel pages?
2. Is there a Symfony application in scope today, or is this speculative?
3. What is our SSR requirement, and can Inertia SSR satisfy it without a second asset pipeline?
4. Who owns the Symfony/Twig surface if we adopt — and is that headcount durable?
5. What is our exit if upstream decouples from Twig or de-prioritizes UX Vue relative to UX React?
6. Are we currently below symfony/asset-mapper 8.2 for any reason other than this conflict?

Integration Approach

Stack fit. Target: Laravel 10/11/12, PHP 8.1+, Vue 3, Vite. This package assumes Symfony Flex, AssetMapper (or Encore), and Twig namespaces. There is no supported Laravel bridge and it is not on the maintainers' test matrix. Treat the two stacks as separate consumers of a shared Vue component layer, not as one integration.

Recommended path. Do not install into Laravel. Standardize on laravel/vite-plugin + Inertia for the Laravel side, and use UX Vue only where a Symfony app already exists. If shared UI is the goal, publish the Vue components as an internal npm package and consume it from both stacks — that keeps the Symfony-only dependency out of the Laravel composer.json and out of Laravel's deploy artifact.

Migration path, if we do proceed.

1. Inventory existing symfony/ux-vue / symfony/asset-mapper / Twig usage across the estate.
2. On Symfony services, upgrade symfony/ux-vue to ^3.6 — this is a no-op code-wise and lifts the asset-mapper 8.2 pin.
3. Validate the frontend build in CI on the Symfony services before touching asset-mapper.
4. Only then evaluate symfony/asset-mapper 8.2+.
5. Leave Laravel services untouched; record the decision and revisit at ux-vue v4 or any announced Twig decoupling.

Compatibility and constraints. v3.6.0 is drop-in over v3.5.0 — no code changes, no config changes required. The only behavioral delta is permissive: symfony/asset-mapper 8.2+ is no longer blocked. Pin ^3.6 and let the lockfile carry the rest.

Sequencing. ux-vue bump → CI green → asset-mapper bump → staging soak. Never invert the first two steps; the conflict rule existed precisely because that ordering failed for someone.

Operational Impact

Maintenance. Low absolute maintenance — the package is small and Symfony-maintained — but we do not control its roadmap, and its version constraints are dictated by symfony/* releases we also don't control. Effective maintenance cost for a Laravel team is not the package; it's carrying familiarity with a second framework's asset and templating conventions indefinitely.

Support. Symfony core team plus community, on Symfony's terms. Laravel-specific issues (Eloquent data into Vue components, Vite/Inertia interplay, Laravel Mix-era configs) will get no upstream attention. Internal escalation path must be our own frontend platform group.

Scaling. Runtime cost lives in the Vue bundle and, if SSR is used, the Node render process — not in this package. If AssetMapper/importmaps are in play, the scaling variable becomes importmap resolution and HTTP/2 request fan-out on cold loads. Neither concern applies to a Laravel Vite setup, which is another reason not to blend the two.

Failure modes to monitor.

• Dependency-driven breakage: a sibling Symfony package ships a version this package rejects (the #3919 pattern).
• Coupling drift: Symfony majors change AssetMapper or Twig internals and the integration layer moves with them.
• SSR process failure: Node renderer crash or memory growth degrading page delivery.
• Divergence: Symfony-rendered and Laravel-rendered instances of the "same" component drifting apart with no shared test harness.
• Project risk: UX Vue receiving less investment than UX React, leaving us on a slower-moving track.

Ramp-up. A Vue-fluent engineer is productive in hours on the Vue side. The real cost is Symfony UX literacy — importmaps, UX component conventions, Twig namespacing, Flex recipes — measured in days and only justified if Symfony is genuinely in scope. Budget for that explicitly rather than treating this as "just add a Composer package."

Recommendation. Upgrade to ^3.6 anywhere Symfony is present — it is free and unblocks asset-mapper 8.2. Do not introduce this package into Laravel services; the capability is already covered natively and the integration tax is permanent. Keep it on the watchlist, with a decision checkpoint at v4 or at any announced reduction in Twig/AssetMapper coupling.