Promise Laravel Package

Product Decisions This Supports

• Feature scoping for I/O-bound workflows. The package enables promise-style chaining and deferred resolution in plain PHP, which maps directly to features like multi-provider API aggregation (e.g., pulling quotes, inventory, or shipping rates from 3–5 services in one request), dashboard fan-in, webhook fan-out, and enrichment steps inside queue jobs.
• Build vs. buy vs. use-native. It forces an explicit decision on your async orchestration layer: adopt a small third-party promise primitive, standardize on Laravel’s own tooling (Concurrency facade, Http::pool()), or build an internal helper. This is a low-cost decision to evaluate and a high-cost one to get wrong later, since promise semantics leak into every call site.
• Roadmap input on performance work. If latency budgets are dominated by sequential outbound calls, this package is a candidate tactic in a “reduce p95 latency without adding infrastructure” initiative — cheaper than introducing Swoole, RoadRunner, or a message bus.
• Architecture guardrails. Because the library is framework-agnostic and unopinionated, adopting it implies a decision to wrap it behind an internal interface (e.g., a BatchRunner contract) so the underlying implementation can be swapped for Laravel-native concurrency or amphp without rewriting feature code.
• Dependency-risk policy. With zero stars and zero dependents, this is a live test case for your third-party dependency criteria — useful for calibrating how the team treats low-adoption packages generally.

When to Consider This Package

Consider it when:

• You are already inside, or interoperating with, the Windwalker ecosystem, where conventions and support already exist.
• You need Promises/A+ style semantics (then, catch, finally, all, race) in a codebase that is not running an event loop, and you want a dependency with a small surface area rather than pulling in ReactPHP or amphp.
• You are hardening a legacy PHP 7.x/8.x service where adding a full async runtime is out of scope, and the goal is simply to stop writing sequential blocking calls in a handful of hot paths.
• You can isolate the dependency behind your own abstraction and accept ownership of patching it if upstream goes quiet.

Look elsewhere when:

• You are on Laravel 11+ — Concurrency and Http::pool() cover the common cases with first-party support, testing utilities, and no added dependency.
• Guzzle is already in the stack — its promise implementation is battle-tested, widely depended upon, and integrates with the HTTP client your team already uses.
• You need true parallelism or a real event loop — ReactPHP, amphp, Swoole, or Laravel Octane are the right tools; a promise library alone does not create concurrency.
• Supply-chain review is a gate. Zero stars, zero dependents, and a single maintainer mean no community backstop, no CVE-watch attention, and no realistic expectation of timely fixes. That is disqualifying for payments, auth, or anything on a compliance boundary.
• Your team is unfamiliar with promise semantics and would inherit callback-style complexity without a strong reason — the debugging and stack-trace cost is real.

How to Pitch It (Stakeholders)

To executives: This is a small utility library, not a platform bet. It would let us parallelize slow outbound API calls inside existing PHP request and job lifecycles — a latency win with no new infrastructure. However, it has effectively no adoption (no stars, no downstream dependents, single maintainer), which means we would own its maintenance in practice. My recommendation is to treat it as an evaluation candidate, not a commitment: benchmark the native Laravel concurrency options first, and only adopt this if they fall short. Cost to trial is a few engineering days; cost of an unmaintained critical-path dependency is materially higher.

To engineering: The API is the familiar Promise/Deferred model — then/catch/all — framework-agnostic and small enough to read in an afternoon. It does not give you a scheduler or event loop; it structures composition over non-blocking work you already have (Guzzle async, stream sockets, queue fan-out). Two asks before we adopt: (1) confirm the Laravel 11 Concurrency facade and Http::pool() don’t already cover our target use cases, and (2) if we proceed, wrap it behind an internal contract with contract tests so swapping to Concurrency, Guzzle promises, or amphp later is a one-file change rather than a refactor. We should also pin the version and document the fallback plan given the maintenance profile.

Bottom line: Low opportunity score, low risk to evaluate, moderate risk to depend on. Run a time-boxed spike against native Laravel options; default to first-party unless the spike shows a clear gap.