Package Structure and Dependencies

This page documents the hypervel/foundation package structure, dependency graph, autoloading configuration, and integration mechanisms with the Hyperf framework ecosystem. For architectural principles and design patterns, see page 1.1. For service provider lifecycle details, see page 2.2.

Package Metadata

The hypervel/foundation package provides the core application container, kernels, service providers, and testing framework.

Property	Value
Package Name	hypervel/foundation
License	MIT
PHP Requirement	^8.2
Minimum Stability	dev
Autoload Namespace	Hypervel\Foundation
Helper File	src/helpers.php

Sources: composer.json1-59

Dependency Graph

Complete Dependency Map

Sources: composer.json22-47

Dependency Categories

Category	Packages	Version Constraint
Hypervel Ecosystem	hypervel/core, hypervel/filesystem, hypervel/support, hypervel/http, hypervel/validation	^0.3
Hyperf Framework	hyperf/framework, hyperf/di, hyperf/config, hyperf/contract	~3.1.0
HTTP Layer	hyperf/http-server, hyperf/dispatcher	~3.1.0
Database Layer	hyperf/database, hyperf/db-connection	~3.1.0
Console Layer	hyperf/command, friendsofhyperf/pretty-console, friendsofhyperf/command-signals	~3.1.0
Utilities	hyperf/collection, hyperf/context, hyperf/stringable, hyperf/support, hyperf/signal	~3.1.0
Runtime	hyperf/engine, PHP	^2.1, ^8.2
Third-Party	nesbot/carbon, symfony/error-handler	^2.72.6, ^6.3

The ~3.1.0 version constraint for Hyperf packages pins to the 3.1.x series, ensuring compatibility with Hyperf 3.1 framework features.

Sources: composer.json22-47

Source Directory Structure

The src/ directory contains all framework classes organized by functional area:

Core Classes

File Path	Class	Purpose
src/ConfigProvider.php	ConfigProvider	Hyperf framework integration point
src/Application.php	Application	Application container implementation
src/ClassLoader.php	ClassLoader	Enhanced class loading and annotation scanning
src/DotenvManager.php	DotenvManager	Environment variable loading
src/helpers.php	N/A	Global helper functions (69 functions)

Subsystem Directories

Directory	Purpose	Key Classes
src/Console/	Console command system	Kernel, command classes
src/Http/	HTTP request handling	Kernel, FormRequest
src/Exceptions/	Exception handling	Handler
src/Providers/	Service providers	FoundationServiceProvider, FormRequestServiceProvider
src/Listeners/	Event listeners	SetProcessTitle, ReloadDotenvAndConfig
src/Testing/	Testing framework	TestCase, TestClient, TestResponse, testing traits

Sources: composer.json52-59

Autoloading Configuration

PSR-4 and Files Autoloading

Autoload Configuration:

The PSR-4 mapping enables automatic class loading for all Hypervel\Foundation classes. The files array loads src/helpers.php immediately on Composer autoload initialization, making 69 global helper functions available throughout the application.

Sources: composer.json52-59

Helper Functions Autoloading

The helpers.php file is autoloaded via Composer's files directive, making all global helper functions immediately available:

The helpers file provides approximately 69 global functions that act as facades to the application container and core services. These functions are loaded before any application code executes, ensuring they are available throughout the request lifecycle.

Sources: composer.json56-58

Framework Integration Configuration

ConfigProvider Integration and Service Registration

Class: Hypervel\Foundation\ConfigProvider

The ConfigProvider class serves as the primary integration point between Hyperf framework and Hypervel Foundation package functionality:

The ConfigProvider::__invoke() method returns an array with four main keys:

• dependencies: Maps interfaces to concrete implementations for dependency injection
• listeners: Registers event listeners for framework lifecycle events
• commands: Registers console commands available via the CLI
• publish: Defines publishable configuration files and their destinations

Sources: src/ConfigProvider.php20-46

Service Discovery and Registration Flow

Integration Points:

Composer Integration Configuration:

The dual registration mechanism ensures that:

1. Framework-level components (dependencies, listeners, commands) are registered via ConfigProvider for Hyperf's component system
2. Application-level services and customizations are registered via FoundationServiceProvider for Hypervel's service provider lifecycle

Registered Components:

Component Type	Count	Examples
Dependencies	2	ApplicationInterface, InitProcessTitleListener
Listeners	2	ErrorExceptionHandler, ReloadDotenvAndConfig
Commands	4	AboutCommand, ConfigShowCommand, ServerReloadCommand, VendorPublishCommand
Publish Configs	1	app.php configuration file

Sources: composer.json60-71 src/ConfigProvider.php20-46

Package Discovery and Integration Points

Additional Composer Configuration

The package includes several Composer-specific configurations to facilitate development workflows:

Configuration	Value	Purpose
sort-packages	true	Automatically sort package dependencies alphabetically
minimum-stability	dev	Allow development versions of dependencies during development
branch-alias	dev-main: 0.3-dev	Map development branch to semantic version

These settings enable flexible dependency management during the package development phase.

Sources: composer.json69-76

Console Commands and Asset Publishing

The package provides four built-in console commands for development and maintenance tasks:

Command Class	Signature	Purpose
AboutCommand	about	Display application information
ConfigShowCommand	config:show	Display configuration values
ServerReloadCommand	server:reload	Gracefully reload server workers
VendorPublishCommand	vendor:publish	Publish package assets and configurations

Sources: src/ConfigProvider.php31-36

Server Management Integration

Class: Hypervel\Foundation\Console\Commands\ServerReloadCommand

The ServerReloadCommand integrates with Swoole/Swow server process management:

Signal Mapping:

Signal	Constant	Target	Purpose
SIGUSR1	10	Workers	Gracefully reload all worker processes
SIGUSR2	12	Task Workers	Gracefully reload all task worker processes

Implementation Details:

The command performs the following steps:

1. Reads PID file location from server.settings.pid_file configuration src/Console/Commands/ServerReloadCommand.php30
2. Verifies the PID file exists src/Console/Commands/ServerReloadCommand.php35-38
3. Reads the process ID from the PID file src/Console/Commands/ServerReloadCommand.php41
4. Checks if the process is running using posix_kill($pid, 0) src/Console/Commands/ServerReloadCommand.php44
5. Sends SIGUSR1 to reload worker processes src/Console/Commands/ServerReloadCommand.php45
6. If task workers are configured, sends SIGUSR2 to reload task workers src/Console/Commands/ServerReloadCommand.php50-61

Sources: src/Console/Commands/ServerReloadCommand.php14-71 src/ConfigProvider.php13-34

Sources: composer.json52-77