File Field Type Laravel Package

Technical Evaluation

Architecture fit. anomaly/file-field_type is not a standalone Laravel package — it is a field-type addon for the Anomaly Streams Platform (the data/streams layer underpinning PyroCMS 3.x). Architecturally it registers itself into the platform's field-type registry and delegates actual file persistence to the companion anomaly/files-module. That means its "fit" is binary: it is a clean, idiomatic citizen inside a Streams-based application and a non-starter anywhere else. It should be evaluated as an extension point, not as a library you composer require into an arbitrary Laravel app.

Integration feasibility. Feasible only under explicit preconditions: a Laravel version supported by the installed Streams Platform release, the files module present and migrated, and a stream/assignment defined to carry the field. There is no meaningful path to use the field type in isolation, and no adapter layer to graft it onto Eloquent models. Feasibility therefore reduces to "are we already committed to Streams?"

Technical risk.

• Signal quality: 0 stars / 0 dependents on this repo almost certainly reflects a split/read-only mirror of a monorepo subpackage, not real adoption. Treat popularity metrics as untrustworthy in both directions.
• Version drift: the field type's composer.json constraints must line up with the Streams Platform and files module versions; mismatches typically surface as field-type registration failures at boot rather than clear dependency errors.
• Coupling: behavior (storage disk, path conventions, validation, thumbnails/transformations) is largely inherited from the files module, so failure modes often live one layer away.
• Maintenance opacity: commit history is not visible here; the real cadence must be checked in the upstream Streams/PyroCMS repository.
• License: MIT is permissive and low-risk, but confirm the upstream module and platform carry compatible terms.

Key questions.

1. Which Streams Platform / PyroCMS major does this branch target, and what Laravel/PHP versions does that imply?
2. Is anomaly/files-module a hard dependency, and which version range is pinned?
3. Does the field type abstract the storage disk (local/S3/etc.), or assume a specific adapter?
4. How are file deletions, orphaned records, and cascade behavior handled when an entry is removed?
5. What validation and MIME/size controls are exposed through the field configuration UI?
6. Is upstream maintenance active (issues triaged, releases tagged), and where is the canonical source?

Integration Approach

Stack fit. PyroCMS 3.x / Anomaly Streams Platform on Laravel. If the target application is already Streams-based, this is a natural, low-friction addition. If it is a bespoke Laravel app, the correct decision is to not adopt this package — either write a small custom file-upload layer or adopt the platform wholesale.

Migration path.

1. Pin the Streams Platform version in the application.
2. Install and migrate anomaly/files-module (storage config, disks, permissions).
3. Require anomaly/file-field_type at the matching version.
4. Register a file field on the target stream/assignment via the admin UI or a seeder/migration.
5. Configure the field (allowed types, size limits, storage location, multiple/single).
6. Backfill or migrate any existing attachment data into the files module's expected storage layout.
7. Smoke-test upload, display, download, and delete on a representative entry.

Compatibility. Verify three axes before committing: platform version ↔ field type version, files module ↔ field type version, and Laravel/PHP ↔ platform version. Any deviation typically fails at boot or at field-render time, so pin all three in composer.json and in CI.

Sequencing. The dependency order is fixed and must be respected: platform → files module → file field type → stream/assignment configuration → data migration. Attempting to define the field before the module and its storage are in place produces confusing runtime errors. For brownfield apps, run a parallel environment with the full chain installed and validate against a copy of production data before cutover.

Operational Impact

Maintenance. Expect to track the upstream Streams/PyroCMS release train rather than this mirror's tags. Because the package is small and highly coupled, upgrades are usually "safe or broken," not "subtly degraded" — which makes a pinned lockfile and staged upgrades the primary maintenance control. Budget effort for periodic platform upgrades rather than this package in isolation.

Support. Support flows through the Anomaly Labs / PyroCMS community (GitHub issues, docs, community channels) rather than commercial SLAs. For a business-critical deployment, plan for internal ownership of the field type: forkability under MIT is the real support guarantee.

Scaling. File I/O cost is dominated by the files module and the configured storage disk, not by the field type. The field type itself is thin metadata and adds negligible overhead per entry; scaling concerns are storage throughput, CDN/transform caching, and database joins when listing entries that reference files. Multiple files per entry will multiply the metadata rows and any eager-loading requirements — verify query behavior under realistic list views.

Failure modes.

• Field-type registration/autoload failure after an upgrade (class not found, interface drift).
• Missing or misconfigured files module — uploads appear to succeed but nothing persists.
• Storage path/permission mismatches, especially with non-local disks.
• Orphaned files when entries are deleted, if cascade behavior is not configured.
• Schema/migration ordering issues on fresh installs.
• Silent no-op on invalid MIME/size configuration exposed to editors.

Ramp-up. For a developer already fluent in PyroCMS/Streams, this is hours — read the field type's class, understand the files module contract, wire it up. For a Laravel developer without Streams exposure, budget days: the Streams abstractions (streams, assignments, fields, field types, addon bootstrapping) are the real learning curve, and this package only makes sense once those are internalized. Include at least one admin/editor-facing walkthrough, since field configuration is a UI surface that non-developers will operate.