Lambo Laravel Package

Technical Evaluation

Architecture fit. Lambo is a developer-experience utility, not a runtime dependency. It sits entirely outside the application architecture: a globally installed Composer binary that wraps laravel new and adds host-level side effects — MySQL database creation, valet link/secure/open, git init plus a first commit, editor and browser launch. Fit is therefore binary rather than graded: it matches a macOS + Valet + Laravel-10-era workstation, or it does not. Because it never enters composer.json, it adds no surface to shipped artifacts and cannot affect customers. Structurally it is a Laravel Zero CLI that shells out to laravel, valet, and mysql; its real dependencies are host binaries with independent release cadences, not PHP packages under its control.

Integration feasibility. Install effort is trivial (one pinned composer global require tightenco/lambo:3.1.1). The actual integration work is organizational, not technical: deciding whether the scaffold recipe lives in one developer's home directory (aliases via lambo edit) or in a checked-in bin/new script. Only the latter is defensible, because it makes the invocation reviewable and diffable and keeps the tool swappable.

Technical risk. Archived upstream is the dominant vector. It shells out to globally installed binaries whose flags and skeletons drift, and Laravel 11's trimmed skeleton and reworked starter kits postdate the August 2023 release. Failure can be loud (acceptable) or silent (unacceptable — a scaffold that looks correct and breaks weeks later). Secondary risks are well documented: prompts hang forever in non-TTY contexts; database creation fails quietly, leaving a valid-looking project pointed at a nonexistent database; repeated runs collide on database names and stale Valet links; editor launch silently no-ops when EDITOR/LAMBO_EDITOR is unset; git init nests inside a non-empty parent directory. There is no security response path and no issue triage, which matters for a tool that touches local databases and executes host CLI commands.

Bounded ceiling. The differentiators — starter-kit prompts, test-framework choice, database setup, git initialization, a --using extension point — have largely been absorbed by the Laravel installer. Opportunity score 2.65 against 615 stars reflects that. Zero dependents is expected for a global CLI, not a health signal.

Key questions.

• Are the target developers actually on macOS + Valet, or on Herd / Sail / containers / Linux / WSL? Mixed profiles mean the Valet-baked steps are wrong or redundant and coverage is partial.
• Which Laravel and PHP versions do we scaffold today, and does a 3.1.1 scaffold survive composer update and first deploy?
• What is the measured time-to-first-commit baseline for laravel new versus Lambo on our machines — is the delta a real onboarding lever or noise?
• Does any policy require an actively maintained upstream for tools that touch local credentials and databases?
• If we adopt the pattern, who owns the replacement — a laravel new --using package or a shared bin/new-project — and by when?

Integration Approach

Stack fit. Narrow and explicit: PHP/Laravel, macOS, Valet, Laravel 10 era. Herd users get redundant work; Sail and container users get actively wrong work (host-level database creation and hostname linking are the wrong model inside containers); Linux, Windows, and WSL are effectively unsupported. Treat it as a fit for one well-defined workstation profile, never a team-wide standard.

Migration path. Pin 3.1.1 globally, set EDITOR, and keep it out of composer.json, onboarding docs marked "required," and any CI path. Capture intent immediately — global defaults via lambo edit, project types as aliases — then externalize the recipe into a checked-in bin/new script that calls Lambo with explicit flags. The script is ours; the tool is swappable. The recommended exit path is to reimplement the load-bearing steps as a private laravel new --using installer package (versioned, testable, owned) or a bin/new-project script in shared tooling. Exit cost today is effectively zero — preserve that by never creating a hard dependency.

Compatibility. Three independently versioned surfaces must be reconciled: Lambo 3.1.1, the globally installed Laravel installer/skeleton, and host valet/mysql. Lambo pins none of them. Every PHP or Laravel bump requires re-validating against a hand-rolled laravel new. Assume Laravel 10 compatibility; do not assume Laravel 11+.

Sequencing (bounded, opt-in pilot):

1. Verify prerequisites (which laravel, which valet, which mysql), confirm lambo list runs, set EDITOR/LAMBO_EDITOR in the shell profile.
2. Run lambo edit and fill in defaults — the highest-leverage step; it converts an interactive wizard into a one-word command.
3. Define two to four project-type aliases (client, spike, pest, package-dev) and validate each produces a working, testable app.
4. Immediately port those recipes into bin/new with explicit flags. Keep post-create work (internal packages, CI config, seeders) in a separate bootstrap script chained with && — never assume Lambo does it.
5. Time-box the pilot against a measured baseline; decide adopt-pattern vs. reimplement within one or two sprints, before the pinned global install becomes the standard by inertia.
6. Record the adopt/decline rationale in the decision log so the evaluation isn't repeated.

Do not: invoke it from a Dockerfile, a Makefile target reachable from CI, or a provisioning script — non-TTY prompts hang rather than fail.

Operational Impact

Maintenance. The only burden we own is re-validation: pin, re-verify against a hand-rolled laravel new on every PHP/Laravel bump, and keep the wrapper script under review. Lambo itself will not be maintained — archived, last release 2023-08-08 ("fix build issue"), no plugin API, no hook system, no --using equivalent. The extension surface is configuration and aliases only; anything beyond that is a wrapper or a fork, and given archived status, prefer the wrapper.

Support. Expect a recurring, recognizable ticket set: "Lambo did nothing" (EDITOR unset), "migrations passed but the app 500s" (quiet DB failure, .env pointed at a nonexistent database), "the site 404s" (stale Valet link after a re-run), "it hangs" (non-TTY context). All are debuggable — it is a Laravel Zero app, so -v/-vvv expose the underlying shell commands and a developer can run them by hand — but each is a support cost with no upstream to escalate to. The practical support artifact is an internal note covering the three-command surface (lambo new, lambo edit, lambo list) plus the known failure signatures.

Scaling. It does not scale organizationally. Aliases and configuration live in one developer's home directory, invisible to the team, with no telemetry and no way to observe divergence. At three developers it is a convenience with divergent local configs; at thirty it is an unowned shared dependency. The scalable expression of the same benefit is a versioned installer package or shared script — same opinionated bootstrap, with a changelog and a compatibility story.

Failure modes, ranked by cost to detect.

• Silent skeleton drift — scaffold succeeds, breaks weeks later. Highest cost; mitigated only by pinning, re-validation, and keeping CI and onboarding off the tool.
• Quiet database failure — root password, unexpected socket path, or a missing Postgres client; project looks valid, fails on first query. Fix by creating the database manually and correcting .env.
• Non-TTY hang — blocks forever instead of failing. Highest blast radius if it ever reaches a pipeline; the mitigation is procedural, not technical.
• Re-run collision — database name defaults from the directory basename; orphaned databases and stale Valet links. Clean up with valet unlink plus a manual DROP DATABASE before retrying.
• Nested git init when scaffolding into a non-empty or already-cloned parent.
• Missing host binary — fails loudly, which is the good case.

Ramp-up. Near-zero: three commands, and lambo new --help on the pinned version is the source of truth for flags (they drifted across releases; do not read the README first). That near-zero ramp is the entire pitch — a demo, spike, workshop, or client kickoff gets a running, browser-openable, git-tracked app in a Valet-linked minute. Measure that against the time-to-first-commit baseline and treat the result as a data point on where onboarding friction actually lives. Then close the evaluation, keep the wrapper, and let the tool go.

Verdict: reference, not investment. Permit it as a pinned, opt-in individual convenience for Valet users, do not adopt it as a standard, and spend a small bounded effort reproducing the useful steps in something we version and own.