Manifest Laravel Package

Getting Started

Install the package via Composer to enable parsing and generation of PHAR manifest metadata (manifest.xml). Its core use case is inspecting, validating, or generating standardized PHAR metadata — especially in build pipelines, PHAR packaging tools (e.g., Box, custom PHAR builders), or PHAR-aware test suites.

Start by loading an existing manifest (e.g., from a built PHAR or as a build artifact):

use PharIo\Manifest\ManifestLoader;

$manifest = ManifestLoader::fromFile('path/to/manifest.xml');

Then inspect typed metadata via methods like $manifest->getName(), $manifest->getVersion(), $manifest->getRequirements(), etc. For CI automation, you may also generate manifests programmatically (see Usage Examples) to validate compliance or produce metadata artifacts.

Implementation Patterns

• PHAR Pre-Build Validation: Before bundling, load a manifest and verify PHP requirements or bundled dependencies match expectations (e.g., fail build if php >= 8.2 is declared but toolchain targets PHP 8.0).
• Bundled Dependency Auditing: Call $manifest->getBundledComponents() to enumerate internal dependencies (e.g., detect outdated components in PHAR).
• CI Build Gates: Use $manifest->getRequirements() to enforce runtime compatibility constraints — critical for PHAR-based CLI tools distributed widely.
• Metadata Normalization: Serialize a manually constructed or edited manifest into standard XML (via ManifestSerializer) to ensure compatibility with PHAR tooling that expects phar.io spec compliance.
• Testing PHAR-handling Logic: Construct mock manifests programmatically (using the new Manifest(...) constructor) to test PHAR validation, signature checks, or metadata extraction routines in isolation.

A typical workflow: load → validate / inspect → react (log, fail, re-serialize) — no config or service container setup required.

Gotchas and Tips

• No PHAR introspection built-in: This package only parses manifest.xml. To extract it from a PHAR, you must pre-extract (e.g., Phar::xml() or archive extraction). It does not read PHAR files directly.
• Strict error handling: ManifestLoader::fromFile() throws ManifestException for invalid XML or malformed manifests — wrap all loads in try/catch and log paths for debugging.
• Email fields are nullable since v2.0.4: Author emails are optional. Guard access: if ($author->getEmail() && $email = $author->getEmail()->asString()) { ... }.
• PHP version compatibility matters: Use ^2.0.2 to avoid PHP 8.1 deprecation warnings; ^2.0.4 ensures PHP 8.4 compatibility. Avoid 2.0.0–2.0.1 on PHP ≥8.0.
• Version string normalization: The underlying phar-io/version library rejects non-SEMVER strings (e.g., v1.0 → 1.0.0). Ensure manifest authors use strict semantic versioning.
• Type safety > duck typing: The API returns strongly-typed objects (e.g., Library, ApplicationName). Prefer $manifest->getType() instanceof Library over reflection or class-name checks.