Sail Lite Laravel Package

Product Decisions This Supports

• Developer Velocity for PHP Packages: Enables teams to spin up isolated PHP development environments in minutes (vs. hours for custom Docker setups), accelerating iteration for standalone libraries, CLI tools, or Laravel add-ons. Aligns with roadmap items like "Reduce package development time by 40%" by eliminating Docker configuration debt.
• Build vs. Buy for Local Dev Tools: Justifies adopting a pre-built solution over maintaining custom Dockerfiles, reducing technical debt and freeing engineers to focus on core package logic. Cost-benefit: ~$0 vs. 10+ dev-hours/year for in-house Docker maintenance.
• Consistency Across Projects: Standardizes PHP versions (7.2–8.5), extensions (e.g., xDebug), and permissions across all PHP packages, reducing "works on my machine" issues. Supports initiatives like "Unified local dev environments" for multi-package repositories.
• Use Cases:
  • Laravel Package Development: For teams building spatie/laravel-*-style packages (e.g., auth, payments) without full Laravel app dependencies.
  • PHP CLI Tools: Ideal for packages like laravel-shift/blueprint or custom Artisan commands.
  • CI/CD Local Testing: Replicates CI environments locally (e.g., PHP 8.5) to catch compatibility issues early.
  • Onboarding: Reduces ramp-up time for new contributors by providing a pre-configured sail CLI (e.g., sail up vs. manual Docker steps).

When to Consider This Package

• Adopt When:

  • Your team develops PHP packages (not full Laravel apps) and needs a Docker alternative lighter than Laravel Sail.
  • You prioritize minimalism: No databases, queues, or Node.js (unlike Sail), and your package doesn’t require them.
  • You want PHP version flexibility (7.2–8.5) without manual Dockerfile edits—control via docker-compose.yml or .env.
  • Your workflow involves frequent local testing of package compatibility across PHP versions (e.g., for Laravel 10+ support).
  • You’re tired of Docker Compose verbosity (e.g., docker compose exec -u sail dev bash → sail bash).
  • Your package targets local development only (not production deployment; use Docker/Kubernetes there).

• Look Elsewhere If:

  • You’re building Laravel applications: Use Laravel Sail for its database, queue, and Node.js support.
  • You need advanced services (Redis, PostgreSQL, Elasticsearch): Extend this package or use Docker Compose directly.
  • Your team lacks basic Docker comfort: Requires familiarity with CLI commands (sail up, sail shell).
  • You need multi-container setups: This is a single-container (PHP-only) solution.
  • Your package requires specific PHP extensions not pre-configured (e.g., pdo_pgsql, gd): Customize via sail publish or add them manually.
  • You’re using Windows without WSL2: Limited support (tested on macOS/Linux/WSL2).

How to Pitch It (Stakeholders)

For Executives: "Sail Lite is a force multiplier for PHP package development. By replacing manual Docker setups with a single sail command, we’re cutting onboarding time by ~75% for new contributors and reducing ‘environment setup’ bugs by 60%. For every package we build—like [ExamplePackage]—we save 2–4 hours per developer per sprint. It’s the ‘Laravel Sail for packages’, but stripped down to just PHP, xDebug, and assertions—no bloat. This directly supports our goal to ship 30% more packages annually without adding headcount."

Key Metrics to Track:

• Dev Onboarding Time: Target <30 mins to first sail up (vs. current 2+ hours).
• Package Compatibility Issues: Reduce CI-local mismatches by 50% (via PHP version parity).
• Engineer Productivity: Reclaim 10+ hours/week from Docker maintenance.

For Engineering: *"This replaces our custom Dockerfiles with a maintained, minimalist solution. Here’s why it’s a win:

• Consistency: Every dev uses the same PHP version (e.g., 8.5) via .env, no more ‘it works on PHP 8.2’ debates.
• Speed: sail up spins up a dev container in <30 seconds (vs. 5+ mins for manual Docker Compose).
• Extensibility: Need to tweak PHP settings? sail publish drops Dockerfiles in /docker for customization.
• CI Synergy: Matches our CI’s PHP runtime, eliminating ‘works locally but not in CI’ bugs.
• Tradeoffs:
  • No databases/Node.js: Intentionally minimal—we’re not building Laravel apps here.
  • Docker required: But that’s a hard dependency for modern PHP dev anyway.

Example Workflow:

# Clone repo → ready to code in 1 minute
git clone git@github.com:your/package.git
cd package
composer install
./vendor/bin/sail install
sail up -d
sail bash  # Now you’re in a PHP 8.5 container with xDebug!

For PMs/Tech Leads: *"Use this to:

1. Standardize local dev environments across all PHP packages (e.g., PHP_VERSION=8.5 in .env).
2. Accelerate package prototyping: Spin up a new package in <5 minutes (vs. 1+ hour with custom Docker).
3. Reduce support tickets: ‘It works on my machine’ issues drop by ~40% with consistent Docker setups.
4. Align with CI/CD: Ensure local PHP versions match CI (e.g., GitHub Actions), catching issues early.

When to Avoid:

• If your package requires databases/Node.js, pair this with Docker Compose or use Laravel Sail.
• If your team hates Docker, this isn’t the solution—push for better docs or a VM alternative."*