- Can I use symfony/ux-vue in a Laravel application?
- It is not recommended. symfony/ux-vue assumes Symfony Flex, Twig, and AssetMapper or Encore, and it is not on the maintainers' test matrix for Laravel. There is no supported Laravel bridge, so installing it means dragging a second framework's asset pipeline and templating assumptions into your app. Laravel already provides a native Vue path through laravel/vite-plugin and Inertia.
- What does symfony/ux-vue actually do?
- It is the Symfony UX integration layer for Vue 3. It handles component registration, rendering Vue components from Twig, passing props, SSR hooks, and AssetMapper or importmap wiring. In short, it lets Symfony developers add Vue islands to Twig templates without leaving the Symfony UX ecosystem.
- Does symfony/ux-vue support Vue 3?
- Yes. The package targets Vue 3 and is scoped to Symfony's UX component model rather than being a general-purpose Vue integration. Vue 2 is not the focus of this package. For Laravel, use Vue 3 with Vite and Inertia or a plain Blade-mounted island instead.
- How do I install symfony/ux-vue?
- Installation assumes a Symfony application with Flex, Twig, and AssetMapper or Encore already configured. You add the package via Composer and then register components and wire assets according to the Symfony UX conventions. There is no documented Laravel installation path, and installing it into Laravel is not advised.
- What is the Laravel equivalent of symfony/ux-vue?
- The canonical Laravel path is laravel/vite-plugin plus Inertia, or plain Blade with a mounted Vue island. These give you Vue 3 components, props, and SSR without a second templating engine or asset pipeline. If you specifically need Twig-style component islands, that is a niche configuration and not a foundation to build on.
- Is symfony/ux-vue compatible with Laravel 11 or Laravel 12?
- There is no supported compatibility commitment for Laravel 11 or 12. The package is Symfony-controlled, its release cadence follows Symfony's trains, and Laravel is not part of its test matrix. Treat any Laravel usage as unsupported and expect breakage when upstream Symfony dependencies move.
- Does symfony/ux-vue support server-side rendering?
- Yes, the package includes SSR hooks as part of the Symfony UX conventions for Vue components. The SSR story is tied to Symfony's asset and rendering model, not Laravel's. If your SSR requirement can be met by Inertia SSR on the Laravel side, that avoids introducing a second asset pipeline.
- What changed in symfony/ux-vue 3.6.0?
- Version 3.6.0 is a patch-level maintenance release wearing a minor version number. It refreshed tooling dependencies, added a Composer conflict rule with symfony/asset-mapper 8.2 and above, and fixed a README placeholder. There are no public API changes, deprecations, or breaking changes, and it is a drop-in upgrade over 3.5.x.
- Why does symfony/ux-vue have a conflict with symfony/asset-mapper?
- The 3.6.0 release added a Composer conflict rule against symfony/asset-mapper 8.2 and above. That unblocks teams previously pinned below asset-mapper 8.2 by the package's coupling to Symfony internals. It also illustrates the failure mode: a dependency the package does not own shipped a version that broke it, and the remedy was a conflict rule rather than a compatibility shim.
- Is symfony/ux-vue actively maintained, and what are the production risks?
- It is maintained by the Symfony team, with releases tied to Symfony's cadence and no Laravel maintenance incentive. Release risk is low, but strategic risk is moderate to high for a Laravel estate because the package is inseparable from Twig, AssetMapper, and Symfony UX semantics. If you need shared Vue UI across Laravel and Symfony, publish the components as an internal npm package and consume them from both stacks instead of installing this into Laravel.