PEAR History And Legacy References

PEAR predates Composer and appears in older PHP documentation and codebases. Modern applications normally use Composer, but developers still encounter PEAR packages, include paths, and legacy installation instructions.

Working Knowledge

• Recognise PEAR-style global installation and include-path assumptions.
• Prefer maintained Composer packages for new work.
• Do not replace a legacy dependency blindly without checking behaviour and callers.
• Inventory old bootstrap files and deployment steps before migration.
• Use tests to preserve behaviour while removing global environment assumptions.

Recognise The Old Shape

Older projects may rely on global include paths:

<?php

declare(strict_types=1);

require_once 'Mail.php';
require_once 'HTTP/Request2.php';

Those files may come from server-level PEAR installation rather than the repository. A fresh developer machine or container can fail even though the production server still works.

Inventory Before Replacing

Find the installed package version, bootstrap files, include-path configuration, deployment steps, and call sites. Add tests around the behaviour the application relies on before moving to a maintained Composer package.

Modernisation is not only changing a require_once. Configuration keys, return values, exception behaviour, encodings, and transport defaults may differ.

In Application Work

Legacy knowledge is useful because old applications may rely on server-level packages that are invisible in composer.json. Make those dependencies explicit before modernising them.

What To Check

Before moving on, make sure you can recognise PEAR-era includes, inventory an invisible server dependency, and plan a behaviour-preserving Composer migration.