- What does jameslkingsley/nova-media-library actually do?
- It is a Laravel Nova field that binds to a Spatie Media Library collection on an Eloquent model, letting you upload, preview, and delete attached media from inside the Nova admin panel. It is a thin adapter between Nova and spatie/laravel-medialibrary rather than a media library of its own. All storage, conversions, and file handling are delegated to the underlying Media Library package.
- Is jameslkingsley/nova-media-library still maintained?
- No. The repository is archived and the last release was in January 2019, with around 38 GitHub stars. There are no security patches, no compatibility updates, and no upstream support channel. Treat it as a reference implementation, not a live dependency.
- Does it work with Laravel 8+, PHP 8+, or Nova 3 and 4?
- It does not work as-is on modern stacks. Its Composer constraints and Nova field API target the Laravel 5.x, Nova 1/2 era, and Media Library around version 7.x. Nova's proprietary field API and frontend assets are version-coupled, so even forcing the install typically leaves you with a broken field. You would need a fork upgraded to the current Nova field API and Media Library major version.
- How do I install it in a legacy Nova 1/2 application?
- Run composer require jameslkingsley/nova-media-library on a stack that already has a licensed Nova 1/2 install and spatie/laravel-medialibrary configured. Your model must implement the HasMedia contract and register the media collection, then you add the field to the Nova resource and point it at the collection name. Confirm the filesystem disk and image driver settings before testing uploads, since the field relies entirely on Media Library configuration.
- Can it manage multiple media collections on the same model?
- Yes, the field binds to a single named collection per field instance, so you add one field per collection in the Nova resource. The README-style usage supports things like a single-file avatar collection alongside a multi-file gallery collection. Each field renders and updates only its own collection, so attach and detach actions are scoped correctly.
- Does the field support cropping, conversions, reordering, or responsive images?
- No. The field covers basic upload, preview, and delete operations against a collection; cropping and reordering are not part of its UI. Conversions, responsive images, and other transformations are handled by Spatie Media Library itself, not by this Nova field. If you need richer admin controls, plan to build them into your fork or replacement field.
- Can I use this package in production or should I fork it?
- Do not ship the archived package directly to production. Unmaintained Composer dependencies mean no security patches, stale JavaScript transitive packages, and no path to a fix when Nova or Media Library changes. If you need this functionality, fork it under your own namespace, upgrade it, and assign an internal owner with a support window.
- How would I fork and modernize it for current Nova and Media Library versions?
- Copy the field class and Vue component, then update them to the current Nova field API and asset build tooling. Align the attach, detach, and conversion logic with the Media Library API version you run, and verify the database schema assumptions around the media table. Pin Laravel, PHP, Nova, and Media Library versions together and add tests for attach, detach, delete, and conversion behaviour before relying on it.
- What are the maintained alternatives to this Nova media field?
- Building a small custom Nova field is often the cheapest long-term option, since the scope of upload, list, and delete is modest. Community packages such as ebess/advanced-nova-media-library are commonly used for richer Nova media UIs, though you should verify their current maintenance status and Nova version support yourself. Either way, confirm the package is actively released against the Nova and Media Library versions you run.
- What are the main risks of depending on an archived Composer package like this?
- The risks are dependency obsolescence, no security patching, no upstream support, and fragile frontend assets built with old JavaScript tooling that may pull in vulnerable transitive packages. Nova's proprietary licensing also makes sandbox verification awkward, and the low star count means little community troubleshooting evidence. Review any abandoned package through your security process and get sign-off before copying code into an internal fork.