Laravel Starter Kit Cli Laravel Package

Getting Started

This is a standalone CLI, not a runtime library — you don't add it to an existing app's composer.json. There are two install paths, and the v1.0.2 release makes the second one first-class:

Option A — Composer (global):

composer global require shire-studio/laravel-starter-kit-cli
# ensure ~/.composer/vendor/bin (or ~/.config/composer/vendor/bin) is on PATH
laravel-starter-kit --help

Option B — PHAR (new in v1.0.2):

# grab the .phar from the GitHub release assets for v1.0.2
chmod +x laravel-starter-kit.phar
./laravel-starter-kit.phar --help

Where to look first:

1. --help / the command list — v1.0.2 explicitly surfaces the help command in the list, so list is now a reliable entry point for discovering subcommands.
2. The README for the scaffold command's flags (target directory, starter-kit variant, auth/teams options).
3. The GitHub releases page for the PHAR asset and checksum.

First use case: scaffold a fresh Laravel starter-kit project into an empty directory, then cd in, copy .env.example to .env, and run the usual composer install && npm install && php artisan migrate. Treat the CLI as a one-shot generator — the output is a normal Laravel app you own from that point on.

Implementation Patterns

Pin the version, always. Starter kits are opinionated templates; a minor bump can change generated files. Use composer global require shire-studio/laravel-starter-kit-cli:1.0.2 or vendor the PHAR at a fixed URL in your repo/tooling image.

PHAR for CI and containers, Composer for dev machines. The PHAR removes the Composer-global + PATH setup entirely, which makes it the better fit for Dockerfiles and ephemeral CI runners:

COPY --from=curl /laravel-starter-kit.phar /usr/local/bin/laravel-starter-kit
RUN chmod +x /usr/local/bin/laravel-starter-kit

Non-interactive scaffolding for automation. Wrap the command with explicit flags and --no-interaction so it doesn't block on prompts. This is the pattern for "new project" bootstrapping scripts, make new-project, or a devcontainer postCreateCommand.

Smoke-test your golden path. A small CI job that scaffolds into a temp dir, runs composer install, and boots the app catches upstream template breakage before your team hits it. Keep it on a schedule, not just on PRs.

Compose with your own tooling rather than forking. If you need org-specific defaults (package namespace, CI files, editor config), layer a post-scaffold script over the CLI output instead of maintaining a fork. The CLI's job ends when the directory is populated.

Discovery via the command list. Since help is now listed, scripts and onboarding docs can point users at list/help <command> rather than hardcoding flag documentation that drifts.

Gotchas and Tips

• PHAR and Composer builds can diverge. The two distribution channels are built separately; if you hit odd behaviour, confirm which one you're running (--version) before filing a bug. Keep one channel per environment.
• phar.readonly is a build-time concern only. You don't need to change php.ini to run the PHAR — only to rebuild one. Don't let a blog post talk you into disabling it globally.
• macOS quarantine. A downloaded PHAR may be blocked by Gatekeeper. xattr -d com.apple.quarantine laravel-starter-kit.phar resolves it; document this if your team is on macOS.
• chmod +x and shebang. If ./tool.phar fails with "permission denied," it's the exec bit, not PHP. If it fails with "bad interpreter," invoke it as php laravel-starter-kit.phar.
• Composer global bin not on PATH is the single most common "installed but command not found" issue. Prefer composer global exec laravel-starter-kit -- --help or fix PATH once in your shell profile.
• Interactive prompts hang CI. Always pass --no-interaction plus explicit values; a silent 10-minute timeout is usually a prompt waiting on stdin.
• Target directory must be empty. Most scaffolders refuse to write into a non-empty path — check before running in a script, and fail fast with a clear message.
• Network dependency. Scaffolding pulls down the starter kit and dependencies; air-gapped builds need a mirrored template or a pre-baked image.
• No upgrade path for generated apps. The CLI bootstraps; it doesn't migrate. To pick up template changes, re-scaffold into a scratch directory and diff against your app — don't expect an update command.
• Extension points are thin by design. There's no plugin API to rely on; use post-scaffold scripts and your own stubs. The MIT license (added in this release) means forking is legally unencumbered if you truly need to.
• Dependency bumps ship silently. v1.0.2 includes a chore(deps): update commit — run the smoke test after upgrading the CLI itself, not just after upgrading Laravel in your app.