Package Structure and Integration

Purpose and Scope

This document explains how the Hypervel Notifications package is structured and how it integrates with the Hyperf framework. It covers the package definition, dependency requirements, autoloading configuration, and the bootstrap process that occurs when the package is initialized. For information about the core architectural components and how they dispatch notifications, see System Architecture. For practical usage examples, see Sending Notifications.

---

Package Definition

The Hypervel Notifications package is defined in composer.json1-59 and follows standard Composer package conventions for PHP libraries.

Package Metadata

Property	Value
Package Name	hypervel/notifications
Type	library
Namespace	Hypervel\Notifications
License	MIT
Minimum PHP Version	8.2
Repository	https://github.com/hypervel/components

Sources: composer.json2-22

Autoloading Configuration

The package uses PSR-4 autoloading to map the Hypervel\Notifications namespace to the src/ directory:

This means that a class Hypervel\Notifications\ChannelManager would be located at src/ChannelManager.php, and Hypervel\Notifications\Channels\MailChannel would be at src/Channels/MailChannel.php.

Sources: composer.json23-27

---

Dependency Architecture

The package depends on both Hyperf framework components and other Hypervel ecosystem packages. The dependency structure reveals a well-integrated package within a larger ecosystem.

Hyperf Framework Dependencies

These are core Hyperf v3.1.0 components that provide foundational functionality:

Package	Version	Purpose
hyperf/config	~3.1.0	Configuration management and provider registration
hyperf/di	~3.1.0	Dependency injection container for service resolution
hyperf/database	~3.1.0	Database ORM for DatabaseChannel persistence
hyperf/collection	~3.1.0	Collection utilities for batch operations
hyperf/context	~3.1.0	Coroutine context management
hyperf/stringable	~3.1.0	String manipulation utilities
hyperf/contract	~3.1.0	Interface contracts and abstractions

Sources: composer.json28-36

Hypervel Ecosystem Dependencies

These are Hypervel v0.3 packages that provide specialized notification capabilities:

Package	Version	Purpose
hypervel/mail	^0.3	Email sending through MailChannel
hypervel/queue	^0.3	Asynchronous notification processing
hypervel/broadcasting	^0.3	Real-time notification broadcasting
hypervel/support	^0.3	Base ServiceProvider and helper utilities
hypervel/object-pool	^0.3	Channel instance pooling in ChannelManager

Sources: composer.json37-41

Dependency Flow Diagram

This diagram shows how the package definition in composer.json declares dependencies on both framework and ecosystem packages, which are then utilized by the core notification components.

Sources: composer.json28-41

---

Framework Integration Mechanism

The Hypervel Notifications package integrates with Hyperf through two primary registration mechanisms defined in the extra section of composer.json.

ConfigProvider Registration

The package registers a ConfigProvider class that Hyperf automatically discovers during application bootstrap:

The ConfigProvider class is responsible for:

• Registering service bindings in the dependency injection container
• Publishing configuration files
• Defining component factories and aliases

Sources: composer.json46-49

ServiceProvider Registration

The package also registers a NotificationServiceProvider through the Hypervel-specific mechanism:

This provider extends Hypervel\Support\ServiceProvider and handles additional bootstrap tasks that need to occur after the container is fully configured.

Sources: composer.json50-54

Integration Flow Diagram

This sequence shows the two-phase bootstrap process: first the ConfigProvider registers services with the container, then the NotificationServiceProvider performs additional initialization tasks.

Sources: composer.json46-54

---

Bootstrap Process

The NotificationServiceProvider class handles package initialization tasks that occur after the dependency injection container is configured.

Service Provider Implementation

The service provider is located at src/NotificationServiceProvider.php1-15 and extends Hypervel\Support\ServiceProvider:

Sources: src/NotificationServiceProvider.php1-15

View Registration

The boot() method registers notification view templates with the view system using the namespace notifications. The views are loaded from the publish/resources/views directory relative to the package root.

Method	Parameters	Purpose
loadViewsFrom()	$path, $namespace	Register view files for email templates and other rendered content

These views can then be referenced in the application using the notifications:: namespace prefix, such as notifications::email.default for email templates. This is used by the MailChannel when rendering email notifications. For more information on email message formatting, see Mail Messages.

Sources: src/NotificationServiceProvider.php13

Bootstrap Flow Diagram

This diagram illustrates the bootstrap sequence from application start through view registration, showing how the package becomes ready for use.

Sources: src/NotificationServiceProvider.php11-14

---

Directory Structure

Based on the PSR-4 autoloading configuration and package conventions, the package follows this directory structure:

hypervel/notifications/
├── composer.json # Package definition and dependencies
├── src/ # Source code (Hypervel\Notifications namespace)
│ ├── NotificationServiceProvider.php
│ ├── ConfigProvider.php
│ ├── ChannelManager.php
│ ├── NotificationSender.php
│ ├── AnonymousNotifiable.php
│ ├── Channels/ # Channel implementations
│ │ ├── MailChannel.php
│ │ ├── DatabaseChannel.php
│ │ ├── BroadcastChannel.php
│ │ └── Slack/
│ ├── Messages/ # Message types
│ │ ├── MailMessage.php
│ │ ├── SimpleMessage.php
│ │ ├── SlackMessage.php
│ │ └── BroadcastMessage.php
│ └── Jobs/ # Queue job classes
│ └── SendQueuedNotifications.php
└── publish/
 └── resources/
 └── views/ # View templates for email rendering

This structure separates concerns into logical directories while maintaining a flat namespace structure within the Hypervel\Notifications namespace.

Sources: composer.json23-27

---

Summary

The Hypervel Notifications package integrates with the Hyperf framework through a two-phase bootstrap process:

1. ConfigProvider Phase: The ConfigProvider class registers service bindings, factories, and configuration with the dependency injection container
2. ServiceProvider Phase: The NotificationServiceProvider loads view templates for email rendering

The package depends on seven Hyperf framework components for core functionality and five Hypervel ecosystem packages for specialized capabilities like mail, queue, and broadcasting. All source code is autoloaded using PSR-4 from the src/ directory under the Hypervel\Notifications namespace.

For details on how these components work together to dispatch notifications, see System Architecture.