feat(rw-uploads): Create uploads package with prisma extension

[dac09]

Small(er) PR with just the Prisma extension, and new uploads package.

This PR does the following:

• creates new @redwoodjs/uploads package. This is configured to be a dual esm/cjs package.
• exports prisma extension with legacy support e.g.

  import {
    createUploadsExtension,
    UploadsConfig,
  } from '@redwoodjs/uploads/prisma'
  

• scaffolds unit test structure for prisma extension
• the prisma extension does the following:
  a) If a base64 or TUS upload URL string is sent, it saves or moves it to a file
  b) Adds a withDataUri result extension, to make it easier to deal with files e.g.

Outstanding:

• Types not coming through correctly on results extension. This is probably package setup
• Add more unit tests

[cannikin]

There's the third case of just a regular form submit, what's the behavior like in that case? You could simulate an RSC Server Action by having a form submit to an API function (like api/src/functions/SubmitHandler.js). Have the file field in that form literally just be a plain <input type="field"> or the built-in <FileField> form helper. In the function you'd have to pull the data out of event somehow...does a Web Request just contain a string body or does it get parsed for you? But however it works, call db.contact.create() with the resulting data and it should save the upload just like the other two.

[dac09]

Lambda functions don’t play well with multipart form data - this is why I don’t want to assume anything about the delivery mechanism with form submits yet! You would probably receive the data, save it to a file and pass the path to prisma (the same way I was doing form posts, but all within the receiving function)

[cannikin]

There's a lot of file-system specific stuff in the Prisma extension...I was imagining these functions are called on an instance of an adapter, and it's the adapter that actually puts the file where it needs to go. So you can hot-swap them and have a whole new storage backend.

I was imagining the adapter exposes probably 3 total functions:

• fetch
• store
• delete

So the Prisma extension doesn't know/care about where the file is going, it just uses the appropriate adapter:

async create({ query, args }) {
  const uploadArgs = await adapter.store(
    uploadFields,
    args,
  )

  return query(uploadArgs)
},

The modelConfig and tusConfig could be sent into the adapter when it gets initialized and then it can be used internally, no need to send it in again every time. The adapter is setup something like:

# api/src/lib/uploads.js
export const adapter = new FileStore({ modelConfig, tusConfig })

And then maybe that adapter is given to the Prisma extension when you $extends it? I can't remember the exact syntax but something like:

import { adapter } from 'src/lib/uploads'

// other db setup stuff...

export const db = ogDb.$extends(createUploadsExtension(adapter))

Let's pair soon and discuss!

[dac09]

Closing this, will create another PR. Design has changed quite a lot!