halimtuhu/array-images
A Laravel package for handling multiple images stored as arrays. Upload, save, resize, and retrieve image collections attached to your Eloquent models with simple helper methods, keeping multi-image fields like galleries and product photos organized in one column.
Architecture fit. The package is a Laravel Nova custom field that serializes uploaded image paths into a single database column as an array/JSON payload. It fits one narrow case: an admin CRUD screen on a single Eloquent model where images are decorative and never queried. It does not fit anything resembling a media library — there is no media table, no metadata, no image variants, no deduplication, and no referential integrity between the column payload and the files on disk.
Coupling and integration feasibility. Hard dependency on Laravel Nova (a paid, licensed product) and on Nova's field API as it existed in early 2019 (Nova 1.x / early 2.x era). Composer installation is trivial; making it run is not. A modern Laravel 10/11 application will almost certainly hit constraint conflicts on illuminate/* and will likely need rewrites around resolveUsing / fillUsing / withMeta, plus asset pipeline differences (the 2019 package predates Nova's Vite migration). Assume a fork rather than a clean install.
Technical risk. High, and concentrated in two places. First, abandonment: last release January 2019, 14 stars, no maintainer activity, no visible test suite — no CVE response path. Second, file handling: upload validation, storage disk selection, visibility, and deletion behavior are security-sensitive and undocumented. The array-in-a-column design also produces silent partial failures — a deleted file leaves a valid-looking path string behind, and nothing in the schema notices.
Key questions.
spatie/laravel-medialibrary with a Nova field, outl1ne/nova-media-hub, or Nova's native File field in multiple mode?Stack fit. Green light only if the application is Laravel + Nova and the existing Nova version still accepts the 2019 field API. If the admin surface is Filament, Inertia, or bespoke, there is no fit — do not contort the stack around a 14-star field. If the requirement is genuinely "a handful of images on one model," Nova's native File field configured for multiple files is the lower-risk default and removes the dependency entirely.
Migration path. Treat this as a schema decision before a package decision. Prefer an explicit json column with an Eloquent array/json cast over an untyped serialized string, and prefer a media table over both. If the package is adopted, fork it into a private VCS namespace, tighten composer.json constraints, add return types, and wrap the resolve/hydrate/fill paths in PHPUnit tests. Plan a later migration to a real media model rather than treating the array column as permanent.
Compatibility. Verify concretely: composer.json PHP and illuminate/* constraints, Nova asset registration mechanism, and every Nova API call the field makes. Expect the field's Vue component to need rebuilding against the current Nova toolchain, and expect withMeta payload changes to break the front end independently of the PHP side.
Sequencing. (1) Timeboxed spike in a throwaway branch against the exact target Nova version. (2) Exercise the full lifecycle: upload, reorder, replace, delete record, delete file, change disk. (3) Security review of upload validation and path handling. (4) Decide fork vs. build-in-house vs. maintained alternative. (5) Only then promote to a shared branch, with tests and a pinned dependency.
Maintenance. We own this on day one. Budget a fork, a pinned dependency, and a recurring upgrade tax every time Laravel or Nova moves. No upstream releases since January 2019 means no patches, security or otherwise.
Support. Effectively zero community: 14 stars, README-only documentation, no issue triage. Knowledge will live with whoever performs the integration — a single point of failure if that engineer leaves. Any incident becomes internal archaeology.
Scaling. Adequate for tens to low hundreds of records in a small internal tool. Poor beyond that: orphaned files accumulate with no lifecycle cleanup, there is no image transform or CDN pipeline, large arrays bloat rows and increase read amplification, and filtering or reporting on image attributes requires decoding JSON in application code.
Failure modes. Dangling paths after file deletion; broken references after a storage disk or bucket migration because stored paths are not portable; malformed or truncated JSON crashing field render; Nova upgrade silently breaking asset registration; missing or weak upload validation enabling malicious MIME types or path injection; and last-write-wins overwrites when two editors modify the same record's array concurrently.
Ramp-up. Low to learn the field API, high to trust it. Estimate one to two days for the compatibility spike and one to two weeks to fork, harden, and test it properly. Recommendation: do not adopt unless a hard constraint — a legacy Nova install that cannot move, or a throwaway internal tool — forces it. Otherwise use Nova's native multi-file field for the simple case, or a maintained media package for the real one.
How can I help you explore Laravel packages today?