Tall Install Laravel Package

Getting Started

ralphjsmit/tall-install is a one-shot scaffolder, not a runtime dependency. There is no meaningful "day-to-day" usage in a running application — the realistic workflow is: run it once to bootstrap a TALL-stack app, commit the result, and own the generated code from that moment on. Everything below assumes that framing.

Minimal path:

1. Confirm the entry point before anything else. The package is archived (last release 2022-04-29), so the README may not match reality. Read composer.json for type and bin, and src/Console/*.php for the command $signature. Expect one of two shapes: a Composer project you scaffold via composer create-project ralphjsmit/tall-install my-app, or an Artisan/global command you run inside a fresh Laravel app (e.g. php artisan tall-install). Don't guess — the invocation differs and only one will work at your pinned versions.
2. Pin your toolchain first. Note the PHP, Composer, Node, and npm versions in the sandbox README. The installer shells out to Composer, npm, and Artisan; a Node 14-era package.json against Node 20+ is a classic silent failure.
3. Scaffold into a throwaway directory, never an existing app. This is not retrofittable and the prompts assume a greenfield Laravel skeleton.
4. git init && git add -A && git commit the instant it finishes — before you run npm install or touch anything. That single commit is your diff base for every later "what did it actually generate vs. what did it promise?" question.
5. Answer the prompts deliberately. Release 1.4.0 made the command interactive, so the optional package set (auth, admin, testing, formatting, static analysis) is a per-run decision, not a fixed list. Write down your answers; you will need them to reproduce the scaffold.

First use case: an internal admin panel or CRUD MVP. After the run, do a five-minute smoke test before celebrating:

php artisan about                 # framework + env sanity
php artisan migrate --seed        # does the generated schema actually run?
npm install && npm run build      # does the generated Tailwind pipeline compile?
php artisan route:list            # is auth/login routing wired?

Then create one throwaway Livewire component and one Alpine x-data block in the generated layout. If both work, the wiring is real. If Alpine throws Alpine Expression Error, the frontend integration is half-baked and you've found it in five minutes instead of five days.

Implementation Patterns

Pattern 1 — Sandbox spike, then mine it. Run the installer into /tmp/tall-spike, commit, and diff composer.json, package.json, tailwind.config.js, vite.config.js, resources/js/app.js, and resources/views/layouts/app.blade.php against a bare laravel new app. That diff is the product. Extract it into a checklist doc; you now have the package's opinionated defaults without the dependency.

Pattern 2 — Promote to an internal starter repo. If the defaults are good, fork (MIT permits it) into acme/tall-starter, pin versions, name an owner, and add a CI job that runs composer install, npm ci, npm run build, php artisan test. Teams then use composer create-project acme/tall-starter — one maintained baseline, no template drift, no archived dependency.

Pattern 3 — Scripted replacement for the interactive command. Interactive prompts are unusable in CI, containers, or onboarding scripts. Don't try to drive it with yes |; instead read src/Console/ for the exact package list and prompt branching, then codify it as an idempotent shell script in your starter repo:

composer require livewire/livewire:^3.0
npm install -D tailwindcss @tailwindcss/forms alpinejs
# ...mirror the installer's steps explicitly, in a script you own

You get reproducibility and a readable record of why each package is there.

Pattern 4 — Day-to-day work lives in the generated app. Once scaffolded, write components the ordinary way: php artisan make:livewire Users/Index, a Blade view with wire:model.live, and Tailwind classes inline. Use Alpine for purely local UI state (x-data="{ open: false }"), Livewire for anything that touches the server. Keep that boundary clean — mixing wire: and heavy x- state machines is the most common TALL maintenance problem.

Pattern 5 — Upgrade as a project, not a command. The generated app targets Laravel 9 / Livewire 2 / Tailwind 3-era conventions. Modernizing means livewire/livewire:^3, @livewireStyles removal, wire:model → wire:model.live where you need eager updates, and Tailwind 3 → 4 config migration. Do it on a branch, one dependency per commit, with composer audit and npm audit gating each step.

Integration tips: verify config/auth.php points at the right App\Models\User (that exact fix landed in 1.4.0 — if you rename or move the model, update it again). Check tailwind.config.js content globs cover any directory you add later. Remove the installer from require-dev after scaffolding — it is ephemeral tooling and should not ship.

Gotchas and Tips

• Archived means every bug is yours. No upstream fixes for framework incompatibility, CVEs, or the Laravel skeleton drift that has occurred since 2022. Budget for it or don't adopt it.
• Interactive = not automatable. In non-TTY contexts the command may hang or take unintended defaults. Never put it in a Dockerfile, CI pipeline, or post-create-project-cmd.
• Mid-install failure leaves a dirty directory. Composer, npm, and Artisan all run sequentially; a failure at step four leaves you with a half-wired app and no rollback. Always scaffold into a fresh, git-initialized directory so git clean -xfd is your reset.
• Skeleton coupling is the biggest failure mode. Newer Laravel skeletons swapped Mix for Vite, changed the auth scaffolding, and streamlined config. Expect broken asset wiring, duplicate toolchains, or missing routes/auth.php. Diff the generated structure against your target Laravel version before blaming the package.
• Double Alpine. If the scaffold npm-installs alpinejs and you also run Livewire 3 (which bundles Alpine), you get duplicated initialization and cryptic expression errors. Pick one: import Alpine yourself and call Livewire.start() after, or drop the manual import entirely.
• Stale Tailwind content globs. Adding resources/views/admin/** and seeing unstyled markup is almost always a missing content entry, not a build failure.
• Build output in .gitignore. Release 1.4.0 explicitly added build files to GitIgnore — confirm your deploy pipeline actually runs npm run build, or you'll ship an unstyled app.
• Debugging: run with -vvv for the Composer phase, then inspect the actual composer.json/package.json rather than trusting the prompt summary. Check storage/logs/laravel.log for Artisan-phase errors.
• Verify versions, not intentions. After the run, run composer outdated --direct and npm outdated. The output tells you how far behind the baseline is and whether a fork is a weekend job or a quarter.
• Extension point is your fork, not the package. There's no plugin API. Keep a CHANGELOG.md in your starter repo listing every divergence from the original scaffold so future maintainers know what's inherited versus deliberate.