@emmatown since we are here again refactoring it, can you help us with something to create custom storage easily? Like if I want to have Azure storage or Google cloud storage?

It would be good to be able to register custom storage and use it with the file/image field.

I have been using my own field for s3 which generates 3-4 copy of image processed with sharp to help reduce any compute cost in dynamic image optimization. - https://github.com/keystonejs-contrib/k6-contrib/tree/main/packages/fields-s3images

do you see a way to do that with this new refactoring?

It would be good to be able to register custom storage and use it with the file/image field.

This PR is doing exactly that

This pull request will additionally add an example for doing a few of the common ones (at least S3, maybe Azure and or GCS)

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

View full report↗︎

It would be good to be able to register custom storage and use it with the file/image field.

This PR is doing exactly that

I see we still keeping multiple fields in database? (_id, .filename, .extension) etc? As there is no filtering applicable to this field, I am thinking we should convert into JSON field internally. This will help adding more data to the field I can add multiple image size in my custom implementation.

At least add a meta field <field>.meta so that custom implementation can have flexibility.

Interesting idea @gautamsi, but as a breaking change that would be a pretty significant hurdle for many developers wanting to migrate compared to this thus far. Maybe we can posit that as an idea in a different pull request and think about how to help developers migrate?

@dcousens I understand that migrating such data structure to json will be cumbersome. Adding _meta field should help with custom implementation

How are you thinking the meta field would work for now?

I can save additional information specific to provider or save more information like image metadata (orientation, geocoding etc.) and use that in my frontend/workflow.

OK, so you want a meta JSON sub-field on file and image that you could interact with arbitrarily in resolveInput hooks?

These are all great changes! Also the "node_modules black hole" gets smaller by removing the direct dependency on aws-sdk!

Since we're already making breaking changes, could we also address the update problem with these fields? This issue is related to #9419, but the problem is more general.

Currently, the order of operations is:

update → beforeOperation hook (delete old) → transformName → put (upload) → update DB

However, uploading is a fragile operation and can fail, leaving us with nothing.
A simple solution would be to change the order to:

update → transformName → put (upload) → update DB → afterOperation hook (delete old)

With this approach, we would need to enforce the limitation that transformName must produce a unique string. This is already the case unless the user provides a custom implementation.

If this limitation is not practical, the only alternative I see, would be to change the interface. For example, we could introduce a differentiating argument for transformName and/or storage.delete like version, operationType or some unique identifier.

OK, so you want a meta JSON sub-field on file and image that you could interact with arbitrarily in resolveInput hooks?

exactly.

Thank you @emmatown ❤️ Simple and elegant solution.

@gautamsi I don't think I have an answer to your meta JSON sub-field issue as part of this pull request

would you accept a pull request?