sixlive/laravel-preset
sixlive/laravel-preset helps you define and apply reusable Laravel application presets, bundling common setup tasks like package installation, configuration, and scaffolding into a repeatable command for consistent new projects.
This is a Laravel frontend preset in the same family as laravel-frontend-presets/tailwindcss: a service provider registers an Artisan preset command, and running it swaps the default resources/assets (or resources/js/resources/sass) scaffolding, webpack.mix.js, package.json dependencies, and a handful of Blade layouts for the author's preferred stack. Treat it as a curated set of stubs plus a one-shot installer, not as a runtime dependency.
Minimal steps on a compatible app (Laravel 5.5–5.8 era; the php artisan preset command it hooks into was removed in Laravel 6):
composer require sixlive/laravel-preset --dev
php artisan preset sixlive # the exact preset name is whatever the provider registers
npm install && npm run dev
Where to look first, in this order:
src/*ServiceProvider.php) — shows the preset name you pass to artisan preset, what it publishes, and whether it auto-registers via package discovery.package.json/composer.json entries it merges. This is the real documentation.stubs/ directory — every file you'll end up living with (webpack.mix.js, tailwind.js/tailwind.config.js, app.scss, app.js, Blade layouts, .babelrc, .eslintrc). Read these before running anything; they tell you exactly what your project will look like afterward.First use case: bootstrapping a fresh Laravel 5.8 app with the author's Tailwind/Vue (or similar) setup so you don't hand-assemble Mix config, PurgeCSS, and base layouts. Because the last release is March 2019 and adoption is tiny (19 stars), the realistic first use case today is mining the stubs for an existing project rather than running the installer end-to-end.
Fresh-project bootstrap (the intended path). Create the Laravel app at a version the preset supports, require the package as a dev dependency, run php artisan preset sixlive, then commit before npm install so you can diff exactly what the preset touched. Use git diff as your changelog, since the package ships no meaningful docs.
Preset-as-reference / selective adoption. On modern Laravel (9/10/11), don't install the package at all. Clone the repo, copy the pieces you want by hand — the webpack.mix.js (or port it to Vite), the Tailwind config, the base Blade layouts, the ESLint/Babel config — and adapt them. This is the most common real-world pattern for a 2019 preset in 2024+.
Snapshot into your own starter kit. If you like the opinions, fork the repo, update the stubs (Tailwind version, Mix→Vite, @tailwindcss/forms, etc.), and keep it as your private preset/starter repo. You get the value of the author's choices without depending on an unmaintained package. Wire this into your project scaffolding script (laravel new && cp -r stubs/... && npm install) so new services start consistent.
Provisioning/CI integration. If you do run the preset in a script, pin the exact version ("sixlive/laravel-preset": "1.x") and run it in a Docker build step against a pinned Laravel skeleton. The installer is not idempotent-friendly — assume it's a one-shot on a clean checkout, and never run it against a repo with local frontend changes you care about.
Revert pattern. Laravel's preset system supports php artisan preset none to restore the default scaffolding. Know this before you run the preset: it's your escape hatch, but it only restores Laravel's stock files, not your own modifications.
Integration tips. Register the provider only in require-dev; don't let it leak into production autoload. After running, immediately verify package.json — presets typically merge dependencies, and stale pins (old laravel-mix, node-sass, Tailwind 0.x/1.x) are the main thing you'll need to bump. Then run npm install, npm run dev, and a production npm run production to confirm PurgeCSS/Mix config actually builds.
php artisan preset command was removed in Laravel 6 (replaced by laravel/ui and later starter kits). On Laravel 6+ the command simply won't exist; on 5.8 and earlier, composer constraints may still fight you. Check the package's composer.json illuminate/support constraint before requiring it.require-dev and out of production images.webpack.mix.js, resources/js/app.js, resources/sass/app.scss, package.json, and Blade layouts. Commit or branch first. There's no dry-run.sixlive, sixlive-preset, etc.) must match what the provider registers; a typo yields "Preset [x] does not exist." Read the provider to confirm.node-sass (fails on modern Node), old laravel-mix (v4-era, incompatible with current webpack), Tailwind pre-1.0 config format (.tailwind.js vs tailwind.config.js), and PurgeCSS configured the old way. Plan to modernize: Node LTS, Mix 6 or Vite, @tailwindcss/* plugins, updated purge/content globs.config/app.php under providers (dev-only). If it publishes configs/assets, use php artisan vendor:publish --provider="Sixlive\\...\\...ServiceProvider" and inspect tags.composer.json / package.json merge quirks. Presets often append dependencies rather than reconcile versions; you can end up with duplicate or conflicting entries. Diff both files post-run and prune.preset hook (on 5.x) or convert it to a small internal starter repo (on 6+). The preset class is small and easy to extend; the stubs are the substance.npm run dev fails after the preset, bisect by reverting webpack.mix.js to stock, then reintroduce preset pieces one at a time. Most failures trace to a Node/sass-loader/webpack version mismatch, not to Laravel.How can I help you explore Laravel packages today?