React Child Process Promise Laravel Package

Product Decisions This Supports

• Feature feasibility for non-blocking work: this package lets a ReactPHP-based service spawn an OS child process and receive a promise for its output/exit status, so long-running shell work (image/video transcoding, PDF rendering, git, mysqldump, legacy sync PHP scripts) runs outside the event loop instead of stalling every in-flight request. That directly gates whether we can offer features like async exports, thumbnail generation, or on-demand report builds without a separate worker tier.
• Build vs. buy vs. borrow: the package is a thin ergonomic layer (~a promise adapter over react/child-process). The real decision is not "adopt this?" but "do we take a 50-line dependency or write the 50 lines ourselves?" Treat it as a reference implementation first, a dependency second.
• Architecture boundary: it encourages modeling subprocess execution as an isolated, replaceable unit. That supports a roadmap decision to isolate memory-hungry or crash-prone workloads (short-lived children) rather than hardening a long-running monolith.
• Scoping the async platform investment: discovering this package usually means we're evaluating the WyriHaximus ReactPHP family (react-child-process-pool, -messenger, -closure). Whether we need concurrency limits, structured IPC, or just fire-and-forget output capture is a scope decision the PM should own before engineering picks a library.
• Use cases it fits: CLI wrappers, per-task sandboxing, fan-out of CPU-bound jobs at low volume, and bridging existing synchronous scripts into an event-driven service.
• What it does not decide: it is internal plumbing with no user-visible surface. It should never appear in a customer-facing roadmap, and its health metrics should not be allowed to gate a feature on their own.

When to Consider This Package

Consider it when all of the following hold:

• You are already committed to ReactPHP (event loop, promise semantics, react/child-process in the dependency graph) — otherwise the promise layer buys you nothing.
• Your need is genuinely small: spawn a process, collect stdout/stderr, resolve on exit. No queue, no retry policy, no concurrency ceiling.
• You are comfortable vendoring or version-pinning an effectively unmaintained dependency: last release 2020-12-04, ~12 stars, 0 dependents. That is a personal utility extracted from the author's monorepo, not a validated ecosystem component. Budget for "we own this code now."
• The blast radius is contained — an internal service, not a customer-facing critical path.

Look elsewhere when:

• You are not on ReactPHP. Use symfony/process behind a queue (Laravel Queue, Symfony Messenger, SQS) — simpler, maintained, and gives you retries and observability for free.
• You need maintained async process control. amphp/process is actively developed, has real adoption, and supports cancellation and structured I/O; spatie/async covers the fork-pool case. Either is a safer long-term bet.
• You need concurrency limits, pooling, or structured IPC. Step up to wyrihaximus/react-child-process-pool / -messenger, or better, use a real queue — subprocess-per-task does not scale to high throughput and gives you no backpressure.
• You need operational guarantees (timeouts, kill semantics, resource caps, per-task telemetry). None of that ships here; you would be building it.
• Zero-dependency-risk is a hard requirement (regulated, security-reviewed, or long-lived products). Reimplement the wrapper in-house so the maintenance obligation is explicit rather than inherited from a stalled repo.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed utility that lets our PHP service hand heavy or risky work to a separate operating-system process instead of tying up the request loop — the kind of change that improves responsiveness without adding infrastructure. The honest caveat is longevity: the library has had no releases since 2020, ~12 stars, and no downstream dependents, so it carries "we may have to maintain this ourselves" risk. That risk is acceptable only behind our own internal interface and confined to a single service. Recommendation: do not treat it as a strategic dependency, and do not let it anchor a platform bet.

For engineering: It is a promise adapter around react/child-process — spawn, collect stdout/stderr, resolve on exit. Roughly a few dozen lines. Adopt it only if we're already on ReactPHP and want the ergonomics today; otherwise copy the pattern (or use amphp/process) and own the code. Regardless of choice, wrap it in our own ProcessRunner interface so the underlying library is swappable, pin the exact version, and add our own timeout, kill, and logging behavior — the package provides none. If throughput, pooling, or IPC enters the picture, escalate to a queue rather than adding more sibling packages.