Composer, Autoloading, Testing, and Tooling

Composer Basics

composer require vendor/package
composer install
composer update
composer dump-autoload

Do not run composer update casually on production. Commit or package the exact dependency set intended for release.

composer.json

{
  "name": "example/my-plugin",
  "type": "wordpress-plugin",
  "autoload": {
    "psr-4": {
      "MyPlugin\\": "src/"
    }
  },
  "require": {}
}

Load Autoloader

require_once __DIR__ . '/vendor/autoload.php';

If the production package expects Composer autoloading, include vendor/ or build it during deployment.

PSR-4 Example

File path:

src/Admin/SettingsPage.php

Class:

namespace MyPlugin\Admin;

final class SettingsPage {}

PHP Lint and Coding Standards

php -l path/to/file.php
vendor/bin/phpcs
vendor/bin/phpcbf

WordPress projects commonly use WordPress Coding Standards.

Static Analysis

Common tools:

• PHPStan
• Psalm
• PHP_CodeSniffer
• Rector

Static analysis can catch type, method, and flow issues before runtime.

PHPUnit

final class DiscountTest extends TestCase {
    public function test_discount_is_calculated(): void {
        $this->assertSame(10.0, myplugin_discount(100.0, 0.1));
    }
}

Test Levels

Level	Good For
Unit	Pure functions and services
Integration	WordPress hooks, database, options, REST
End-to-end	Browser flows, checkout, forms, editor behavior

Release Package Checklist

• Include required PHP files.
• Include built assets.
• Include runtime Composer dependencies if the server will not install them.
• Exclude tests, local config, caches, and development artifacts when appropriate.
• Update plugin or theme version headers.
• Test install from the actual zip artifact.

Common Tooling Pitfalls

• Running checks locally but not in CI.
• Ignoring all warnings because there are too many.
• Shipping source that requires Composer without shipping dependencies.
• Updating dependencies without testing integrations.
• Testing only pure functions while ignoring WordPress hooks and permissions.