- What is titasgailius/laravel-moonlight and what does it actually generate?
- Moonlight is a batteries-included Laravel preset built on the Inertia.js, Vue 3 and Tailwind CSS stack. It is an install-time scaffolding tool, not a runtime library: you add it as a dev dependency, run its artisan install command, and it writes controllers, Vue pages, layouts, routes, Tailwind configuration and authentication scaffolding directly into your application. After that first commit, the generated code belongs to you and the package is no longer in the request lifecycle. Think of it as an opinionated starting point rather than a framework you build on top of.
- Which Laravel and PHP versions does Moonlight support?
- Do not assume current support. The last tagged release was 2023-01-03, which predates Laravel 10 and 11 as well as the Inertia v1 and v2 release lines, so the advertised constraints will likely be older than the framework version you are running. Check the composer.json constraints in the repository before installing and validate the install on your exact Laravel and PHP versions on a throwaway branch. If it does not resolve cleanly, expect to adjust constraints manually rather than relying on --with-all-dependencies to fix everything.
- Does Moonlight ship Vite or Laravel Mix, and which Inertia, Vue and Tailwind versions does it pin?
- Given the January 2023 release date, the preset most likely still ships Laravel Mix rather than Vite, and will pin Inertia and Tailwind versions from that era. That matters because Vite has replaced Mix in current Laravel releases and Tailwind 3 to 4 introduced breaking changes. Inspect the generated package.json, vite or webpack config, and Tailwind config immediately after install, then reconcile versions by hand. Budget a half-day spike to confirm a clean install and a successful production build before you commit the team to it.
- Is Moonlight a runtime dependency I will have to keep upgrading?
- No. Moonlight is a one-time code generator, so once the files are generated into your repository there is no vendor coupling and no upgrade treadmill from the package itself. The tradeoff is that maintenance shifts from tracking upstream releases to owning the generated code, including future Laravel, Inertia, Vue and Tailwind upgrades. That is perfectly manageable, but only if the ownership is explicit and someone on the team is accountable for it.
- How do I install Laravel Moonlight and can I eject it later?
- The intended flow is to require the package as a Composer dev dependency and run its artisan install command against a fresh Laravel application, which publishes the controllers, Vue pages, layouts, routes and Tailwind config into your codebase. Ejection is trivially clean by design because nothing in the request lifecycle references the vendor package after install. Most teams go one step further and fork the preset into an internal scaffold so they can pin versions and regenerate consistently.
- How is Moonlight different from Laravel Breeze or Jetstream?
- All three scaffold an Inertia plus Vue plus Tailwind application, so the real decision is which scaffold to adopt, not whether you need the capability at all. Breeze and Jetstream are officially maintained by the Laravel team and track current framework releases, while Moonlight offers a more opinionated layout and component structure that can save days of boilerplate for Vue-fluent teams. Diff Moonlight's generated output against Breeze's Vue and Inertia stack first; if Breeze is close enough, prefer the officially supported path.
- Can I install Moonlight into an existing Laravel application?
- It is not recommended. Moonlight is designed for greenfield projects or throwaway spike branches, and there is no migration path for retrofitting a live codebase with it. Because it overwrites layouts, routes and front-end scaffolding, applying it to an existing app risks conflicts with your current auth, routing and asset pipeline. If you want its structure, generate it in a clean repo first and port the pieces you need manually.
- Is Moonlight's generated authentication scaffolding production-ready?
- Treat that as unverified until you test it. An 18-month-old preset may not include current patterns such as rate limiting on login, email verification flows, password reset handling and modern session management. Walk through registration, login, verification, password reset and logout end to end on the installed branch, and immediately wrap the generated auth flows in CI tests. Fixing gaps is usually straightforward, but you need to know about them before launch rather than after.
- Is Laravel Moonlight still maintained, and what is the risk of adopting it?
- Activity is effectively minimal: the last release was 2023-01-03, the repository sits around 142 stars, and support is a single maintainer with no SLA or security response process. Since the stack has moved on materially since then, you should not expect upstream fixes for future Laravel, Inertia, Vite or Tailwind releases. The mitigation is to fork the preset into your organisation and own it, or to choose an officially maintained option like Breeze or Jetstream instead.
- What license is Moonlight under and should we fork it internally?
- The project is understood to be MIT licensed, which is fork-friendly, but confirm the LICENSE file in the repository before you copy it into an internal scaffold. Forking is the recommended path if your team is committed to Vue 3 plus Inertia plus Tailwind and Moonlight's structure genuinely beats Breeze's output. Pin all Composer and npm versions in the fork, add CI around the generated auth flows, and only scaffold the real application once the fork is validated.