Daisyui Starter Kit Laravel Package

Getting Started

This is a starter kit / scaffolder, not a runtime library — the release that matters is the one you laravel new from, not one you composer require and forget. Treat v1.0.0 as the baseline: it is the first release where the Livewire + daisyUI front end, the Chisel installer, and the shipped Composer dist are all verified together.

1. Scaffold with the installer, not by hand:

   laravel new my-app --using=<vendor>/<package>
   

   --using is confirmed working in this release because tests/, .github/ and phpunit.xml are now included in the Composer dist. If you get a bare skeleton with no test harness, you are pulling a pre-1.0.0 dist.
2. Prerequisites: PHP 8.2+, Node/npm (the install runs a Vite build), and a database for the default migrations. Pick the feature set at the prompt — deselections strip @chisel marked blocks from Fortify config, routes and Vite entries as part of install.
3. Where to look first after install:
   • resources/css/app.css — the daisyUI 5 @plugin/theme block and semantic token setup.
   • routes/web.php + routes/auth.php (if auth selected) — what survived deselection.
   • vite.config.js — confirm the input entries match what actually remains.
   • config/fortify.php + app/Actions/Fortify/ — present only if you kept Fortify.
   • app/Livewire/ and resources/views/livewire/ — the starter components.
4. First use case: php artisan make:livewire Counter, use daisyUI classes (btn btn-primary, card bg-base-200) in the Blade view, drop it on a page with <livewire:counter />, and npm run dev. That exercises the whole stack — Livewire wiring, daisyUI tokens, Vite — in about five minutes.

Implementation Patterns

Semantic tokens are the contract, not raw Tailwind colours. Write bg-base-100, text-base-content, border-base-300, btn btn-primary — never bg-gray-100. The whole value of the daisyUI 5 migration is that a theme swap recolours the app without touching templates. Theme definition lives in resources/css/app.css via @plugin "daisyui" { themes: ... }; keep per-project theme overrides in a dedicated block so upstream template updates stay diffable.

Feature deselection is a one-shot build step. Chisel resolves @chisel markers at install time and the result is copied into your app. So:

• Decide your feature set up front; re-running the installer into an existing app is not the workflow.
• If you need a house-standard starting point (e.g. "Livewire + daisyUI, no Fortify, no registration"), fork the kit, edit the marker blocks in the fork, and point --using at your fork. That is the intended extension path.
• Keep a README note in the fork recording which @chisel blocks you changed, because the markers are invisible in the generated app.

Auth work goes through Fortify actions. When Fortify is selected, customise behaviour in app/Actions/Fortify/* and config/fortify.php features array — not by editing generated controllers. Login/registration views are Livewire components; override the view binding rather than editing vendor-shaped Blade.

Testing pattern. Pest is shipped and the kit's own CI asserts Livewire components. For your own code:

Livewire::test(Counter::class)
    ->call('increment')
    ->assertSet('count', 1);

Add a smoke test that boots the homepage and hits a Fortify route only if you kept that feature — the kit's own test matrix is combination-aware, yours needs to be too.

Vite entries are conditional. After install, vite.config.js should only reference files that exist. If you add a feature back manually, add the entry explicitly; don't assume the installer's trimming is reversible.

Gotchas and Tips

• There is no upgrade path. Once laravel new finishes, the package is not in composer.json. Security patches and daisyUI 6 will not arrive via composer update. Plan for periodic re-scaffolding or cherry-picking by hand — this is the single biggest ongoing cost.
• daisyUI 4 → 5 is a real migration, not a rename. Semantic tokens and the @plugin "daisyui/theme" syntax changed; any custom theme ported from a v4 project needs rewriting. Component class names largely survived, CSS variables did not.
• The release notes admit one failing deselection scenario (22/23). Whatever combination that is, it is not verified. Run a throwaway laravel new with your exact feature choices and boot it before committing the scaffold to a repo.
• Dangling markers break output. The stripper removes marked blocks line-wise; a hand-edited unbalanced @chisel open/close pair in your fork will silently produce broken PHP or a vite.config.js pointing at a deleted entry. Symptom is usually a Vite build error or a class-not-found at boot. Fix by diffing a fresh scaffold against expectations, not by patching the generated app.
• Missing tests/CI means the wrong dist. If phpunit.xml or .github/workflows/ is absent after install, that's a packaging regression — reinstall from 1.0.0 rather than writing your own harness from scratch.
• Deselecting Fortify leaves references behind if you wrote code against it. Grep for Fortify::, features, and two-factor after a no-Fortify install before assuming the trim was clean.
• Debugging install failures: run laravel new -v, and inspect the temporary clone directory the installer leaves behind. Almost every install bug is a marker-stripping bug or a dist-packaging bug — both are upstream issues, worth an issue rather than a local patch.
• Node is mandatory. Even a backend-only feature set pays the Vite build cost during install; if npm is unavailable the scaffold may complete with a stale asset manifest and a broken first page load.