Integration with Hyperf

This document explains how the hypervel/hashing package integrates with the Hyperf framework's dependency injection container and configuration system. It covers package discovery, service registration, configuration publishing, and runtime resolution.

For usage examples of the hashing service, see Usage Guide. For configuration details, see Configuration.

Package Discovery

Hyperf automatically discovers and loads packages through a convention defined in composer.json. The package registers itself with Hyperf's component discovery system using the extra.hyperf.config key.

Discovery Mechanism

The composer.json file declares the ConfigProvider class as the package's integration point:

composer.json37-40

When Hyperf bootstraps, it scans all installed packages for the extra.hyperf.config key and invokes the specified class. The framework expects the class to have an __invoke() method that returns a configuration array.

Sources: composer.json1-45

ConfigProvider Class

The ConfigProvider class is the central integration point between the package and Hyperf. It returns a configuration array containing service bindings and publishable files.

ConfigProvider Structure

Configuration Key	Purpose	Type
dependencies	Service container bindings	Array of interface-to-class mappings
publish	Publishable configuration files	Array of publish definitions

The ConfigProvider implementation:

src/ConfigProvider.php9-28

Sources: src/ConfigProvider.php1-29

Service Registration

The package registers two service bindings in Hyperf's dependency injection container. These bindings determine how the hashing service is resolved when applications request it.

Service Bindings

Primary Binding: Hasher Interface

src/ConfigProvider.php15

This binding maps the Hasher interface to the HashManager class. When application code type-hints Hasher or requests it from the container, Hyperf resolves it to a HashManager instance.

Resolution Example:

Alias Binding: Default Driver

src/ConfigProvider.php16

This factory binding provides direct access to the default driver instance. The factory function receives the container, resolves the Hasher (which returns HashManager), and calls the driver() method to get the default driver.

Resolution Flow:

1. Container receives request for 'hash.driver'
2. Factory function is invoked with $container parameter
3. Factory resolves Hasher::class → returns HashManager instance
4. Factory calls $hashManager->driver() → returns default driver instance (e.g., BcryptHasher)

Sources: src/ConfigProvider.php14-17

Runtime Resolution Flow

The following diagram shows how service resolution works at runtime when application code requests the hashing service.

Service Resolution Sequence

Resolution Patterns

Pattern 1: Type-Hint Injection

Pattern 2: Direct Container Resolution

Pattern 3: Driver-Specific Access

Sources: src/ConfigProvider.php14-17

Configuration Publishing

The package provides a publishable configuration file that applications can customize. Publishing copies the default configuration from the package to the application's configuration directory.

Publishing Mechanism

Publish Configuration Definition

src/ConfigProvider.php18-25

The publish definition contains:

Key	Value	Description
id	'config'	Identifier for this publishable resource
description	'The configuration file of hashing.'	Human-readable description
source	__DIR__ . '/../publish/hashing.php'	Source file in package
destination	BASE_PATH . '/config/autoload/hashing.php'	Destination in application

Publishing the Configuration

Applications publish the configuration using Hyperf's vendor:publish command:

When prompted, select the config option. This copies the default configuration file to the application's config/autoload/ directory, where it can be customized.

Configuration Merge Order:

1. Package default configuration (in memory, from package code)
2. Published configuration file (if exists in config/autoload/hashing.php)
3. Environment variables (for runtime overrides)

Sources: src/ConfigProvider.php18-25

Dependency Requirements

The package requires specific Hyperf framework packages as dependencies. These dependencies enable the integration features.

Required Hyperf Packages

Package	Version Constraint	Purpose
hyperf/config	~3.1.0	Configuration system access
hyperf/context	~3.1.0	Context management for coroutines
hyperf/support	~3.1.0	Base Manager class for driver factory pattern

composer.json28-32

Version Compatibility

The package strictly requires Hyperf version 3.1.x (~3.1.0 constraint). This means:

• Compatible with: 3.1.0, 3.1.1, 3.1.2, etc.
• Not compatible with: 3.0.x or 3.2.x

PHP Version Requirement

composer.json29

The package requires PHP 8.2 or higher, leveraging modern PHP language features.

Sources: composer.json28-32

Integration Summary

The following table summarizes the integration points between the package and Hyperf:

Integration Point	Mechanism	Code Reference
Package Discovery	composer.json extra.hyperf.config	composer.json38-40
Service Registration	ConfigProvider::__invoke() dependencies	src/ConfigProvider.php14-17
Configuration Publishing	ConfigProvider::__invoke() publish	src/ConfigProvider.php18-25
PSR-4 Autoloading	composer.json autoload.psr-4	composer.json23-26
Framework Dependencies	composer.json require	composer.json28-32

Complete Integration Flow:

Sources: composer.json1-45 src/ConfigProvider.php1-29