Ticking Promise Laravel Package

Product Decisions This Supports

• Build vs buy for async plumbing. This is a single-purpose primitive: wrap one or more event loop ticks into a react/promise promise so callers can await a tick instead of hand-wiring a Deferred plus Loop::futureTick(). The buy decision is cheap and the build decision is also cheap, so the real question is "do we want one named, tested, versioned implementation instead of N hand-rolled copies."
• Test determinism as a product cost. It enables replacing usleep() and sleep() based waits in async test suites with deterministic tick awaits. Flaky CI is a recurring tax on delivery throughput; this is a direct lever on that tax.
• Deferral semantics for long-running processes. Supports features that need "run this after the current tick" rather than "now": deferred event dispatch, coalescing writes, batching log or metrics flushes, yielding to the loop inside a tight iteration so other work is not starved.
• Sequencing inside promise chains. For roadmap items that live on ReactPHP (daemon workers, webhook fan-out, stream processors, CLI services), it lets "yield to the loop" be expressed as an awaitable step in a chain instead of a callback side channel with implicit ordering.
• Stack standardisation. It informs whether to standardise on the broader WyriHaximus async tooling (async-test-utilities, test-utilities), of which this is typically a transitive dev dependency. That is an engineering-standards decision, not a product feature decision.
• What it does not support. It is not a feature enabler. It is substrate under features. No user-visible outcome traces back to it, so it should never appear on a roadmap or in a prioritisation session as a line item.

When to Consider This Package

Adopt when all of these hold:

• You actually run a ReactPHP event loop, either in production (daemon, worker, CLI service, long-running process) or in your test harness for async code.
• You are already on react/promise v3 and react/event-loop, since this adds no new runtime to the tree.
• You have a concrete call site: a test that currently sleeps, or a code path that needs a tick-await and is currently repeating a Deferred + futureTick block.
• You prefer a named, versioned primitive over an inline block copy-pasted across modules.

Look elsewhere when:

• The application is a standard Laravel request/response app with php artisan queue:work workers. There is no loop to tick. Nothing to leverage, and adding it would be cargo culting.
• You need delays or timeouts rather than ticks. Use react/promise-timer.
• You need recurring work. Use Loop::addPeriodicTimer directly.
• You need the full async testing toolkit. Use wyrihaximus/async-test-utilities, which is the higher-leverage entry point and likely pulls this in anyway.
• You are on Swoole, AMPHP, or Revolt/Fibers. Different concurrency model; this wraps React's loop specifically.
• You require a vendor with a support contract, an SLA, or a second maintainer on the pager.

Ownership reality check. Six stars, zero dependents on the package index, single-maintainer ecosystem, bus factor of one. Last release dated 2026-04-12 suggests an active cadence, but popularity is not the safety net here. The safety net is surface area: the code is small enough that forking or inlining it is an afternoon, not a quarter. That near-zero exit cost is precisely what makes adoption defensible.

Default recommendation: dev dependency only, adopted at the first concrete async test that sleeps. Do not promote it to production dependencies without a named production call site and an owner.

How to Pitch It (Stakeholders)

For executives (30 seconds): "A tiny MIT-licensed utility that lets our async code wait for the event loop to make progress instead of guessing with sleeps. It makes our async test suite deterministic, which means fewer false-red builds and less engineer time chasing flakes. The whole thing is one composer line and small enough to replace in-house in a day, so the downside is capped. We are not funding a dependency here, we are allowing one."

For engineering (60 seconds): "It turns event loop ticks into a promise, so you can await a tick instead of wiring a Deferred and calling futureTick yourself. Two uses: make async tests deterministic instead of usleep-based, and express 'let the loop breathe' as a step inside a promise chain. Requires react/promise and react/event-loop; adds no new runtime. If you are not on ReactPHP, ignore it entirely. If you are, add it as a dev dependency the first time you write a sleeping test, and use async-test-utilities if you want the broader harness rather than the single primitive."

What to explicitly not claim: that it improves performance, that it is a strategic dependency, or that adoption signals anything about the health of the wider async stack. It is a small correctness tool with a small blast radius in both directions.