- What is the laravel-frontend-presets/vuetify package and how do I install it?
- It is a Laravel frontend preset that replaces the default Bootstrap/Vue scaffolding with a Vue 2 plus Vuetify Material Design starting point, including prebuilt authentication views. On a compatible Laravel version you pull it in with Composer and then run php artisan preset vuetify, which swaps the generated assets. It is scaffolding rather than a runtime library, so the generated files become yours to own and maintain.
- Which Laravel versions does this Vuetify preset support?
- It targets Laravel 5.5 through 6.x, the releases where the php artisan preset command still exists. On Laravel 5.5 and 5.6 the preset output lands in resources/assets/js, while later versions use resources/js, so watch for directory layout drift. Anything from Laravel 7 onward no longer exposes the preset extension point.
- Can I use this preset with Laravel 10 or Laravel 11?
- Not directly. Laravel 7 removed the artisan preset command in favour of laravel/ui, and Jetstream and Breeze later took over scaffolding, so there is nothing for this package to hook into on Laravel 10 or 11. Adoption degrades into manually copying package.json, webpack.mix.js, resources/js and vendor bootstrap files out of the package. At that point you are building from a template rather than installing a dependency, and Vuetify's own documentation is usually the better starting point.
- What exactly does the preset scaffold, just Vuetify or also router, Vuex and auth views?
- The package promises Vuetify components plus prebuilt authentication views, but verify the exact contents by diffing the generated files against a fresh install. Typical output includes a Vuetify plugin registration file with theme config, a base Blade layout, example components and an updated package.json dependency block. Router and Vuex wiring varies between preset versions, so confirm before planning work around them.
- What Vue, Vuetify, Node and Laravel Mix versions does it assume?
- Expect Vue 2 with Vuetify 1.x or 2.x and a Laravel Mix and Webpack toolchain that may rely on node-sass. Those assumptions are the main compatibility risk, because node-sass and older Webpack builds fail on current Node LTS releases. Pin Laravel, PHP, Node, npm, Vue, Vuetify and Mix versions and commit lockfiles before attempting a production build.
- Why does npm install or npm run prod fail after running the preset?
- The generated dependency tree is old, so npm peer-dependency resolution and node-sass binaries commonly break on modern Node releases. Common fixes are running an older Node LTS in a container or CI image, using --legacy-peer-deps, or swapping node-sass for sass and adjusting the Mix config. Treat a clean npm run prod as an explicit gate in your spike rather than an assumption.
- Is laravel-frontend-presets/vuetify maintained and safe to use in production?
- Treat it as high risk. It has modest stars, no dependents, a low overall score and no visible maintenance process, and the frontend dependencies it pins are stale with no security response process. It is reasonable to try on a throwaway branch or sandbox, but decide explicitly who owns a fork if you adopt the generated code.
- Does it overwrite my existing files, and can I undo it?
- Presets work by replacing scaffolding files, so existing views, layouts and asset configuration can be overwritten without a prompt. Never run it against a production application or a dirty working tree. Create a spike branch or a throwaway Laravel 6 install, run the preset there, diff the output, and harvest only the files you actually want.
- How do I get Vuetify with Vue 3, Vite or Laravel 11 instead of this preset?
- Use Vuetify 3's official installation guide with Vite and Vue 3, or a maintained starter kit, rather than trying to modernise this scaffold. Rewriting the generated Vue 2 and Vuetify 2 code into a Vite plus Vue 3 plus Vuetify 3 setup is generally more work than starting from current documentation. Breeze or Jetstream combined with Vuetify 3 is a common modern combination.
- What is the license, and should the package stay in composer.json?
- MIT is reported, but confirm the LICENSE file in the repository before vendoring any code. Because this is a scaffold asset rather than an architecture component, the usual pattern is to install it temporarily, generate the files, then remove it from composer.json and own the copied assets yourself. Record the fork-versus-reference decision and your version pinning strategy in an ADR.