Yolo Alpha Laravel Package

Getting Started

codinglabsau/yolo-alpha is a pre-1.0 package, so treat everything below as "verify against the README for the exact tag/command names" — but the shape of the day-to-day workflow is stable across the alpha line.

1. Install as a dev dependency. It is tooling, not runtime code:

   composer require --dev codinglabsau/yolo-alpha:1.0.0-alpha.38
   

   Pin the exact alpha. ^1.0@alpha will silently move you across releases that change FPM/ini defaults (see v1.0.0-alpha.38 below).

2. Publish the config before your first run. Do not edit anything under vendor/. The published config is where the PHP-FPM pool settings, ports, document root, and ini overrides live:

   php artisan vendor:publish --tag=yolo-config
   

3. Start it. The release notes reference a start command, which is the entry point you'll use every day:

   php artisan yolo:start
   

4. First use case: replace the hand-rolled php -S / Valet / Sail setup for a single Laravel app. Boot it, hit the app in a browser, confirm /storage/logs/laravel.log and the FPM error log are both being written, then immediately check php -i | grep -E 'upload_max_filesize|post_max_size' inside the running process so you know what you actually got.

The very first thing to validate on any project is the FPM request-size ceiling, because that is the setting alpha.38 just changed.

Implementation Patterns

Per-project override, not per-machine edits. Keep the published config in the repo and set the limits explicitly there so every developer and every CI runner gets identical FPM behaviour. Machine-local tweaks go in .env-driven config values, not in a hand-edited pool file.

Match the FPM limits to the app's real upload surface. If you have a media library, CSV import, or avatar uploader, set upload_max_filesize / post_max_size in the published config to your app's documented maximum plus headroom, and set post_max_size a few MB above upload_max_filesize so multipart overhead doesn't truncate the request. Then mirror that number in your FormRequest max: rules so validation and infrastructure agree.

CI / test-server pattern. Boot the server in the background, poll a health endpoint until it responds, then run your browser/Dusk/Pest tests against it, and always tear it down in a finally or a trap handler. Do not assume the process is up the instant the command returns.

php artisan yolo:start > /tmp/yolo.log 2>&1 &
until curl -sf http://127.0.0.1:8000/up > /dev/null; do sleep 1; done
php artisan test

One server per worktree. Alpha tooling in this space tends to bind a fixed port. If you run multiple checkouts in parallel, make the port configurable and set it per worktree rather than killing each other's processes.

Log routing. Point the FPM error log at storage/logs/ so a single tail covers both PHP-FPM startup failures and application exceptions. Startup failures (bad pool config, missing socket dir) otherwise surface only as a blank 502.

Gotchas and Tips

v1.0.0-alpha.38 lowered the FPM request size limits to 12M/10M. This is a small diff with an outsized blast radius: it is a behavioural breaking change for any app whose uploads previously worked. Concretely:

• post_max_size = 12M and upload_max_filesize = 10M means any single file above 10MB is rejected by FPM, before Laravel sees it.
• When a request exceeds post_max_size, PHP does not raise a catchable exception — $_POST and $_FILES simply arrive empty. Your controller then fails on a missing field or a "file is required" validation message, which sends you hunting in entirely the wrong place. Learn to recognise that symptom as "request body was dropped."
• The Laravel-side max: validation rule and the upload_max_filesize ini setting are different layers. Tightening or loosening max: will never fix an FPM-level rejection.
• If your app legitimately accepts large files, override both values in the published config and add a smoke test that uploads a file just over the boundary.

Debugging checklist when a request misbehaves:

php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit'
# confirm the values the *server* process is using, not your CLI

Also check the FPM error log for POST Content-Length ... exceeds the limit — that line is the smoking gun for the case above.

Silent-config trap. If you change the published config and nothing changes, you are probably looking at a cached/generated pool file. Clear it and restart; a stale generated conf is the most common "my config is ignored" cause with this class of tooling.

Alpha discipline. At alpha.38 the config schema is still moving. Pin the version in composer.json, commit composer.lock, and read the changelog before bumping — releases like this one ship as a one-line "fix" but alter defaults you may be depending on. Don't run this on production infrastructure; keep it in require-dev and out of the deployed artifact.

Extension points worth knowing: the published config (limits, ports, document root, ini overrides) is the supported surface; anything deeper — custom FPM pool templates — is vendor-patching and will break on the next alpha. If you need a genuinely different server topology, wrap the start command in a project script rather than forking the package.