feat: framework refactor + decouple from Hyperf#349
feat: framework refactor + decouple from Hyperf#349binaryfire wants to merge 1799 commits intohypervel:0.4from
Conversation
|
@albertcht To illustrate how much easier it will be to keep Hypervel in sync with Laravel after this refactor, I asked Claude how long it would take to merge laravel/framework#58461 (as an example) into this branch. This is what it said: So just 5-10 minutes of work with the help of AI tooling! Merging individual PRs is inefficient - merging releases would be better. I can set up a Discord channel where new releases are automatically posted via webhooks. Maybe someone in your team can be responsible for monitoring that channel's notifications and merging updates ever week or 2? I'll only be 1-2 hours of work once the codebases are 1:1. We should be diligent about staying on top of merging updates. Otherwise we'll end up in in the same as Hyperf - i.e. the codebase being completely out of date with the current Laravel API. |
|
Hi @binaryfire , Thank you for submitting this PR and for the detailed explanation of the refactor. After reading through it, I strongly agree that this is the best long-term direction for Hypervel. Refactoring Hypervel into a standalone framework and striving for 1:1 parity with Laravel will indeed solve the current issues regarding deep coupling with Hyperf, maintenance difficulties, outdated versions, and inefficient AI assistance. While this is a difficult step, it is absolutely necessary for the future of the project. Regarding this refactor and the planning for the v0.4 branch, I have a few thoughts to verify with you:
Thank you again for dedicating so much effort to driving this forward; this is a massive undertaking. Let's move forward gradually on this branch with ongoing Code Reviews. |
|
Hi @albertcht Thanks for the detailed response! I'm glad we're aligned on the direction. Let me address each point:
Let me know your thoughts! |
binaryfire
force-pushed
the
feature/hyperf-decouple
branch
from
8cec3bf to
bfffa6f
Compare
|
Hi @albertcht. The All the Laravel tests have been ported over and are passing (the unit tests, as well as the integration tests for MySQL, MariaDB, Postgres and SQLite). I've implemented Context-based coroutine safety, static caching for performance and modernised all the types. The code passes PHPStan level 5. Let me know if there's anything I've missed, if you have any ideas or you have any questions. The other packages aren't ready for review yet - many of them are mid-migration and contain temporary code. So please don't review the others yet :) I'll let you know when each one is ready. A few points:
|
| @@ -6,9 +6,9 @@ | |||
|
|
|||
| use Hyperf\Command\Concerns\Prohibitable; | |||
There was a problem hiding this comment.
change to Hypervel's Prohibitable here?
binaryfire
force-pushed
the
feature/hyperf-decouple
branch
from
80f3ef2 to
94c115e
Compare
|
@albertcht The following packages are ready for review. I've modernised typing, optimised the code, added more tests (including integration tests) and fixed several bugs.
I've also ported https://github.com/friendsofhyperf/redis-subscriber into the Redis package. The subscription methods were all blocking - now they're coroutine friendly. With the previous implementation, if you wrapped
The approach follows the same pattern suggested in hyperf/hyperf#4775 (https://github.com/mix-php/redis-subscriber, which Deeka ported to https://github.com/friendsofhyperf/components). I.e. a dedicated raw socket connection with This is a good article re: this issue for reference: https://openswoole.com/article/redis-swoole-pubsub |
|
Hi @albertcht! The new This is Swoole-optimised version of Laravel's IoC Container, replacing Hyperf's container. The goal: give Hypervel the complete Laravel container API while maintaining performance parity with Hyperf's container and full coroutine safety for Swoole's long-running process model. Why replace Hyperf's container?Hyperf's container is minimal. It exposes
Also, the API is very different to Laravel's. This makes it difficult to port Laravel code or use Laravel's service provider patterns without shimming everything. The new container closes that gap completely and makes interacting with the container much more familiar to Laravel devs. It also means that our package and test code will be closer to 1:1 with Laravel now. APIThe new container implements the full Laravel container contract:
It also supports closure return-type bindings (register a binding by returning a typed value from a closure, including union types), Key API difference from HyperfLike Hyperf's Auto-singletoned instances are stored in a separate Attribute-based injection16 contextual attributes are included, providing declarative dependency injection:
Example: class OrderService
{
public function __construct(
#[Config('orders.tax_rate')] private float $taxRate,
#[Tag('payment-processors')] private array $processors,
#[Authenticated] private User $user,
) {}
}PerformanceBuild recipe cachingConstructor parameters are analyzed via reflection once per class and cached as Method parameter caching
Reflection caching
Hot-path optimizations
Performance vs HyperfThe singleton cache-hit path does marginally more work than Hyperf's single Coroutine safetyAll per-request state is stored in coroutine-local
Circular dependency detection uses two complementary mechanisms:
All transient Context state is cleaned up in Scoped instance cleanup is handled consistently across all invalidation paths. Tests~220 tests:
Everything passes at PHPStan level 5. Let me know what you think |
| */ | ||
| protected function prepareDatabase(): void | ||
| { | ||
| if (! $this->migrator->repositoryExists()) { |
There was a problem hiding this comment.
Hi @binaryfire , do we consider porting handleMissingDatabase function from Laravel as well?
https://github.com/laravel/framework/blob/12.x/src/Illuminate/Database/Console/Migrations/MigrateCommand.php#L179
There was a problem hiding this comment.
Hi @albertcht. I haven’t ported the Laravel commands because I want to port illuminate/console first.
So all these commands will be fully refactored later (and the Laravel features will be ported at that time).
| use Hypervel\Console\Prohibitable; | ||
| use Hypervel\Database\ConnectionResolverInterface; | ||
|
|
||
| class WipeCommand extends Command |
There was a problem hiding this comment.
@binaryfire will we also port DbCommand, DumpCommand, MonitorCommand, PruneCommand, ShowCommand and TableCommand from Laravel?
There was a problem hiding this comment.
@albertcht Please see my comment here: #349 (comment). The current commands are just refactored versions of the old commands. I'll be doing fresh ports of the Laravel commands after I port illuminate/console. Otherwise I'd have to do the work twice. So could you skip reviewing the commands for now? It will be better to review the new ones after I've replaced them. That won't be for a while though - there are several other things I need to refactor before I do illuminate/console.
- Widen InteractsWithIO::option() return type to include int|float, matching what Symfony's getOption() can actually return. The overly narrow type caused a TypeError when options had integer values. - Update ExceptionHandlerListenerTest and StdoutLoggerTest to use Hypervel\Config\Repository instead of Hyperf\Config\Config, which no longer satisfies the Hypervel\Contracts\Config\Repository type hint.
Port ParserTest (7 tests) and CommandTest tests (hookFlags, exit codes, setUpTraits, Prohibitable) from Hyperf. Adapted for Hypervel's execute() which differs from Hyperf's: uses ErrorRenderer + Collision instead of $application->renderThrowable(), and disableDispatcher() can overwrite mock dispatchers from the bootstrapped container. Key adaptations: - Input mocks return true for getOption to prevent dispatcher overwrite - Output mocks use shouldIgnoreMissing for ErrorRenderer/Collision writes - setUpPrettyable called explicitly since execute() bypasses run()
The extends relationship was nominal — every method was already overridden. Add the clear() method directly (previously inherited, trivial one-liner).
…sTitleListenerTest
Package was not a transitive dependency of anything, so it was fully removed.
….json files None of these packages import any Hyperf\Config\* class.
Empty marker interface extending Psr\Log\LoggerInterface, replacing Hyperf\Contract\StdoutLoggerInterface.
…el\Contracts\Log\StdoutLoggerInterface 25 files updated across pool, redis, websocket-server, engine, framework, foundation, http-server, server, database, event, object-pool, and core.
…rvel\Contracts\Log\StdoutLoggerInterface 13 test files updated, including one hardcoded FQCN config key string.
Replaces the Hyperf pattern of using a class FQCN as the Context key with Hypervel's __package.name convention (__session.store).
Swap all consumers from Hyperf's SessionInterface to Hypervel equivalents: - Context keys use Store::CONTEXT_KEY instead of SessionInterface::class - UrlGenerator resolves via Hypervel SessionContract instead of Hyperf interface - ShareErrorsFromSession type-hints Hypervel Session contract
Delete the adapter that bridged Hyperf\Contract\SessionInterface to Hypervel\Contracts\Session\Session, and remove its ConfigProvider binding. All consumers now use the Hypervel contract directly.
…ract Swap all server and http-server package type-hints from the narrow PSR ContainerInterface to Hypervel\Contracts\Container\Container, matching Laravel's convention of using its own container contract internally.
The RegisterCommandListener from hyperf/command is dead code — it handles Hyperf-specific command registration (AsCommand annotations, closure commands) that Hypervel doesn't use. The Kernel's own collectCommands() handles all command discovery independently.
With hyperf/command's RegisterCommandListener excluded from auto-discovery, nothing depends on this interface. Remove: - implements HyperfContainerInterface from Application - Bridge methods: set(), unbind(), define() - Container binding and alias for Hyperf\Contract\ContainerInterface - Replace unbind() calls with forgetInstance() in ReloadDotenvAndConfig and PendingCommand - Remove set/unbind @method annotations from App facade
Create a new GeneratorCommand that extends Hypervel\Console\Command (aligned with Laravel) instead of raw Symfony Command (Hyperf pattern). Key changes from Hyperf's GeneratorCommand: - Uses handle() instead of execute() - Uses $this->app->path() + getNamespace() for path resolution (no Hyperf\CodeParser\Project dependency) - Uses $this->components for styled output - Sets $coroutine = false (file generation doesn't need Swoole) - Adds $type, $reservedNames, isReservedName(), sortImports() from Laravel - Modernizes getEditorUrl() to use match expression - Keeps Hypervel-specific getConfig() and openWithIde()
Port and adapt tests from Hyperf's devtool GeneratorCommandTest: - getPath() with relative/absolute paths, trailing slashes, nested namespaces - Default app path resolution via $this->app->path() - Option registration (path, force, namespace) Add new tests for Laravel-ported features: - isReservedName() with reserved words, non-reserved, case insensitivity - sortImports() alphabetical sorting and no-op for non-import code - qualifyClass() with default namespace, forward slashes, custom namespace
…Command Swap base class from Hyperf\Devtool\Generator\GeneratorCommand to Hypervel\Console\GeneratorCommand. Replace constructor/configure() with $name/$description/$type properties. Change $this->input->getOption() to $this->option() and $this->input->getArgument() to $this->argument(). ControllerCommand: remove local call() (inherited CallsCommands is better). MailCommand/NotificationCommand: change $this->output->writeln() to $this->components->info() for styled output.
…mmand
Swap base class, use $name/$description/$type properties with | alias
syntax. Change execute() to handle(), remove manual $this->input/output
assignment, change $this->input->getOption() to $this->option(),
change $output->writeln() to $this->components->info/error(),
change Container::getInstance()->make('config') to $this->app->make('config').
Also restore Laravel's canonical comment blocks to base GeneratorCommand
handle() method.
Swap base class, use $name/$description/$type properties. Change execute() to handle() with guard on parent::handle() failure — if model generation fails (reserved name, already exists), abort without generating related artifacts. Remove local call() method — inherited CallsCommands::call() handles sub-command invocation with proper context passing. Change all $this->input->getOption/getArgument to $this->option/$this->argument. Add void return types to create* methods.
Remove Hyperf\Devtool\Generator\GeneratorCommand import and class_exists guard. The guard was needed when GeneratorCommand came from the optional hyperf/devtool package. Now it lives in hypervel/console which is always present.
- Remove hyperf/devtool from root composer.json (require-dev) - Remove hyperf/devtool from src/devtool/composer.json (require) - Remove Hyperf\Devtool\ConfigProvider block from testbench ConfigProviderRegister (Hypervel's devtool ConfigProvider is auto-discovered via extra.hyperf.config)
Devtool generator commands now import Hypervel\Console\GeneratorCommand directly. Declare the dependency so standalone/split installs resolve correctly.
2 participants
Hi @albertcht. This isn't ready yet but I'm opening it as a draft so we can begin discussions and code reviews. The goal of this PR is to refactor Hypervel to be a fully standalone framework that is as close to 1:1 parity with Laravel as possible.
Why one large PR
Sorry about the size of this PR. I tried spreading things across multiple branches but it made my work a lot more difficult. This is effectively a framework refactor - the database package is tightly coupled to many other packages (collections, pagination, pool) as well as several support classes, so all these things need to be updated together. Splitting it across branches would mean each branch needs multiple temporary workarounds + would have failing tests until merged together, making review and CI impractical.
A single large, reviewable PR is less risky than a stack of dependent branches that can't pass CI independently.
Reasons for the refactor
1. Outdated Hyperf packages
It's been difficult to migrate existing Laravel projects to Hypervel because Hyperf's database packages are quite outdated. There are almost 100 missing methods, missing traits, it doesn't support nested transactions, there are old Laravel bugs which haven't been fixed (eg. JSON indices aren't handled correctly), coroutine safety issues (eg. model
unguard(),withoutTouching()). Other packages like pagination, collections and support are outdated too.Stringablewas missing a bunch of methods and traits, for example. There are just too many to PR to Hyperf at this point.2. Faster framework development
We need to be able to move quickly and waiting for Hyperf maintainers to merge things adds a lot of friction to framework development. Decoupling means we don't need to work around things like PHP 8.4 compatibility while waiting for it to be added upstream. Hyperf's testing package uses PHPUnit 10 so we can't update to PHPUnit 13 (and Pest 4 in the skeleton) when it releases in a couple of weeks. v13 has the fix that allows
RunTestsInCoroutineto work with newer PHPUnit versions. There are lots of examples like this.3. Parity with Laravel
We need to avoid the same drift from Laravel that's happened with Hyperf since 2019. If we're not proactive with regularly merging Laravel updates every week we'll end up in the same situation. Having a 1:1 directory and code structure to Laravel whenever possible will make this much easier. Especially when using AI tools.
Most importantly, we need to make it easier for Laravel developers to use and contribute to the framework. That means following the same APIs and directory structures and only modifying code when there's a good reason to (coroutine safety, performance, type modernisation etc).
Right now the Hypervel codebase is confusing for both Laravel developers and AI tools:
hypervel/contractspackage, the Hyperf database code is split across 3 packages, the Hyperf pagination package ishyperf/paginatorand nothyperf/pagination)static::registerCallback('creating')vsstatic::creating())ConfigProviderand LaravelServiceProviderpatterns across different packages is confusing for anyone who doesn't know HyperfThis makes it difficult for Laravel developers to port over apps and to contribute to the framework.
4. AI
The above issues mean that AI needs a lot of guidance to understand the Hypervel codebase and generate Hypervel boilerplate. A few examples:
hypervel/contractsfor contracts) and then have to spend a lot of time grepping for things to find them.And so on... This greatly limits the effectiveness of building Hypervel apps with AI. Unfortunately MCP docs servers and CLAUDE.md rules don't solve all these problems - LLMs aren't great at following instructions well and the sheer volume of Laravel data they've trained on means they always default to Laravel-style code. The only solution is 1:1 parity. Small improvements such as adding native type hints are fine - models can solve that kind of thing quickly from exception messages.
What changed so far
New packages
illuminate/databaseportilluminate/collectionsportilluminate/paginationportilluminate/contracts)hyperf/pool)Macroableto a separate package for Laravel parityRemoved Hyperf dependencies so far
Database package
The big task was porting the database package, making it coroutine safe, implementing performance improvements like static caching and modernising the types.
whereLike,whereNot,groupLimit,rawValue,soleValue, JSON operations, etc.Collections package
Contracts package
Support package
hyperf/tappable,hyperf/stringable,hyperf/macroable,hyperf/codecdependenciesStr,Envand helper classes from LaravelHypervel\Contextwrappers (will be portinghyperf/contextsoon)Number::useCurrency()wasn't actually setting the currency)Coroutine safety
withoutEvents(),withoutBroadcasting(),withoutTouching()now use Context instead of static propertiesUnsetContextInTaskWorkerListenerto clear database context in task workersConnection::resetForPool()to prevent state leaks between coroutinesDatabaseTransactionsManagercoroutine-safeBenefits
Testing status so far
What's left (WIP)
The refactor process
Hyperf's Swoole packages like
pool,coroutine,contextandhttp-serverhaven't changed in many years so porting these is straightforward. A lot of the code can be simplified since we don't need SWOW support. And we can still support the ecosystem by contributing any improvements we make back to Hyperf in separate PRs.Eventually I'll refactor the bigger pieces like the container (contextual binding would be nice!) and the config system (completely drop
ConfigProviderand move entirely to service providers). But those will be future PRs. For now the main refactors are the database layer, collections and support classes + the simple Hyperf packages. I'll just port the container and config packages as-is for now.Let me know if you have any feedback, questions or suggestions. I'm happy to make any changes you want. I suggest we just work through this gradually, as an ongoing task over the next month or so. I'll continue working in this branch and ping you each time I add something new.
EDIT: New comments are getting lost in the commit history so linking them here:
New
hypervel/containerpackage ready for reviewSee: #349 (comment)
New
hypervel/context,hypervel/coordinator,hypervel/coroutine,hypervel/engine,hypervel/pool&hypervel/redispackages ready for reviewSee: #349 (comment)
New
hypervel/databasepackage ready for reviewSee: #349 (comment)