Launchpad Laravel Package

Getting Started

Treat this as a one-shot scaffolder, never a runtime dependency. The package is a require-dev bootstrapping helper for greenfield Laravel projects; it has no place in a request lifecycle.

Minimal path:

# 1. Isolated sandbox — container, not your host. Install-time scripts are arbitrary code.
docker run --rm -it -v "$PWD:/app" -w /app php:8.3-cli bash

# 2. Fresh baseline to compare against
laravel new sandbox && cd sandbox && git init && git add -A && git commit -m "baseline"

# 3. Add the package as a dev dependency, pinned
composer require --dev juststeveking/launchpad:^x.y

Where to look first, in this order:

1. composer.json inside vendor/juststeveking/launchpad/ — check the require constraints (Laravel/PHP matrix), and whether the package declares scripts of its own. Anything that runs on post-autoload-dump executes on every install on every machine.
2. The service provider in src/ — read register() and boot(). This is where Artisan commands get registered and where publishable stubs/paths are declared.
3. php artisan list before and after install, diffed. That gives you the exact command surface, which the README may not document.
4. The stubs/ (or equivalent) directory — the actual opinions live there, not in the PHP code.

First use case: a timeboxed spike. Run the scaffold commands against the freshly committed sandbox project, then git diff to see precisely what it created versus modified. That diff is the evaluation. It tells you what the package believes a Laravel project should look like, and whether those beliefs match yours — strict types, Pint, PHPStan, Pest, CI workflows, directory layout.

Then repeat on an existing app (git clone a real service, run in a branch). The existing-app case is where scaffolders break, and it decides whether this is greenfield-only or safe for retrofits.

Implementation Patterns

Scaffold-and-eject (recommended default). Install, run the commands once, review the diff, commit, then remove the package from composer.json. You keep the generated conventions and drop the dependency, the install-time scripts, and the upstream release cadence. This is the highest-value, lowest-risk usage and requires no ongoing maintenance relationship with the author.

Reference implementation / pattern mining. Because it is MIT and self-described as a personal convenience package, its realistic worth is as a catalogue of one developer's Laravel opinions. Read the stubs, cherry-pick the ones that match how your team already writes code, and route them into an internally owned starter template (laravel new plus your own installer command). You own the code, you control the cadence, and you shed the bus-factor-of-one risk.

Pinned dev dependency in a template repo (only if consumed upstream). If a team insists on consuming rather than forking, constrain it hard:

"require-dev": {
    "juststeveking/launchpad": "1.2.3"
}

Exact pin — no caret. Prohibited in release branches. A named internal owner. An explicit written acknowledgement that you inherit upstream's abandonment risk and that a Laravel major bump may silently break the scaffold.

Diff-driven adoption. Always produce a two-column list before deciding: what we gain (conventions we don't have) versus what conflicts (conventions that fight our CI rules, org-wide linters, or existing directory layout). Adopt or fork against that list, not against impressions from a successful run.

Fork-and-own with a CI smoke test. If the stubs prove valuable, fork and add a job that scaffolds a throwaway project and asserts it builds:

laravel new smoke --quiet
cd smoke
composer require --dev ./path/to/internal-template
php artisan <your-scaffold-command>
composer install --no-dev && php artisan test

This is the cheapest guard against the template quietly decaying into cargo cult.

Publish-then-edit. If the service provider exposes publishable stubs, publish them into your own repo (php artisan vendor:publish --provider=...) and commit the result. You then edit your copies freely, and the upstream package becomes a source you can drop at any time.

Gotchas and Tips

Read the source before you run it. There is no changelog discipline to rely on and no third-party dependents to learn from — zero dependents means no production usage has surfaced the edge cases for you. The source is the documentation.

Install-time scripts are arbitrary code execution. Even as a dev dependency, a post-install-cmd or post-autoload-dump script runs on developer laptops and CI runners. Sandbox the first install in a container and diff your composer.json afterwards to confirm nothing was injected.

Mutating vs. creating is the gating question. Determine whether the scaffolder only creates new files or also rewrites existing ones (config/, composer.json, phpunit.xml, .gitignore). Create-only is reversible in minutes; mutating turns a trial into a review exercise. Always run against a committed baseline so git diff is your audit trail, and test idempotency — run the command twice and check the second run is a no-op.

Verify composer install --no-dev excludes it cleanly. This is a hard gate before any deploy pipeline touches a repo that once used it. A dev dependency that leaks into a production autoload path through a stale lockfile or a class reference is an outage waiting to happen.

False confidence is the real failure mode. Teams assume "the scaffolder set up the linters" means quality is handled and skip baseline review. Generated defaults must be visible and reviewable, not implicit. Walk the diff with someone who did not run the command.

No semver guarantee — treat every upgrade as an untested change. Bump the pin only inside a branch where you can diff the scaffold output against the previous version.

Opinion lock-in is a silent cost. The package encodes one maintainer's conventions. Where they conflict with org-wide CI rules or an existing platform standard, the conflict surfaces months later as inconsistent services rather than at install time.

Expect drift against Laravel majors. At 15 stars and a single maintainer, the package will likely lag a Laravel release without notice. This is a reason to fork or eject, not a reason to avoid trialing it.

Plan to own it. Budget a fork at well under a day per quarter for Laravel bumps. Consuming without forking shifts the cost from "we fix it" to "we are blocked when it breaks" — strictly worse at this value level.

Document the output immediately. Write a one-page internal README covering what the scaffold set up, which generated files are safe to edit or delete, and who owns it. Without both an owner and that page, new hires cannot tell generated scaffolding from load-bearing application code, and the generated conventions decay into cargo cult within a couple of hires.

Extension points to check first: publishable stubs (copy and own them), the service provider (only register what you need), and any config file — publish it and diff against the package default so upstream changes are visible rather than surprising.