- Is hyperf/stdlib a Laravel package?
- No. hyperf/stdlib is a companion standard-library component for the Hyperf framework, which is a coroutine-based PHP microservice framework built on Swoole or Swow. It is not built for Laravel and does not ship Laravel service providers, facades, or framework-specific integration. Treat it as Hyperf-only unless you are deliberately running Hyperf alongside Laravel.
- Can I use hyperf/stdlib in a Laravel application?
- You can install it with Composer, but it is not a practical fit for a pure Laravel application. Laravel already provides overlapping collection, array, string, and JSON-style helpers through illuminate/support. Adding hyperf/stdlib would introduce a second set of similarly named primitives without adding Laravel-native capability.
- How do I install hyperf/stdlib?
- Install it with composer require hyperf/stdlib. The package is MIT licensed and has no service provider or configuration step, so installation is mechanically simple. The real precondition is that you already have a working Hyperf runtime with Swoole or Swow available.
- Does hyperf/stdlib require Swoole or Swow?
- Yes, effectively. The package belongs to the Hyperf ecosystem, and a working Hyperf runtime requires the Swoole or Swow PHP extension. That is an infrastructure precondition rather than a code change. If your environment is Laravel plus PHP-FPM only, this package is not relevant.
- What Laravel versions does hyperf/stdlib support?
- hyperf/stdlib does not target Laravel versions. Its versioning tracks the Hyperf core line, with a 3.1.x stable line and 3.2.0 alpha releases present. Laravel version support is not part of its design scope, so do not evaluate it as a Laravel compatibility package.
- What does hyperf/stdlib provide compared with illuminate/support?
- It provides foundational utility primitives such as collection, array, string, and JSON-style helpers expressed in Hyperf idioms. illuminate/support provides comparable helpers for Laravel applications. The overlap is the main concern: using both in one codebase can create idiom duplication and inconsistent behavior for similarly named utilities.
- Will hyperf/stdlib conflict with Laravel helper classes or functions?
- There is a real collision surface because hyperf/stdlib overlaps with illuminate/support class and potentially global function names. In a monorepo containing both Laravel and Hyperf services, verify class and function name collisions before adoption. This is usually where integration time is actually spent.
- Is hyperf/stdlib safe in long-running coroutine workers?
- Coroutine safety should be verified rather than assumed. In a long-running Hyperf worker model, static caches or memoization inside utility helpers could become cross-request state leaks. Review the helpers you actually use and test them under your worker lifecycle before relying on them in production.
- How is hyperf/stdlib maintained and versioned?
- It is maintained as part of the Hyperf framework, so continuity is tied to Hyperf's release cadence. Versioning follows Hyperf core, with 3.1.x stable and 3.2.0 alphas present. Documentation is thin, with changelog stubs rather than API docs or migration notes, so onboarding cost lands on your team.
- What are the alternatives to hyperf/stdlib for Laravel developers?
- For Laravel applications, use illuminate/support and Laravel's built-in Arr, Str, Collection, and Stringable helpers instead of adding a Hyperf utility package. If you run both Laravel and Hyperf services, standardize on illuminate/support for Laravel and keep hyperf/stdlib scoped to Hyperf services. A fork-and-vendor fallback is also cheap here because the package has a small surface area.