VOOZH about

URL: https://deepwiki.com/MahoCommerce/maho-composer-plugin/6-development-and-quality-assurance

⇱ Development and Quality Assurance | MahoCommerce/maho-composer-plugin | DeepWiki

Loading...
Loading...
Menu

Development and Quality Assurance

Purpose and Scope

This document describes the comprehensive quality assurance infrastructure that protects the maho-composer-plugin codebase from defects and regressions. The system implements a multi-layered validation strategy combining static analysis, continuous integration workflows, and development environment safeguards to enforce code quality standards before any changes reach production.

For detailed information about specific components:

Quality Assurance Architecture

The quality assurance system implements four parallel validation layers that execute automatically on every push and pull request. Each layer focuses on a different quality dimension, creating comprehensive coverage that prevents common classes of defects.

Quality Gate Matrix

Quality GateConfiguration FileValidation TargetBlocking Failure
Static Analysis.phpstan.dist.neonType safety, strict rules, deprecationsYes
Composer Validation.github/workflows/composer.ymlPackage definition integrityYes
Line Ending Check.github/workflows/line-endings.ymlCRLF consistencyYes
PHP Syntax Check.github/workflows/syntax-php.ymlParse errors, syntax validityYes

All quality gates must pass before code can be merged. The system is configured with fail-fast: false in workflows to provide complete feedback on all issues rather than stopping at the first failure.

Sources: .phpstan.dist.neon1-13 .github/workflows/composer.yml1-31 .github/workflows/phpstan.yml1-46

Diagram: Quality Assurance Pipeline Architecture



Sources: .github/workflows/composer.yml3-7 .github/workflows/phpstan.yml3-8 .phpstan.dist.neon10-12




Static Analysis Configuration


The project enforces maximum strictness through PHPStan level 10 analysis with additional rule sets. The configuration file .phpstan.dist.neon1-13 includes four distinct rule collections that work together to catch potential defects.


PHPStan Rule Set Composition
































Rule SetSourcePurpose
Bleeding Edgevendor/phpstan/phpstan/conf/bleedingEdge.neonLatest type inference improvements
Strict Rulesvendor/phpstan/phpstan-strict-rules/rules.neonEnforce type strictness, disallow unsafe patterns
Deprecation Rulesvendor/phpstan/phpstan-deprecation-rules/rules.neonDetect usage of deprecated PHP features
Composer Rulesvendor/composer/composer/phpstan/rules.neonComposer-specific type definitions


The analysis scope is limited to the src directory .phpstan.dist.neon11 and enforces PHP version compatibility between 8.2.0 and 8.4.99 .phpstan.dist.neon8-9 This range ensures the plugin remains compatible with current production PHP installations while preparing for future versions.


Sources: .phpstan.dist.neon1-13




Diagram: PHPStan Analysis Configuration and Execution




Sources: .phpstan.dist.neon1-13 .github/workflows/phpstan.yml9-46




Continuous Integration Workflow Orchestration


The CI/CD system implements four independent GitHub Actions workflows that execute in parallel. Each workflow is triggered by the same event set: push, pull_request, workflow_call, and workflow_dispatch .github/workflows/composer.yml3-7 providing consistent validation across all code changes.


Composer Validation Workflow


The composer.yml workflow validates package definition integrity without installing dependencies. The composer validate --strict --no-check-all command .github/workflows/composer.yml30 checks:


    

  • JSON syntax in composer.json
    • 

  • Required field presence (name, type, license)
    • 

  • Dependency version constraint validity
    • 

  • Lock file synchronization with composer.json
    • 



The --no-check-all flag limits validation to repository-defined packages, avoiding false failures from transitive dependencies.


Sources: .github/workflows/composer.yml1-31


PHPStan Analysis Workflow


The phpstan.yml workflow implements a unique dual-analysis strategy through matrix execution .github/workflows/phpstan.yml14-18 For pull requests, it analyzes both:


    

  • target-branch: The merge destination (e.g., main)
    • 

  • pr-head: The proposed changes
    • 



This approach detects regressions introduced by the PR and prevents merging code that would fail analysis. The workflow uses shivammathur/setup-php@v2 to install the latest PHP version .github/workflows/phpstan.yml22-24 and runs analysis with verbose output: php vendor/bin/phpstan.phar analyze -vvv .github/workflows/phpstan.yml45


