feat: framework refactor + decouple from Hyperf#349
feat: framework refactor + decouple from Hyperf#349binaryfire wants to merge 2358 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! |
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:
|
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.
src/database/src/Listeners/RegisterConnectionResolverListener.php
Outdated
Show resolved
Hide resolved
The Guzzle package was removed previously but the workflow still referenced tests/Integration/Guzzle, causing CI failures.
Move Engine, Factory, View, and ViewCompilationException from src/view/src/Contracts/ to src/contracts/src/View/, updating namespace from Hypervel\View\Contracts to Hypervel\Contracts\View to match Laravel's Illuminate\Contracts\View structure.
Update all Hypervel\View\Contracts references to Hypervel\Contracts\View in foundation, mail, routing, support, telescope, testing packages and their tests.
Make 'view' and 'blade.compiler' the canonical alias keys in registerCoreContainerAliases, matching Laravel's pattern where string shorthands are canonical. Update ViewServiceProvider to bind to these canonical keys instead of the now-aliased contract classes. Update View facade accessor to return 'view'.
Allows per-request opt-out of Telescope recording via request
attributes. Usage: Http::withoutTelescope()->get('...')
Delete GuzzleHttpClientAspect, HttpClientWatcher, and ConfigProvider. The AOP approach intercepted raw Guzzle calls and predates the Http client package which dispatches ResponseReceived/ConnectionFailed events. The event-based replacement follows in the next commit.
Rewrite the stub ClientRequestWatcher to listen for ResponseReceived and ConnectionFailed events from the Http client, matching Laravel Telescope's approach. Includes per-request opt-out via withoutTelescope(), ignore_hosts filtering, and separate request/response size limits. Also removes the Telescope ConfigProvider from root and package composer.json since it only contained AOP aspect registrations.
Port Laravel Telescope's ClientRequestWatcherTest and add coverage for Hypervel-specific features: ignore_hosts, withoutTelescope() opt-out, ConnectionFailed recording, and request/response size limits.
Delete class_map/SentrySdk.php, Aspects/CoroutineAspect.php, Aspects/GuzzleHttpClientAspect.php, Factory/ClientBuilderFactory.php, and Switcher.php. These depend on hyperf/di AOP (aspects, class_map) which is being removed as a dependency. Each has a non-AOP replacement: afterCreated hook, event-based HttpClientIntegration, inline ServiceProvider logic, and Feature base class methods respectively.
Add isTracingFeatureEnabled() and isBreadcrumbFeatureEnabled() with in-memory caching, replacing Switcher dependency. Add sentryConfig() helper for scoped config access. Features now use these built-in methods instead of injecting Switcher.
Replace $this->switcher->isTracingEnable() and isBreadcrumbEnable() calls with the new isTracingFeatureEnabled() and isBreadcrumbFeatureEnabled() methods from the Feature base class across all existing feature classes.
Add extractNameAndSourceForRoute() for route name extraction, captureUnhandledException() with handled/unhandled detection via backtrace, handles() convenience method for exception handler registration, and HTML-escaped meta tag helpers. Update flushEvents() to also flush Logs and TraceMetrics instances. Preserve existing swoole.version context enrichment in setupOnce().
Add ContextIntegration for app context (version, environment) on Sentry events. Add ModelViolationReporter base class with coroutine- scoped deduplication, and three concrete reporters for discarded attributes, lazy loading, and missing attributes.
Add event-driven handler for framework events: routeMatched, messageLogged, and authenticated. Removed Octane, Lumen, and Sanctum code that doesn't apply to Hypervel.
Add FlushEventsMiddleware (critical for transport pool lifecycle — calls Integration::flushEvents() in terminate() to release pooled transports) and SetRequestIpMiddleware (sets user IP on Sentry scope).
Port HTTP request tracing middleware with three Swoole-specific changes: (1) remove continue_after_response entirely — Hypervel's dispatchAfterResponse() uses Coroutine::defer(), not terminating callbacks, so TransactionFinisher pattern doesn't apply; terminate() always calls finishTransaction() directly. (2) Make bootedTimestamp a static property — scoped() instances don't share boot-time state across coroutines. (3) Per-request state ($transaction, $appSpan, $didRouteMatch) stays as instance properties, safe via scoped() registration giving each coroutine its own instance.
Add tracing event handler that subscribes to framework events for creating tracing spans (route matched, database queries). Uses coroutine-safe Context for per-request span tracking. Removed Lumen code.
Add route dispatcher decorators for tracing: TracingRoutingDispatcher base class, TracingCallableDispatcherTracing, and TracingControllerDispatcherTracing. These wrap route dispatching to create tracing spans for controller/callable execution.
Add view engine decorator that wraps Blade/PHP/file engines to create tracing spans for view rendering.
Add ConsoleIntegration for command breadcrumbs and scope tagging. Add HttpClientIntegration for HTTP client tracing via Hypervel Http\Client events (replaces the AOP-based GuzzleHttpClientAspect).
Add Facade, SentryHandler (Monolog handler), and Util/Filesize. Update LogChannel, Logs/LogChannel, and Logs/LogsHandler with sentry-laravel improvements. Update Version SDK identifier.
Update ResolvesEventOrigin and TracksPushedScopesAndSpans to use coroutine-local Context for per-request state instead of instance properties. This prevents scope/span state from leaking between concurrent requests sharing the same singleton feature instances.
Two fixes: (1) Wrap pool->get() in try/catch — on RuntimeException (pool exhausted), return ResultStatus::skipped() instead of blocking the request coroutine for wait_timeout seconds. (2) Change from single Context key to array tracking — multiple sends in one coroutine (e.g. captureException + transaction finish) no longer overwrite the previous transport reference, so close() releases all of them.
Expand test command with structured output, DSN validation, config diagnostics, and feature status reporting ported from sentry-laravel.
Merge sentry-laravel functionality (configureAndRegisterClient, bindEvents, registerLogChannels, middleware registration, tracing setup, feature lifecycle) with Swoole-specific code (coroutine-scoped Hub, HttpPoolTransport with pool config from sentry.pool, async HttpClient, enhanced afterCreated hook copying both Hub stack and Request context to child coroutines). Register Tracing\Middleware as scoped() for coroutine isolation with static bootedTimestamp. No TransactionFinisher — terminate() always finishes directly.
Config: add RedisFeature, HttpClientIntegration, ConsoleIntegration to default features. Fix pool config key (sentry.pool, not pools.sentry). Set pool wait_timeout to 0.01s for fast-fail backpressure. Add tracing and breadcrumb config keys from sentry-laravel. Remove obsolete breadcrumbs.guzzle and enable.coroutine keys. Composer: add hypervel/http and hypervel/routing dependencies.
Add dedicated tests for each bug fix and Swoole adaptation: - ConfigRegressionTest: pool config key, RedisFeature wiring - HttpPoolTransportTest: multi-send transport release, backpressure fast-fail on pool exhaustion - FlushLifecycleTest: transport release after flush - CoroutineContextPropagationTest: child coroutines inherit Hub stack and Request context - CoroutineSafetyTest: trait and integration coroutine isolation - TracingMiddlewareTest: scoped instance isolation, static bootedTimestamp, direct finishTransaction in terminate - ModelViolationDedupeTest: per-coroutine deduplication isolation Update SentryTestCase with shared helpers and QueueFeatureTest for updated Feature API.
| // Uncacheable callables: closures and global function strings. | ||
| // These lack a deterministic ClassName::methodName key, so we fall | ||
| // back to per-call reflection via addDependencyForCallParameter. | ||
| $dependencies = []; |
There was a problem hiding this comment.
@binaryfire I'm thinking if we can also cache method dependencies for closures via WeakMap like this:
$cache = new WeakMap();
$closure = fn () => 'result;
$cache[$closure] = 'result';When closures get recycled by GC, it will be deleted from the WeakMap automatically.
| // type class names in $scopedInstances (not the Closure) so that isScoped() correctly | ||
| // identifies them and resolve() routes their instances to Context. | ||
| if ($abstract instanceof Closure) { | ||
| foreach ($this->closureReturnTypes($abstract) as $type) { |
There was a problem hiding this comment.
Hi @binaryfire , I'm thinking if we can also cache return types for closures via WeakMap like this: #349 (comment)
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)