- What is torann/promise used for in a Laravel application?
- It is a lightweight Promises/A+-style library that provides then() and catch() chaining, deferred resolve/reject, all() and race() helpers, a service provider and a facade. In a Laravel app its realistic role is organizing multi-step, synchronous request logic so success and failure paths stay flat instead of nesting try/catch blocks. It does not add real concurrency, because PHP-FPM executes a request on a single thread. Before adopting it, confirm what src/ actually contains: the repository metadata describes a Roles and Permissions package, which conflicts with the promise documentation.
- How do I install torann/promise with Composer?
- Run composer require torann/promise and then register the service provider and facade alias in config/app.php on older Laravel versions. The package targets a Laravel 5-era bootstrap, so on Laravel 8 and later the illuminate/* constraints will likely fail to resolve without a fork. Widening the constraint in an internal fork is the only honest fix; using --ignore-platform-reqs just moves the incompatibility from install time to production runtime.
- Does torann/promise support Laravel 10 or Laravel 11?
- Probably not out of the box. The package is built around config/app.php provider and alias registration plus Laravel 5-era illuminate/* constraints, while Laravel 11 moved service provider registration into bootstrap/providers.php and removed the traditional Kernel.php middleware setup. Composer resolution is likely to fail before you even reach those runtime changes. If you need it, plan for a maintained internal fork with updated constraints and registration.
- Does torann/promise make my PHP code actually asynchronous?
- No. PHP-FPM is synchronous and single-threaded, so then() callbacks execute inline rather than in the background. What you gain is readable control flow and a single error handler at the end of a chain, not parallelism. all() runs its items sequentially, and race() in a cooperative single-threaded runtime is deterministic, so it generally just returns the first element of the array rather than whichever finishes first.
- How does catch() handle exceptions thrown inside a then() callback?
- Exceptions thrown in a then() handler are routed to the nearest catch() in the chain, which is the main readability win over nested try/catch blocks. The common debugging trap is a chain with no catch at all, or a catch that returns null instead of rethrowing, which produces an empty page instead of a visible error. Always log inside catch or rethrow so failures surface during development and in production.
- What is the difference between all() and race() in this package?
- all() collects the results of every item in the chain and resolves with the full set of values, and because the runtime is single-threaded those items are processed sequentially rather than in parallel. race() resolves with the first settled result, but with no real concurrency the winner is effectively the first element in the array every time. Do not use race() expecting timing-based behavior; if you need genuine parallel I/O, use Laravel's Http::pool or queued jobs instead.
- Is the Promise facade bound as a singleton, and does that cause state leaks?
- That is one of the first things to verify in the service provider before using the package in production. If the provider registers a singleton, facade calls and app() resolution share one instance, so state can leak between chains, between requests in long-running workers, and between tests. Prefer a per-chain instance or a factory binding, and wrap usage behind your own interface so the binding is easy to change.
- How do I test code that uses torann/promise?
- Because callbacks run synchronously and eagerly within the request, ordinary PHPUnit assertions work fine and you do not need to wait on anything. The risk is shared facade state, so reset the container binding or avoid singletons between tests. The most testable approach is to depend on your own internal contract rather than on Torann\Promise directly, so promise chains can be swapped or mocked in isolation.
- Is torann/promise actively maintained and safe to use in production?
- The evidence points to abandonment: the README, package metadata and documented feature set disagree about what the library even does, and its framework constraints are Laravel 5-era. Treat it as a reference point for effort rather than a dependency candidate, and run a short spike to read composer.json and src/ before any design work. If you do adopt the capability, assign a named internal owner and host a fork in your own namespace.
- What are the maintained alternatives to torann/promise in Laravel?
- For concurrency, use queued jobs, Laravel's Http::pool, or Guzzle promises rather than a hand-rolled promise library; for true event-loop programming, ReactPHP or Amp. For short multi-step flows that may throw, plain try/catch is clearer, has no dependency, and will still compile years from now. If the source turns out to be the RBAC package after all, choose a currently maintained authorization package instead of a Laravel 5-era one.