Vuetify Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony bundle, not a Laravel package. There is no service provider, no config/vuetify.php, and Composer will happily install it into a Laravel app while doing absolutely nothing. If you're working in Laravel, the honest answer is that you don't leverage this package at all — you'd install vuetify via npm + Vite and write Blade components. The rest of this assessment assumes you've inherited a Symfony codebase that already depends on it, which is the realistic scenario given the 9-star, archived, zero-dependent status.

Minimal path in Symfony:

1. composer require solidworx/vuetify-bundle — expect no Flex recipe, so register manually in config/bundles.php: SolidWorx\VuetifyBundle\SolidWorxVuetifyBundle::class => ['all' => true].
2. Install the frontend side yourself — the bundle does not vendor Vuetify for you in any modern sense. Either a CDN <script>/<link> pair for vuetify@2 + @mdi/font, or npm i vuetify @mdi/font and wire it into Webpack Encore.
3. Look first at the bundle's Twig form theme directory (Resources/views/Form/…) — that's the entire value proposition. Everything the bundle does is map Symfony form types onto Vuetify components (v-text-field, v-select, v-checkbox, v-btn).
4. First use case: a contact form. Register the theme, render form_start/form_row/form_end inside a v-app → v-main → v-container shell, mount Vue on the container, and confirm the fields render as Vuetify inputs rather than raw <input> tags.

Implementation Patterns

Global form theme registration is the pattern you'll use 90% of the time. In config/packages/twig.yaml:

twig:
    form_themes:
        - '@SolidWorxVuetify/form/vuetify_layout.html.twig'

Ordering matters — the last registered theme wins for a given block, so put this after bootstrap_4_layout.html.twig if you have one, or drop the Bootstrap theme entirely.

Passing Vuetify props through Symfony form options. Once the theme is active, attr becomes your prop channel:

$builder->add('email', EmailType::class, [
    'attr' => [
        'prepend-inner-icon' => 'mdi-email',
        'outlined'          => true,
        'hint'              => 'We never share this.',
    ],
]);

This works because Vuetify reads unknown attributes as props; it's also the escape hatch when the theme's defaults are wrong.

Server-rendered shell + client hydration. The bundle gives you markup, not a Vue app. The working pattern is: Twig renders the form inside v-app, Vue mounts on #app, and any dynamic data (select options, initial values) is handed over via a <script type="application/json"> block or data-* attributes rather than interpolated into the JS. Keep CSRF hidden fields inside the form — Vuetify components don't submit themselves.

Progressive adoption. If the form theme fights your existing Bootstrap/Tailwind forms, use the bundle only for its layout/asset helpers and hand-write Vuetify markup in Twig. Half-adoption is legitimate here; the form theme is the most opinionated and most brittle part.

Encore integration. A single app.js entry: import Vue from 'vue'; import Vuetify from 'vuetify'; Vue.use(Vuetify), plus vuetify/dist/vuetify.min.css and @mdi/font/css/materialdesignicons.css in your addStyleEntry. Then {{ encore_entry_script_tags('app') }} in base.html.twig. If you're used to Laravel Mix, the Encore config keys are addEntry/addStyleEntry rather than mix.js/mix.sass — same idea, different vocabulary.

Extending the theme. Don't edit the bundle. Create templates/bundles/SolidWorxVuetifyBundle/… to override a single block, or write a thin custom theme that does {% use '@SolidWorxVuetify/form/vuetify_layout.html.twig' %} and overrides only checkbox_row. That's the sanctioned Symfony extension point.

Gotchas and Tips

• Archived and unmaintained — pin your Vuetify version. The bundle predates Vuetify 3 / Vue 3. Its templates emit props from the Vuetify 1/2 era (outlined, dense, filled). Running it against Vuetify 3 will produce components that render but ignore styling props. Lock vuetify@^2 and vue@^2 in package.json before you touch anything.
• v-app is mandatory. Vuetify's layout system silently degrades without a v-app root — you'll get forms that look 80% right with mysteriously broken spacing. Wrap your whole body content once in base.html.twig.
• MDI icons render as empty squares if you forget @mdi/font. This is the single most common "the bundle is broken" report and it's never the bundle.
• Symfony checkbox/radio impedance mismatch. Symfony emits a hidden _<name> input before each checkbox and uses value="1" semantics; Vuetify's v-checkbox prefers true-value/false-value. Expect to override checkbox_row and to keep the hidden input so unchecked state still submits.
• Validation errors are unstyled. Symfony renders form_errors as a <ul>; Vuetify wants an error-messages prop. Either map errors into the component in a custom theme block or accept unstyled red text. Note that server-side validation and client-side rules are two different systems — don't try to unify them.
• Debugging form themes is a Twig problem, not a Vue problem. bin/console debug:twig --filter=form and bin/console debug:container | grep vuetify are your first stops. If a field renders as a raw <input>, the theme isn't registered for that block — check ordering in twig.yaml and clear var/cache/dev/twig.
• No recipe means manual config drift. Unlike a maintained bundle, nothing updates your bundles.php or twig.yaml on upgrade. Document the setup in your repo, because the README will be the only other record and it's frozen.
• Migration off it is cheap. Because the bundle is essentially a set of Twig templates, the exit path is: copy the theme into templates/form/vuetify_layout.html.twig, remove the package, drop the bundle registration. Budget an afternoon, not a sprint — worth doing on any project you plan to keep, given it's archived with zero dependents.