What this work needed to become.
Laravisor brings everyday development operations into one keyboard-driven workspace. It recognizes Laravel through composer.json and can discover the application server, Vite, queues, Horizon, Reverb, Artisan commands, quality tools, and logs.
A local .laravisor.json file can disable defaults, add custom processes or tools, and adapt the workspace to the project rather than forcing one fixed setup.
The hard part was in the edges.
A Laravel development session often spans several terminals: long-running processes, logs, tests, formatting, static analysis, and code generation.
The goal was to reduce that context switching while preserving the transparency and control developers expect from their terminal.
Constraints that shaped the solution
- Projects can use different process managers, queues, quality tools, and local environments.
- Child processes must stop cleanly and avoid becoming orphaned.
- Unexpected exits need bounded restart behavior instead of tight failure loops.
- The interface must remain responsive while streaming several outputs.
Choices made explicit.
The implementation follows from these boundaries. Each choice solves one problem while accepting a clear trade-off.
Use Bubble Tea
The Elm-style update model keeps terminal interaction predictable while Lip Gloss provides a restrained visual system.
Prefer convention, allow overrides
Useful Laravel defaults appear automatically, while project configuration can disable, replace, or extend every category.
Own shutdown explicitly
Managed processes receive SIGTERM first and escalate to SIGKILL only after a timeout, avoiding immediate destructive shutdown.
Bound restart pressure
Never, on-failure, and always policies use exponential backoff capped at sixty seconds to prevent runaway restarts.
Useful, shipped, and honest about its limits.
Laravisor reached v1.1.0 with release archives and checksums for macOS and Linux on amd64 and arm64. The latest build, test, vet, and release workflows completed successfully.
It provides a useful foundation for a more polished developer tool: the process model and distribution are in place, while documentation remains the clearest next investment.
What I would carry forward.
A good developer tool must earn trust twice: through predictable runtime behavior and through documentation that lets users understand installation, configuration, and failure modes before they run it.
The next public milestone should add a comprehensive README, terminal recording, explicit license file, and documented configuration examples.