The XDEBUG_MODE=off prefix disables Xdebug during analysis to improve performance.


Sources: .github/workflows/phpstan.yml1-46




Diagram: Workflow Execution and Caching Strategy




Sources: .github/workflows/composer.yml18-27 .github/workflows/phpstan.yml30-45




Dependency Caching Strategy


Both workflows implement identical caching strategies to accelerate CI execution. The cache key uses three components:


    

  1. Runner OS: ${{ runner.os }} - Isolates caches by operating system
    2. 

  2. Static prefix: composer - Identifies cache purpose
    3. 

  3. Lock file hash: hashFiles('**/composer.lock') - Invalidates on dependency changes
    4. 



The cache stores the directory returned by composer config cache-files-dir .github/workflows/composer.yml20 which contains downloaded package archives. The restore-keys fallback .github/workflows/composer.yml27 allows partial cache hits when composer.lock changes but the OS remains the same.


Cache Key Structure


${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
 | | |
 | | └─ SHA-256 of composer.lock
 | └─ Cache namespace
 └─ Operating system (ubuntu, macos, windows)



Sources: .github/workflows/composer.yml24-27 .github/workflows/phpstan.yml34-39




Development Environment Configuration


The .gitignore file defines exclusion patterns for local development artifacts, ensuring clean version control history. The configuration implements a distributed-vs-local pattern for PHPStan configuration files.


Git Ignore Pattern Categories










































PatternPurposeFiles Ignored
.ideaPhpStorm IDE metadataAll PhpStorm project files
/vendorComposer dependenciesAll installed packages
.phpstan*.neonLocal PHPStan overrides.phpstan.neon, .phpstan.local.neon, etc.
phpstan*.neonAlternative PHPStan configsphpstan.neon, phpstan-baseline.neon, etc.
!.phpstan.dist.neonDistribute default configNegative pattern - include in repository
!.phpstan.dist.*.neonDistribute variant configsNegative pattern - include variants


The PHPStan patterns allow developers to create local configuration overrides (e.g., .phpstan.neon) for development purposes while ensuring the canonical .phpstan.dist.neon remains tracked in version control. This pattern supports:


    

  • Local customization: Developers can adjust analysis settings without affecting CI
    • 

  • Distributed defaults: The .dist.neon file defines the official configuration
    • 

  • Clean commits: Local overrides never accidentally commit to the repository
    • 



Sources: .gitignore1-12




Diagram: Development Environment File Organization




Sources: .gitignore1-12




Platform Requirements and Compatibility


The static analysis enforces PHP version compatibility through the phpVersion parameter in .phpstan.dist.neon7-9 The specified range (8.2.0 to 8.4.99) defines the supported PHP versions for the plugin.


PHP Version Compatibility Matrix































PHP VersionMinimumMaximumAnalysis Mode
8.28.2.0 (80200)8.2.999Strict type checking
8.38.3.08.3.999Strict type checking
8.48.4.08.4.99 (80499)Strict type checking


The PHPStan workflow uses php-version: latest .github/workflows/phpstan.yml24 to run analysis with the newest available PHP version, ensuring forward compatibility. The composer install --ignore-platform-req=ext-* flag .github/workflows/phpstan.yml42 bypasses extension requirements during CI execution, allowing analysis to proceed even if optional PHP extensions are unavailable in the GitHub Actions environment.


Sources: .phpstan.dist.neon7-9 .github/workflows/phpstan.yml22-42




Quality Gate Enforcement Strategy


The GitHub Actions workflows implement strict enforcement through multiple mechanisms:


    

  1. Parallel execution: All workflows run simultaneously via push and pull_request triggers
    2. 

  2. Non-fast-fail strategy: fail-fast: false .github/workflows/phpstan.yml14 ensures all checks complete even if one fails
    3. 

  3. Matrix execution: PHPStan analyzes both target branch and PR head to detect new issues
    4. 

  4. Status checks: GitHub branch protection rules can require all workflows to pass before merge
    5. 



This multi-gate approach ensures that:


    

  • No syntactically invalid PHP code enters the repository
    • 

  • Package definitions remain valid and installable
    • 

  • Static analysis standards are maintained at level 10
    • 

  • Line ending consistency is preserved across platforms
    • 



Any workflow failure blocks the pull request merge, requiring developer remediation before code integration.


Sources: .github/workflows/phpstan.yml14-18 .github/workflows/composer.yml29-30