- What is gts-meghni/laravel-essentials-kit used for?
- It is a Laravel scaffolding package that generates a ready-to-use API boilerplate into your application. It bundles hardened defaults, a JSON response envelope, global exception rendering, common packages, and quality gates so you can start feature work faster. The generated files live in your app as code you own, rather than remaining hidden inside the dependency.
- How do I install laravel-essentials-kit?
- Install it with Composer, then run the package installer or generator to write the boilerplate into your Laravel app. The installer uses interactive yes/no prompts for optional packages and also supports non-interactive paths such as --packages=reverb for CI and automation. Commit the generated changes so you can review and customize them as part of your codebase.
- Which Laravel versions does laravel-essentials-kit support?
- The current release targets Laravel 11/12-style applications, including first-party broadcasting with Reverb when you opt in. Exact Composer constraints should be checked in the package's composer.json before upgrading a production app. Since generated files are owned by your app, test the output against your target Laravel version.
- What hardened defaults and quality gates are included?
- The kit is positioned around API-first defaults: a consistent JSON response envelope, global exception rendering, and common helper utilities. It also includes quality gates and package choices intended to keep a codebase clean and consistent. The generated code can be reviewed, modified, or removed like any other application code.
- How does the JSON response envelope and exception rendering work?
- The generated boilerplate provides a consistent response envelope so API success and error payloads follow the same structure. Global exception rendering centralizes how exceptions become JSON responses, reducing repeated try/catch and response-shaping code in controllers. Because it is generated into your app, you can adjust the envelope and renderer to match your API conventions.
- Can I opt into SATIM, captcha, or Reverb WebSockets?
- Yes. Optional integrations follow an opt-in model, with interactive yes/no prompts and non-interactive package flags such as --packages=reverb. SATIM and captcha mainly touch Composer and config, while Reverb also updates env files, generated frontend assets, Docker Compose, and nginx routing. Review the generated diffs carefully when enabling any integration.
- Is it safe to re-run the installer on an existing Laravel project?
- Re-running is intended to support scaffolding, but the Reverb opt-in is the sharpest edge because it writes BROADCAST_CONNECTION and REVERB_* keys into env files. Whether those writes are idempotent and whether an existing BROADCAST_CONNECTION is preserved are key evaluation questions flagged for this release. Run it on a clean branch and review .env, Docker, and nginx diffs before using it on production.
- Does adding Reverb reduce the queue container memory?
- Yes. The Reverb opt-in carves 256 MB out of the queue container's default, dropping it from 768 MB to 512 MB. That is a real reduction in headroom for job-heavy applications and is flagged as something that should be surfaced during install and ideally made configurable. Review your queue workload before enabling Reverb in production.
- How does Reverb WebSocket routing work with Docker and nginx?
- The installer proxies /app/ for WebSocket traffic and /apps/ for Reverb's signed HTTP API at both nginx layers, including the required upgrade headers. Serving them on the app's own origin avoids CORS setup and a second TLS certificate, but it means those paths must not collide with existing routes. The current single reverb container is suitable for small and medium deployments; multi-container horizontal scaling is not documented and is flagged as an open question.
- How do I disable or remove Reverb changes later?
- The package supports opt-in selection through prompts and flags such as --packages=reverb, but a dedicated uninstall or disable command that cleans up Docker Compose and nginx changes is flagged as an open question. Because the generated files are code you own, the practical path is to review the Reverb-related diffs and revert them through version control. Check the package docs for any removal command before making manual infrastructure edits.