Laravel Init Laravel Package

Getting Started

• Install with composer require fuelviews/laravel-init, then run the package's init/setup artisan command (php artisan to list it — typically something like php artisan init or php artisan app:init).
• First place to look: the package's README install section and the published config/laravel-init.php (publish via php artisan vendor:publish --tag=laravel-init-config). The config file is where the set of packages/stubs to install is defined, so it is your source of truth for what the init run will touch.
• First use case: scaffold a fresh Laravel app — run the init command immediately after laravel new, before adding your own models/migrations. The command installs base packages, registers their service providers, and (per v2.0.7) now runs composer dump-autoload and clears caches for you, so a single command leaves you with a working, bootable app.
• v2.0.7 is a patch release with no breaking changes — safe to bump from v2.0.6. If you are installing for the first time, prefer v2.0.7 over earlier versions, since it fixes the install instructions and the autoload/cache step that previously left new providers unregistered.

Implementation Patterns

• Fresh-project scaffolding (primary workflow): laravel new my-app → composer require fuelviews/laravel-init → run init command → commit the result as your project's "baseline" commit. This gives you a repeatable, diffable starting state you can rebase future projects against.
• Idempotent re-runs: after the v2.0.7 autoload-dump fix, re-running the init command on an already-initialized project is safer — it will re-register providers and clear caches. Use this when a teammate pulls a branch with newly added init-managed packages.
• Customize via config/stubs: publish the config and the stub files, then edit paths and entries there rather than editing generated files directly. The v2.0.7 Tailwind config stub path fixes mean your custom stubs should target the corrected paths (update any local copies you kept).
• Team onboarding: keep the Laravel Init version pinned in composer.json and treat the generated baseline (Tailwind config, service provider registrations, .gitignore entries) as reviewed code. New team members get a consistent setup without a wiki of manual Tailwind/provider steps.
• CI integration: run the init command in a setup step in CI (or a Docker entrypoint) after composer install, then let the command's built-in dump-autoload + cache-clear handle bootstrapping instead of hand-rolling those steps in your pipeline.

Gotchas and Tips

• Autoload/cache ordering: the core v2.0.7 fix is that the installer now dumps autoload and clears caches after installing packages. If you script the init command yourself, do not skip that step — skipping it is exactly what leaves new service providers unregistered and yields confusing "class not found" or "provider not registered" errors.
• Tailwind config paths changed: v2.0.7 removed incompatible Tailwind dependencies and corrected the Tailwind config stub paths/entries. If you generated a project on v2.0.6 or earlier, re-check your tailwind.config.js content paths and package.json — a stale config can silently compile with no CSS.
• .gitignore updates: re-check your .gitignore against the updated stub; missing entries (build dirs, generated files) can leak artifacts into commits after an upgrade.
• Read the install instructions again: v2.0.7 explicitly fixes the installation instructions — if you followed older docs, re-read the README before upgrading, as the corrected sequence (install → init → autoload/cache) matters.
• Debugging an init run: if something doesn't register, check in this order — (1) was composer dump-autoload run, (2) did the cache clear run, (3) is the package constraint satisfied in composer.json, (4) is the provider registered in the published config. v2.0.7's version-constraint updates mean pinning old versions can cause silent skips.
• Extension point: the published stubs and config are the intended customization surface — keep your customizations there in source control so future package upgrades don't clobber hand-edited generated files.
• CI note: the actions/checkout 4→5 bump is maintainer-side only and does not affect how you consume the package.