Porter Laravel Package

Technical Evaluation

Architecture fit. Porter is a dev-only Laravel package: a service provider registers an Artisan entrypoint that wraps php artisan serve and supervises a set of child processes (queue worker, Vite, Reverb, log tail, custom commands) declared in config/porter.php. Architecturally it is a thin orchestration layer over Symfony Process — no database, no runtime services, no production surface area. It slots into the "developer tooling" layer of a Laravel stack rather than the application layer, which means it cannot destabilize production behavior. The main structural question is whether it duplicates capability the team already has: Laravel Sail, concurrently, Procfile runners, or a composer dev script (Laravel 11+ ships one by default) all solve the same problem.

Integration feasibility. Low effort: composer require --dev anystack-sh/porter, publish config, optionally add presets. No changes to application code, no schema, no CI prerequisites. Friction points are version constraints (PHP and Laravel range pinned at the 2023 release) and the fact that it is a require-dev dependency, so it must be excluded from production installs (--no-dev) — standard, but needs to be enforced in the Docker build.

Technical risk. Two distinct risks, with very different weights:

• Runtime risk (low). Process spawning, signal forwarding, and shutdown cleanup are the hard parts; failures manifest as orphaned workers or ports held after Ctrl+C. Annoying, not damaging.
• Maintenance risk (moderate-to-high). Last release 2023-05-15 with a single-maintainer bus factor and 531 stars — healthy interest but not a large community. Two years of Laravel major releases have shipped since; unverified compatibility with Laravel 11/12 and PHP 8.3/8.4 is the gating concern. Opportunity score (3.02) is consistent with a tool that improves individual ergonomics but has no leverage on product capability.

Key questions. (1) Does it install and run cleanly on Laravel 11/12 with our pinned PHP version? (2) Is signal propagation and process cleanup reliable on macOS, Linux, and WSL2 — and is Windows supported at all? (3) Can preset definitions be committed to the repo and shared, or are they developer-local? (4) What is the fallback if a Laravel upgrade breaks it — is removal a one-line composer change? (5) Does it conflict with Sail, Herd, or an existing composer dev script? (6) Is output interleaved with prefixes or dumped raw, and does that impede debugging?

Integration Approach

Stack fit. Good fit for a conventional Laravel monolith on Docker/Sail or native PHP where developers routinely need three to five concurrent processes. It fits poorly where Sail/docker compose already defines the process topology, since Porter would be a second, competing source of truth for "what runs."

Migration path. Additive and reversible. Ship it as an opt-in: composer require --dev, commit config/porter.php with team presets (--with-queue, --with-vite, --with-logs), document the invocation in the README, and leave existing composer dev / Sail workflows untouched. Removal is a single composer remove --dev plus a config deletion — a genuinely zero-lock-in decision, which lowers the cost of a failed pilot.

Compatibility. Verify against the matrix we actually support: Laravel 10/11/12 × PHP 8.1–8.4 × macOS/Linux/WSL2. Do not assume; the release date makes the constraint block suspect. Confirm --no-dev production builds exclude it and that no service provider is auto-discovered in a way that errors when absent.

Sequencing. (1) Spike — one engineer, half a day, on the current Laravel version. (2) If clean, pilot on one or two repos for a sprint. (3) Collect developer feedback against the incumbent composer dev script. (4) Decide: adopt as standard, keep as optional, or drop. (5) If adopted, pin the version and add a note to the Laravel-upgrade runbook flagging Porter as a known-breakage candidate. Gate the whole thing on step 1 — do not sequence documentation or onboarding work ahead of the compatibility check.

Operational Impact

Maintenance. Near-zero ongoing cost if it works, but it is an unmaintained-by-proxy dependency: we inherit the burden of validating it against every Laravel and PHP upgrade. Budget a small recurring check at each framework bump, and a fork-or-drop decision if it breaks and upstream is silent. Pin the version exactly; do not float.

Support. No vendor SLA, no commercial backing, community issues only. Internal support burden is genuinely low because failure is visible and local — a developer notices immediately and can fall back to separate terminal tabs. Do not route this through platform/DevOps; it is a developer-environment concern owned by the team using it.

Scaling. Scales linearly with headcount at effectively zero marginal cost — each developer runs it locally, no shared infrastructure, no coordination. The real scaling limit is heterogeneity: the more varied the local setups (Herd, Sail, native, Windows), the more presets and documentation diverge, and the weaker the case for a single mandated tool.

Failure modes. Orphaned child processes after an unclean exit consuming ports (Vite 5173, queue workers); signal-handling gaps leaving workers running invisibly; interleaved stdout making errors hard to attribute; hard failures on unsupported PHP/Laravel combos after an upgrade; silent divergence from Sail's containerized environment, so developers test a different topology than CI. Mitigate with a documented kill/cleanup command and an explicit "known limitation" section.

Ramp-up. Under an hour for a Laravel-fluent developer; it is configuration, not architecture. The cost is documentation and habit change, not training. Expect partial adoption unless the team standardizes on it, and treat partial adoption as an acceptable outcome given the reversibility.