phar-io/manifest: load or build phar.io manifests in PHP

Two directions: load a manifest.xml, or build one in code

The library does both halves of the job, and the split is the thing to understand first. In one direction you point a loader at a file and get a value object back, then hand that object to a serializer if you want the XML out again:

use PharIo\Manifest\ManifestLoader;
use PharIo\Manifest\ManifestSerializer;

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

echo (new ManifestSerializer)->serializeToString($manifest);

In the other direction you construct the same object graph from parts, which is what a build step actually wants. The pieces named in the example are an ApplicationName, a Version, a type such as Library, a CopyrightInformation built from an AuthorCollection and a License, and a BundledComponentCollection holding BundledComponent entries. The consequence is that this is a model plus a serializer rather than a string helper. If you already have a manifest.xml you can round-trip it; if you are producing one, you construct the object and let the library decide the XML.

manifest.xsd is checked in, so the XML is a contract and not a convention

Among the top level files is manifest.xsd, a schema for the document this library reads and writes, and the example output shows what it describes. The root element is `<phar>` inside the namespace `https://phar.io/xml/manifest/1.0`, followed by a `<contains>` element carrying the application name, version and type, then a `<copyright>` block with a `<license>` element, a `<requires>` block holding `<php version="*"/>`, and a `<bundles>` block listing components. Two things follow. First, the schema is available to you, so a manifest your build produces can be validated rather than eyeballed. Second, the schema version is baked into the namespace URI, which means a document is self identifying about which manifest generation it claims to conform to. That is the mechanism that lets a consumer decide whether it understands a file, rather than guessing from element names.

Both README examples are truncated, so copying them produces broken code

The README shows two usage examples, loading a manifest.xml and building one through the API, and the examples directory in the repository holds example-01.php and example-02.php alongside them.

Bundled components and the containing application are separate elements

The XML sample is where the model's purpose becomes clear. The `<contains>` element describes the archive itself, with a name, a version and a type such as library, while the `<bundles>` element lists what is inside it, here a single component named vendor/packageA at version 1.2.3-dev. In code that separation is the difference between a BundledComponentCollection holding BundledComponent entries and the ApplicationName and Version passed to the Manifest constructor. The detail that will catch you out is that a development version string is a normal value here: 1.2.3-dev goes into a bundle entry without any special treatment. If your build produces a prerelease archive, this is where that version belongs, and if you get the nesting wrong you will produce a document that is valid XML but says something different from what you meant.

Copyright information is a structured object, and the licence URL is part of it

Licensing metadata is not a free text field. CopyrightInformation takes an AuthorCollection and a License, and License is constructed with an identifier such as BSD-3-Clause plus a Url object pointing at the licence text. In the output that becomes a `<copyright>` element containing a `<license>` element with both a type attribute and a url attribute, here pointing at the SPDX page for that licence. Note also that the `<requires>` block in the same output carries a `<php version="*"/>` entry, so the manifest also records a PHP requirement, which is a third thing beyond the identity and the bundles that people forget exists.

Two releases twenty minutes apart, then a three year gap

The release list is three entries and the spacing tells a story. Version 2.0.2 was published on 2021-07-20 at 11:14 and 2.0.3 at 11:33 the same morning, nineteen minutes later, which reads like a packaging fix shipped straight after a mistake rather than a planned pair. Then nothing until 2.0.4 on 2024-03-03. The repository is not archived, and the last push is dated 2026-05-20, so branch work continues more than two years after the most recent tag without producing a release. For a dependency this is the situation to plan around rather than worry about. The surface is small, the schema is checked in, and there is no feature queue visible, so 2.0.4 is a reasonable pin. But if you need a change that has not shipped, you are reading the branch, and you should know that when you compare your installed version to someone else's.

The toolchain is PHIVE, Psalm and php-cs-fixer, all pinned in the tree

The repository carries its own development apparatus, which tells you what building and checking this code involves. phive.xml sits at the top level alongside a tools/ directory, which is how PHAR-based tool binaries are declared and installed rather than expected on your machine. Static analysis is configured through psalm.xml, code style through .php-cs-fixer.dist.php, the test run through phpunit.xml, and there is a build.xml with a build/ directory. composer.lock is committed as well, so the dependency set of the library itself is pinned. Two practical consequences for anyone consuming it. You do not need PHIVE or Psalm installed to use the package, since installation is Composer only, and the presence of a committed lock file and a schema file means the project treats reproducibility as part of its job rather than as an afterthought.

Editorial conclusion

Use it when your build tool has to emit or consume a phar.io manifest, and prefer the object API over hand-written XML so the library owns the namespace and the structure. Read the README examples together with examples/example-01.php and example-02.php in the repository. Before you depend on it, pin 2.0.4, since the two releases before it landed twenty minutes apart on the same day in 2021, and validate your manifest against the manifest.xsd that ships in the repository rather than trusting the example output.

Frequently asked questions

Official sources

1. Issues
2. phar-io/manifest on GitHub
3. Project website
4. README
5. Releases