File Laravel Package

Product Decisions This Supports

• Legacy dependency triage, not net-new capability. hoa/file is an archived 2017-era filesystem abstraction (files, directories, streams, filters, watchers, locking). The decision it informs is "what do we do about the code that already uses it," not "should we build a feature on it."
• Build vs. buy for filesystem abstraction. If a roadmap item needs remote storage, S3/GCS adapters, or pluggable filesystems, the buy decision points to league/flysystem; for local-only operations, symfony/filesystem or PHP's native SPL (SplFileObject, stream wrappers). hoa/file is not a competitive option in that comparison — it is a reference design, not a candidate.
• Platform modernization / PHP upgrade scoping. Any PHP 8.x migration, framework upgrade, or SBOM/security review will surface this package. The PM decision is sequencing: is replacing it blocking the upgrade, or can it be isolated behind an interface first?
• Compliance and vendor-risk reporting. "Archived: yes," last release 2017-07-11, and zero dependents in the ecosystem are all inputs to an abandoned-dependency register that security and procurement stakeholders will ask for.
• Pattern reference for ingestion/pipeline features. The library's stream-filter and file-watcher model is a useful mental model when specifying a data-ingestion or log-tailing feature — but the value is conceptual. Do not copy the dependency to capture it.
• Explicitly not supported: new feature delivery, performance work, or anything customer-facing. There is no realistic path where adding this package advances a product goal.

When to Consider This Package

Consider it only in the narrow case where it is already in the codebase and working:

• The application is pinned to a PHP version where it still runs, the file-handling paths are covered by tests, and the cost of touching them exceeds the risk of leaving them alone this quarter.
• You specifically depend on the Hoa stream/filter/watcher API surface (e.g., Hoa\Stream filter chains, inotify-backed watchers) and a rewrite would be a multi-sprint effort for no user-visible gain.
• You are reading it as a design reference for an internal abstraction layer, with no intention of adding it to composer.json.

Look elsewhere in every other case:

• Archived upstream. No security patches, no PHP 8.x guarantees, no issue triage. Treat any CVE or runtime break as yours to fix permanently.
• Zero dependents in the ecosystem is a weak health signal — you will not find a community maintaining a fork when it breaks.
• Local and cloud filesystem work: league/flysystem (adapters, well maintained) or symfony/filesystem + symfony/finder for local operations.
• Streams and filters specifically: native PHP stream wrappers and php://filter cover most needs without a dependency.
• Anything greenfield. Do not introduce an archived package into a new service; the maintenance cost lands on a team that did not choose it.

How to Pitch It (Stakeholders)

To executives: This is a risk line item, not an opportunity. hoa/file is an abandoned PHP filesystem library — last release 2017, repository archived, no active dependents. It delivers no differentiating capability; it only appears in older code paths. Recommend we (a) inventory where it is used, (b) stop any new adoption, and (c) fund a timeboxed replacement behind our existing file-service interface. Framing it as "we are removing an unsupported dependency before it blocks our PHP upgrade" is the message that lands.

To engineering: We are not asking for a rewrite of file handling. We are asking for one interface boundary plus a swap to league/flysystem (or Symfony Filesystem where scope is local-only), with the existing test suite as the safety net. Sequence it so the interface lands first and the dependency can be removed incrementally rather than as a big-bang migration.

To security and procurement: The package receives no upstream patches. That is acceptable only while it is isolated and inventoried; it is not acceptable as a permanent state. Add it to the abandoned-dependency register with an owner and a target removal date.

The one-line pitch: Low strategic value, real maintenance risk — contain it, replace it, and stop the bleeding.