- What is fuelviews/laravel-init used for?
- fuelviews/laravel-init is a Composer starter package that scaffolds common Laravel initialization, including service providers, configuration stubs, Tailwind config stubs, and baseline defaults. It is a build-time and developer-onboarding tool rather than a runtime dependency, so it is best suited to teams standardizing how new Laravel repositories are bootstrapped.
- How do I install fuelviews/laravel-init in a Laravel project?
- Install it with Composer, typically as a dev dependency, then run the package's install command against your project. The installer writes service providers, config stubs, and other baseline files into the host application. In v2.0.7 the install flow also runs composer dump-autoload and clears caches so newly registered providers are picked up.
- Does fuelviews/laravel-init support Laravel 11 or Laravel 12?
- The provided notes do not list explicit Laravel or PHP version support, so verify compatibility in the repository before adopting it. Pin both your Laravel major version and PHP version in your own project documentation. Test the installer on a scratch branch because it edits host files such as composer.json and Tailwind configuration.
- Is fuelviews/laravel-init safe to run on an existing Laravel application?
- It is safer for new or lightly customized projects because the installer mutates host-application files, including composer.json constraints, config stubs, and Tailwind configuration. Running it on an existing app can overwrite or conflict with customizations, and the notes do not document whether the tool detects and skips modified files. Always run it on a scratch branch and diff the result before merging.
- Is the fuelviews/laravel-init installer idempotent?
- Idempotency is not documented in the available notes, so do not assume a second run is a safe no-op. Before relying on repeat installs, test the command twice on a clean Laravel project and inspect the diff. If it rewrites files or constraints on each run, treat it as a one-time scaffold rather than a repeatable setup step.
- Why does fuelviews/laravel-init run composer dump-autoload and clear caches?
- v2.0.7 adds composer dump-autoload and cache clearing after installation so newly registered service providers are actually loaded. Before that change, installs could appear successful while leaving a broken autoloader or stale config cache. This is a reliability improvement, but teams should confirm the commands are safe in their environment, especially read-only container filesystems.
- Can I use fuelviews/laravel-init without Tailwind CSS?
- You can use it for provider and config scaffolding, but the package includes Tailwind config stubs and related dependency changes. The notes do not document an opt-out flag for Tailwind, so non-Tailwind projects inherit risk from those code paths. Review the diff carefully and remove or ignore Tailwind-specific changes if you do not use Tailwind.
- Does fuelviews/laravel-init work in CI pipelines or read-only containers?
- It is a build-time and onboarding tool that writes files into the host application, so it is a poor fit for ephemeral CI runners or reproducible container builds that expect immutable application code. The installer also runs composer dump-autoload and clears caches, which may fail on read-only filesystems. Use it in a local or dedicated scaffolding step, then commit the generated changes.
- Does fuelviews/laravel-init rewrite my composer.json version constraints?
- Yes, the package edits composer.json constraints on the host application on your behalf. That is convenient but removes explicit control over what your project is pinned to, which matters for compliance and software composition analysis. Add a review gate before running it in repositories with SCA or version-pinning requirements, and check whether rewrites are scoped to an allowlist and logged.
- What changed in fuelviews/laravel-init v2.0.7 and do I need to migrate?
- v2.0.7 is described as corrective and additive: it adds composer dump-autoload and cache clearing after install, removes incompatible Tailwind dependencies, and fixes Tailwind config stub paths and entries. There is no migration burden from v2.0.6, but projects that inherited old Tailwind dependencies or customized generated config should diff after upgrading. Bump the dev dependency, run the installer on a scratch branch, and reconcile any Tailwind-related changes manually.