Lambo Laravel Package

Getting Started

Install pinned, globally, never as a project dependency.

composer global require tightenco/lambo:3.1.1

Lambo is archived (last release 2023-08-08), so 3.1.1 is the last thing you'll ever get. Pin it explicitly rather than letting Composer float. Ensure the global vendor bin directory is on PATH (~/.config/composer/vendor/bin on modern Composer, ~/.composer/vendor/bin on older setups), then verify the three binaries Lambo shells out to actually exist:

which laravel   # Lambo wraps this — it determines your skeleton version
which valet     # link / secure / open steps
which mysql     # database creation step
lambo list      # smoke test that the binary runs

First run — from a parent directory, not inside an existing project:

cd ~/Code
lambo new blog

Answer the prompts (database name, dev server, testing framework, run migrations, install Node deps, open editor/browser). The value is the composite result: scaffolded app, created database, Valet-linked .test host, git init plus a first commit, migrations run, editor and browser open.

Where to look first, in order — not the README:

1. lambo new --help on your installed version (flag sets drifted between releases; your local --help is the source of truth for what you pinned)
2. lambo edit — the global config file that backs every prompt
3. The README's alias workflow, last

The use case worth adopting it for: a demo, spike, workshop, or client kickoff where you need a running, browser-openable, git-tracked Laravel app in under a minute — on macOS, on Valet, on the Laravel version the 2023 release was built against. Nothing that needs reproducibility, CI, or a shared environment baseline.

Implementation Patterns

Configure globally once — this is the highest-leverage move. lambo edit opens the global config file (shell-sourced assignments mirroring the CLI flags). Fill in editor, default database driver, run-migrations, npm-install, open-browser, secure-by-default. After that, lambo new x becomes near-zero-prompt. Lambo shifts from "interactive wizard" to "one-word command."

Model project types as aliases, not per-project flags. At the end of a good interactive run Lambo offers to save the answers as a named alias; you can also reuse one with --alias and edit it later:

lambo new acme-portal --alias=client
lambo edit client          # redefines what "client project" means

Sensible alias set: client, spike, package-dev, pest. Each alias is a saved answer-set, so the invocation stays one word while the recipe stays inspectable.

Keep the recipe in the repo, not in dotfiles. Aliases live in one developer's home directory — invisible to teammates, unversioned, and gone when the laptop is. If a scaffold recipe matters to the team, encode it in a checked-in script that calls Lambo with explicit flags so it's reviewable and diffable:

#!/usr/bin/env bash
set -euo pipefail
lambo new "$1" --alias=client "${@:2}"
cd "$1" && git commit --allow-empty -m "Scaffold: internal baseline"

This is also the pattern that survives Lambo's death: the script is yours, the tool behind it is swappable.

Chain post-create work explicitly. Lambo stops at "running app." Anything team-specific — an internal package, a CI config, baseline seed data, a PHPStan config — belongs in a script that runs after it, not in a hope that Lambo does it:

lambo new acme-portal --alias=client && (cd acme-portal && ../../tooling/bootstrap-client.sh)

Non-interactive invocations. Pass explicit flags (plus whatever force/quiet flag your version exposes) so no prompt blocks. Fine for scripted local use; never in CI — see Gotchas.

The daily surface is three commands. lambo new, lambo edit, lambo list. Treat lambo edit as the settings screen and lambo new --alias=… as the workhorse. That's the whole tool — which is both why it's pleasant and why a 50-line shell script can replace it.

Compare before you commit. Run laravel new side by side once. The modern installer already prompts for starter kit, testing framework, and database, and initializes git. If Lambo's remaining delta (Valet link/secure/open, host-level DB creation, editor launch) isn't worth an unmaintained dependency for you, you've learned that cheaply.

Gotchas and Tips

Archived means silent divergence — treat it as the headline risk. Lambo shells out to the globally installed laravel binary. When the installer's flags or the skeleton change, Lambo either fails loudly (good) or produces a scaffold that looks fine and breaks weeks later (bad). Realistically it's a Laravel 10-era tool; Laravel 11's trimmed skeleton and reworked starter kits are outside what its release was tested against. Re-verify against a hand-rolled laravel new whenever you bump PHP or Laravel.

It is Valet-shaped. valet link, valet secure, and valet open are baked into the flow. Herd users get redundant work; Sail/container users get actively wrong work (host-level database creation, hostname linking); Linux/Windows/WSL are effectively unsupported. Restrict it to Valet machines or skip it.

Prompts hang in non-TTY contexts. Any CI runner, Docker build, or ssh without -t blocks forever rather than failing. Never put Lambo in a Dockerfile, a CI-invoked Make target, or a provisioning script.

Database creation fails quietly and confusingly. The step shells out to the local MySQL client with default assumptions. If root has a password, the socket path isn't what Lambo expects, or you're actually on Postgres, the DB step fails while the rest of the scaffold proceeds — leaving a project whose .env points at a database that doesn't exist. Symptom: migrations "passed" in the prompt but the app 500s on first query. Fix: create the DB manually, then correct .env.

Repeated runs collide. The database name defaults from the project directory name, so two projects with the same basename (or a retry after a failed run) leaves orphaned databases and stale Valet links. Clean up with valet unlink and a manual DROP DATABASE before retrying.

Editor launch silently no-ops when neither LAMBO_EDITOR nor EDITOR is set. This is the single most common "Lambo did nothing" report — set it in your shell profile.

git init inside a non-empty directory (a freshly cloned parent, a monorepo) creates a nested repo instead of failing. Scaffold into a clean parent directory.

Debugging: raise verbosity and read the shell commands. It's a Laravel Zero app, so -v/-vvv expose the underlying commands each step runs. When something fails, copy those lines and run them by hand — faster than reasoning about the wrapper.

Extension points are config and aliases, full stop. No plugin API, no hook system, no equivalent of laravel new --using. Anything beyond config + aliases is a wrapper script or a fork. Given the archived status, prefer the wrapper.

Exit path, planned now: reimplement the load-bearing steps as a private laravel new --using installer package (versioned, testable, owned) or as bin/new-project in shared tooling. Same standardization benefit, plus a changelog and a compatibility story. Exit cost today is effectively zero — keep it that way by never referencing Lambo from composer.json, from onboarding docs marked "required," or from CI.