Weave Code
Components Laravel Package
hypervel/components
Hypervel Components packages a suite of Laravel-style building blocks—routing, validation, collections, and more—for the Hyperf coroutine framework, letting developers reuse familiar PHP patterns in high-performance, Swoole-powered applications.
The components for Hypervel framework.
Frequently asked questions about Components
- What is hypervel/components used for?
- Hypervel Components is a collection of reusable, Laravel-inspired building blocks for the Hypervel framework, which runs on the Hyperf coroutine runtime. It provides shared abstractions such as routing, validation, collections, the container, facades, and an HTTP kernel so you can write familiar Laravel-style PHP inside long-lived Swoole workers. The components are modular and can be adopted individually or as a set. It is aimed at coroutine-native services, not at PHP-FPM workloads.
- How do I install hypervel/components with Composer?
- Install it like any other package with composer require hypervel/components, then place configuration files under config/autoload/ as Hyperf expects. There are no migration scripts or bootstrapping steps beyond the standard Hypervel and Hyperf setup. Installation itself is trivial; the real work is auditing any third-party packages for assumptions about Laravel's per-request lifecycle.
- Can I use hypervel/components in an existing Laravel application?
- No, not as a drop-in dependency. Hypervel replaces the framework's foundation layer, including the container, facades, Eloquent, HTTP kernel, and event system, and it assumes a resident worker with coroutine-scoped state rather than Laravel's bootstrap-per-request model. Moving an existing Laravel app onto it is a lifecycle rewrite plus an audit for stateful assumptions, not a Composer bump. If you are on PHP-FPM, shared hosting, or depend on the broader Laravel package ecosystem, it is out of scope.
- Which Laravel features does hypervel/components replicate?
- The package covers the core surface developers expect: routing, validation, collections, the service container, facades, events, and the HTTP kernel, with more components added over time. Parity is stated as an intent to stay close to Laravel wherever possible, not as a contractual guarantee. Treat parity as a per-component, per-release claim and verify it against the test suite for the specific components you plan to use.
- Can I adopt only some Hypervel components instead of the whole framework?
- Yes, the modular packaging is one of the package's real strengths, and you can adopt something like the container, HTTP kernel, and event components without committing to Eloquent. That said, the components ship from a monorepo, so a single version pin governs every component you pull in. Plan your adoption boundaries accordingly, because you cannot version individual components independently.
- Is hypervel/components coroutine-safe for Swoole workers?
- The components are built for coroutine-scoped state in resident Swoole workers, but coroutine-safety is something you must preserve in your own code. Singletons holding request data, static caches, providers capturing request-scoped values, and terminable middleware are the classic sources of bugs. Those defects appear as intermittent, environment-dependent concurrency issues, so audit for stateful assumptions before and during adoption.
- Which PHP, Hyperf, and Swoole versions does hypervel/components support?
- Hypervel Components targets the Hyperf coroutine framework and therefore requires a Swoole or Swow runtime plus a PHP version supported by your Hyperf release. The exact compatibility matrix across PHP, Hyperf, Swoole, and individual Hypervel components should be checked against the repository before you commit. Because the project is pre-1.0, assume the matrix can shift between minor releases and pin accordingly.
- Is hypervel/components production-ready?
- It is pre-1.0, so there is no semver protection and APIs can change between minor versions. The project has a small star count and a single-maintainer release cadence, which means limited external validation and meaningful bus-factor exposure. It can be a reasonable choice for internal, high-throughput coroutine services you own end-to-end, but pin tightly to a specific patch release such as ~0.3.26 and keep an eye on maintenance activity.
- How do I migrate an existing Laravel app to Hypervel?
- There are only two realistic paths: greenfield on Hypervel, which is low friction, or a full migration from Laravel, which is a lifecycle rewrite rather than a lift-and-shift. For the second path, audit for singletons holding request data, static caches, providers capturing request-scoped values, and terminable middleware, and budget it as an engineering project with a parity test suite. If you are already on 0.3.x, patch-level upgrades are the one genuinely cheap path available.
- How are Laravel security patches handled in hypervel/components?
- Because Hypervel diverges from upstream Laravel, Laravel security fixes do not automatically flow into it, and closing that gap is the adopter's responsibility unless upstream commits to a triage and backport process. Ask for the documented policy and target turnaround before relying on it in production. Track Laravel security advisories yourself and map them to the components you actually use.
Weaver
How can I help you explore Laravel packages today?