php-file-iterator: published as phpunit/php-file-iterator, maintained on two lines

It extends FilterIterator, so it filters another iterator's output

The class name and the description together tell you the shape of the thing. It is a FilterIterator implementation, and it filters files based on a list of suffixes, prefixes, and other exclusion criteria. Placing it in PHP's FilterIterator family means it does not open files or walk directories by itself: it wraps whatever iterator you hand it and decides which of that iterator's values pass through. That has a practical consequence for how you evaluate it. The interesting configuration is not a file path or an option in a config file, it is the criteria list you construct, plus the traversal you compose it with. It also means the class is a filter in the strict sense, not a scanner, so if what you need is recursive discovery rather than rejection of unwanted entries, this is the wrong shape of tool and you should be looking for a directory iterator to wrap instead.

The package name is phpunit/php-file-iterator, not sebastianbergmann

There are two identifiers in play and only one of them is what you type. The repository is sebastianbergmann/php-file-iterator, and the GitHub Actions, shepherd.dev and codecov badge links on the README point there. The package you require, however, is published under the phpunit vendor namespace as phpunit/php-file-iterator. The divergence is not cosmetic when you are searching for it. A developer who greps for the repository name will find build results filed under the repository path while Composer insists on the phpunit prefix, and a require written with the wrong vendor name simply fails to resolve. The README's own example settles the question, since the installation command is written with the phpunit namespace and that is what you should copy. The vendor prefix also tells you the intended consumer before you read a line of code.

Six and seven were both patched on 2026-08-25

The release list is three tags long and one detail stands out. Version 7.0.2 was published on 2026-08-25, and version 6.0.2 was published on 2026-08-25 as well, seven minutes earlier, after 7.0.1 from 2026-08-10. Two major lines receiving patches on the same afternoon is a deliberate maintenance arrangement rather than an accident, and it has a direct effect on how you depend on the package. There is a 7.x line and a 6.x line, both alive, and the newest tag is not the whole story. Whatever constraint pushed you toward the older line is still being served, which is the useful part. What it does not tell you is which line you should move to, because that decision depends on your own project rather than on this repository, and nothing in the fifty five word README addresses it. The ChangeLog.md file in the tree is where the per version detail would live.

Two composer commands, and one of them is about your test suite

Installation is the entire body of the README, and it offers two variants of one command:

composer require phpunit/php-file-iterator

composer require --dev phpunit/php-file-iterator

The first adds the library as a local, per-project dependency. The second is for the case where you only need it during development, and the example given is running your project's test suite. That distinction is not cosmetic: it decides whether the package lands in your require block or your require-dev block, which changes what gets installed on a production machine and what shows up when someone audits your dependencies. The rest of the page is badges, and everything else you would want to know, the constructor signature, the criteria you can pass, the behaviour of the exclusion rules, is in src/ with its tests in tests/.

The toolchain is checked in, including PHIVE-managed binaries and Phing

The top level of the repository is more informative than the README. There is a .phive/ directory and a tools/ directory, which is how PHAR-based tool management is normally laid out, plus build.xml and a build/ directory. Static analysis is configured through phpstan.neon, code style through .php-cs-fixer.dist.php, and the test run through phpunit.xml. Dependency updates are handled by renovate.json, and there are ChangeLog.md, SECURITY.md, LICENSE and .gitattributes alongside composer.json. The reading this invites is simple. The project applies to itself the tooling it expects of its users, which is a reasonable signal about the maintainer's standards, and it means the style and analysis rules are pinned in the tree rather than left to a global setup. For you it also means phpstan.neon is not an API contract you can rely on; it is the author's own threshold for his own code.

A fifty five word README means the code is the documentation

It is worth being blunt about what this project gives you to read. The README contains a heading, a set of badges and the installation section, and nothing else. There is no usage example, no list of criteria types, no note about recursion, symlinks, ordering or error handling, and no statement about which PHP versions each line supports. That is not necessarily a criticism, since a filter with a small surface can be understood by reading it, but it does change how you evaluate the dependency. You are making a decision from src/ and tests/, and the tests are the more informative of the two because they show what the filter accepts and what it rejects. It also means documentation for this package, if you want prose, will come from elsewhere or from your own notes. Plan for a twenty minute read of the implementation rather than a two minute skim of a manual, because there is no manual here.

No homepage, a BSD licence, and pushes as recent as 2026-10-03

The administrative picture is short. The licence is BSD-3-Clause, there is no project homepage listed beyond the repository itself, and the default branch is main. The repository is not archived and the last push is dated 2026-11-02, so the code is being touched even though the last release tag is from August. That combination, active branch work with a quiet release line, is normal for a small library maintained alongside a bigger project and it tells you where to look for change. The ChangeLog.md in the tree is the record of released work, renovate.json is what will pull dependency updates, and SECURITY.md is the file to read if you have a disclosure rather than a bug. If you depend on the package, watch the branch for changes and the changelog for anything that actually shipped.

Editorial conclusion

Use it when you already have something walking a directory and you want a declarative rule for which files matter. Skip it if you need a recursive walker of its own, because it filters rather than traverses. Before adopting, read src/ and tests/ rather than the README, because the page documents installation only, and pin the line you depend on, since both 6.0.2 and 7.0.2 were published on the same day and the two are not interchangeable.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes