Local Storage Adapter Extension Laravel Package

Technical Evaluation

What this package is. A single-purpose Laravel package that registers a local filesystem storage adapter into the Anomaly Labs Files module (the PyroCMS 3 / Streams ecosystem). It is an "extension" in Anomaly's plugin sense: a service provider that binds an adapter class into the Files module's adapter registry so a storage disk can be selected in the control panel. It is a leaf dependency — it does not itself provide file management, uploads, or a UI.

Architecture fit. Fit is binary and narrow. It is a good fit only if the host application is a PyroCMS 3 / Anomaly Streams application with the Files module installed and a requirement to expose "local" as a selectable storage adapter in that module's configuration. Outside that exact context the package has no architectural home: it is not a general Flysystem adapter, not a Laravel filesystem driver, and provides nothing Laravel's built-in local disk does not already provide via config/filesystems.php.

Integration feasibility. Low, and falling. A 2015-08-01 release places it in the Laravel 5.0–5.2 / Flysystem 1.x era. Realistic blockers:

• illuminate/support constraints will conflict with Laravel 8/9/10/11; Composer resolution will fail before you see a runtime error.
• Flysystem 1.x League\Flysystem\Adapter\Local was removed in v2/v3; the adapter class this package registers no longer exists in modern dependency trees.
• The upstream anomaly/files-module has itself drifted (and Anomaly Labs' commercial focus shifted), so the registry contract this package targets may no longer match.

Technical risk. Split assessment:

• Runtime/security risk: low. The scope is a local filesystem adapter; there is little attack surface beyond the usual path-traversal and permissions concerns inherited from Flysystem.
• Obsolescence/supply-chain risk: high. 0 stars, 0 dependents, one release eight years ago, no visible CI or test suite. There is no downstream population to surface bugs, no security advisory coverage, and no maintainer response path. The package is effectively an unmaintained code sample.
• Value risk: high. Laravel already ships a local disk driver; the Files module may already register one. We may be adopting a dependency to obtain behavior we already have.

Key questions for the team.

1. Are we actually running PyroCMS 3 / Anomaly Streams, or is this being evaluated for a stock Laravel app? (If the latter, stop here.)
2. Which anomaly/files-module version is in composer.lock, and does it already register a local adapter?
3. What concrete gap does this fill that Storage::disk('local') does not?
4. What PHP/Laravel/Flysystem versions are we pinned to, and is the 2015 constraint set resolvable at all?
5. Is there an internal owner willing to fork and maintain it, or is this a "nice to have" that will rot?
6. Does our deployment target ephemeral containers or multi-node autoscaling? (Local disk is disqualifying if so.)

Integration Approach

Stack fit. Only compatible with: PHP 5.5–7.0 era, Laravel 5.x, Flysystem 1.x, Anomaly Files module of matching vintage. Do not attempt to slot it into a modern Laravel service container; the extension registration pattern and the Flysystem adapter base class both changed materially.

Migration path. Recommended: do not adopt the package as a dependency. Two acceptable paths:

1. Replace with native capability (preferred). Configure a local disk in config/filesystems.php and use Storage::disk('local'). Zero new dependencies, zero maintenance, works on every supported Laravel version. If the Files module needs an adapter to appear in its UI, check whether it already ships one before writing anything.
2. Fork and vendor (only if path 1 is blocked). Copy the ~1–2 files into an internal namespace (e.g. App\Filesystem\LocalAdapterExtension), rewrite the adapter to extend League\Flysystem\Local\LocalFilesystemAdapter (Flysystem 3) or Laravel's FilesystemAdapter, and register it from an application service provider you control. Wire it in via a Composer path repository or plain App\ autoloading — never via Packagist, so we are not silently pinned to an abandoned tag.

Compatibility work required if forking. Update composer.json constraints; remove Flysystem 1.x imports; add a PHP 8 type-safety pass (implicit nullable params, dynamic properties); verify the Files module's adapter registry contract against the installed version; add a smoke test that writes, reads, and deletes a file through the adapter.

Sequencing.

1. Day 0–1 — Gap validation. Confirm the host app is PyroCMS/Streams and that no built-in local adapter exists. This is the go/no-go gate; expect it to resolve to "no gap."
2. Day 1–2 — Compatibility spike. In an isolated branch, attempt composer require and record the exact conflict. If unresolvable, that is the finding, not an obstacle to route around.
3. Day 2–4 — Fork or native substitution. Implement the chosen path behind a thin internal interface so the decision is reversible.
4. Day 4–5 — Test and document. Integration test against the real Files module; document the storage path, permissions, and disk config.
5. Before any production deploy — confirm storage is on a persistent volume, and put a migration note in the runbook.

Operational Impact

Maintenance. Full ownership transfers to us on day one. Upstream is dormant: no issue triage, no security patches, no Flysystem 2/3 port. Budget a recurring tax at every Laravel/PHP major upgrade — the fork will need the same compatibility work each cycle, and it will never be handled by someone else. Treat the package as source code we copied, not as a dependency we consume.

Support. Effectively none. With 0 stars and 0 dependents there is no issue corpus, no Stack Overflow footprint, and no third-party blog coverage to lean on. Troubleshooting means reading 2015-era Anomaly extension conventions from scratch. Internal SME dependency is a single-point-of-failure risk; at minimum, two engineers should be able to explain the registration path.

Scaling. The local adapter is a single-node storage strategy and does not scale horizontally:

• Containers with ephemeral filesystems will lose files on every deploy/restart.
• Multi-node or autoscaling fleets will produce split-brain storage — a file written on node A is invisible to node B.
• No CDN or object-store offload; bandwidth and disk I/O land on the app tier.
• Needs explicit quota/retention policy, or disk fills and the node fails.

If any of the above apply, the correct answer is an object-store adapter (S3-compatible), not this package.

Failure modes to plan for.

• Silent write failures: adapter registry mismatch after a Files module update — uploads appear to succeed but land nowhere or in an unexpected path.
• Composer lock drift: a transitive bump makes the package unresolvable; CI breaks on an unrelated PR.
• PHP 8 fatal errors on the Flysystem 1.x adapter base class if the fork is not fully ported.
• Unpatched CVEs in the pinned Flysystem 1.x line, with no upstream to ship a fix.
• Permission/path issues on the local volume (web user ownership, SELinux, read-only mounts).
• Data loss on redeploy when storage is not a mounted persistent volume.

Ramp-up. Code volume is trivial (a handful of files) but context cost is high: engineers must learn Anomaly's extension/registry pattern, the Files module's adapter contract, and the Flysystem 1.x API simultaneously — all from unpinned, undocumented, decade-old source. Estimate 1–2 days for a senior Laravel engineer to reach confident literacy, plus 1–2 days of hands-on compatibility work. That is a poor return for a package whose entire functional contribution is "write to a local directory."

Recommendation. Do not add this as a dependency. Close the evaluation with the two questions that decide it — "Are we on PyroCMS 3/Streams?" and "Does the Files module already provide local storage?" — and if both are yes, implement the adapter internally in under 100 lines with a test. Adopting a zero-star, eight-year-old, single-release package as infrastructure creates a permanent maintenance obligation for near-zero differentiated value.