Process Bundle Laravel Package

Technical Evaluation

Framing correction: despite being scoped as a "Laravel/PHP package," spipu/process-bundle is a Symfony bundle. Its value is almost entirely in Symfony-specific glue — a DI extension and configuration tree, console commands, event subscribers, and (in the typical pattern for this author's bundles) an optional persistence layer for process state. None of that glue transports to Laravel. The only transferable asset is the underlying symfony/process component, which Laravel already pulls in transitively and which we can call directly with no dependency at all.

Architecture fit: Poor for a Laravel estate. Adopting this package would mean either (a) standing up Symfony kernel plumbing inside a Laravel app — a persistent, high-friction anti-pattern — or (b) treating the repository as a reference implementation and rebuilding its concepts natively. Only option (b) is defensible, and at that point we are not adopting a package; we are doing a small internal build informed by someone else's code. If the target platform were Symfony 6/7, the fit would be moderate: it addresses the real, recurring need to launch, track, and reap long-running child processes from inside a request/console context.

Integration feasibility: Low-to-moderate, and dominated by rewrite effort rather than integration effort. A Laravel-native equivalent is roughly a service provider, a config file, a facade or injectable manager, a jobs or custom processes table with a status state machine, a scheduled reconciler command, and signal/exit-code handling. That is a one-to-two sprint build for a mid-level engineer, and it produces something we own, test, and can instrument — which is the actual product requirement.

Technical risk:

• Supply chain: 0 stars, 0 dependents, single maintainer, composite score 19.5/100. Effectively zero external scrutiny of the code paths we would be running with shell execution privileges. This is the single largest risk and it is not mitigable by review alone at reasonable cost.
• Abandonment: no dependents means no downstream pressure to keep it current. Symfony major-version drift (and PHP minor drift) will strand it.
• Release metadata anomaly: the 2026-10-08 last-release date should be verified against the actual tag history — it may indicate a misconfigured tag, a squashed history, or stale repository metadata. Do not treat "recent release" as evidence of active maintenance until confirmed.
• Blast radius: process-spawning code runs with the application's OS privileges. An unmaintained dependency in that position is a standing security and stability liability.
• License: MIT is clean and imposes no obligations. This is the one unambiguously favorable signal.

Key questions for the maintainer/owner before any further investment:

1. Is the target runtime Laravel or Symfony? If Laravel, this evaluation terminates — the package is out of scope by construction.
2. What specifically does the bundle add over symfony/process alone: state persistence, concurrency limits, restart/backoff, log capture, UI? That inventory is the actual requirements list for a native build.
3. Is there test coverage, and does CI exercise real child processes or only mocks?
4. What are the composer.json constraints on PHP, symfony/process, and any Doctrine packages, and do they conflict with our locked versions?
5. Who is on the hook if this breaks in production, given zero dependents and no vendor?

Integration Approach

Stack fit: Not a fit as a dependency. It is a fit as a design reference. The correct posture is "read, don't require." I would not add this to composer.json under any configuration, including as a dev dependency, because the read is cheap and the dependency is not.

Migration path (recommended sequencing of the decision, not of code):

1. Spike (1–2 days). Clone, read the service definitions, the process manager, and the console commands. Produce a one-page capability inventory: what problem does it solve, what is the state model, what edge cases does it handle (timeouts, exit codes, orphan reaping, output capture, concurrency caps).
2. Gap analysis against our own need. Most Laravel teams asking for this actually need one of: queued jobs with Horizon/queue:work supervision, symfony/process invoked synchronously inside a job with a hard timeout, or Symfony Messenger. If a maintained primitive already covers 80% of the requirement, stop here.
3. Build thin, own it. If a genuine gap remains, implement a minimal internal wrapper: a ProcessManager contract, a SymfonyProcessRunner implementation, a processes table with pending/running/succeeded/failed/timed_out states, and a reconciler command scheduled every minute. This is a small, testable, instrumentable surface.
4. Reject-and-document. Record in the ADR why the package was evaluated and declined, so the question does not reopen in six months.

Compatibility: If a Symfony-based service is in scope, verify symfony/process major alignment, PHP ^8.x constraint, and any Doctrine ORM coupling — ORM-coupled bundles are the most common source of upgrade deadlock. In a Laravel context, compatibility is moot: nothing is installed, so nothing conflicts. That is the cleanest possible integration outcome and worth stating explicitly in the ADR.

Sequencing relative to delivery: This is a non-blocking, low-priority evaluation. It should not consume a sprint slot unless a concrete feature (bulk imports, PDF generation, media transcoding, report exports) is already blocked on background process orchestration. In that case, sequence the native build with the feature, not before it, and let the feature's acceptance criteria define the manager's API.

Operational Impact

Maintenance: Adoption transfers ownership to us in all but name. A zero-dependent, single-maintainer package means we are the de facto maintainers from day one, bearing Symfony upgrade work, PHP version work, and security triage. Even the "reference implementation" path carries a smaller version of this cost: someone must periodically re-read upstream to see whether it has solved something we have since solved worse.

Support: No vendor, no SLA, no community. Questions to the issue tracker are best-effort at a 0-star project. Internal escalation must route to whoever built the native equivalent, and that person needs to be named before the feature ships.

Scaling: The architecture implied by this class of bundle — one OS process per unit of work, supervised externally — scales horizontally only by adding worker capacity, and vertically not at all. Expect to need process supervision (Supervisor or systemd) independent of the package, a concurrency cap to avoid fork storms on shared hosts, and a strategy for output volume. Long-running PHP workers also accumulate memory; the reconciler and timeout logic are load-bearing, not nice-to-haves.

Failure modes to design against:

• Orphaned and zombie children after a PHP-FPM worker is killed mid-run — the reconciler must mark stale running rows as timed_out and attempt termination by PID, with PID-reuse guards.
• Silent failure: exit code captured, output discarded, job marked "done." Capture stderr and persist a tail of it.
• Deploy-time disruption: shipping new code while processes run. Decide explicitly whether running processes are killed, allowed to drain, or detached — and make it consistent with queue worker restart behavior.
• Table and log bloat from unbounded process history; needs a retention policy from day one.
• Privilege and input handling: any process launcher taking user-influenced arguments is a command-injection surface. Enforce array-form invocation, never shell strings.
• Timeout ambiguity: wall-clock vs. idle timeout. Pick one, document it, and make it configurable per process type.

Ramp-up: The API surface is small and the concept is familiar, so developer ramp-up is a half-day. The real cost is operational literacy: on-call needs to understand the state machine, how to read a stuck process, when to kill by PID, and how the reconciler interacts with deploys. Budget for a runbook, not just a README. Overall: 1–2 days to evaluate and decline-or-adopt, 1–2 sprints to build natively if adopted in spirit, and near-zero ongoing cost if declined — which is the outcome the signals point to.