Add `createBlob` util function in common

[mtuchi]

Problem

encodeFormBody can handle Blob and File values in json mode, but there's no ergonomic way for a caller to submit raw binary data (e.g. a Buffer) with a specific MIME type and filename. Without this, submitting files/binaries requires the caller to manually construct a Blob before passing it in.

Proposed Solution

Add a createBlob(data, type, filename) helper that returns a wrapped class instance (BlobEntry). encodeFormBody recognises BlobEntry values in json mode and converts them to a typed, named Blob before appending to the FormData.

Usage:

  import { createBlob, encodeFormBody } from '@openfn/language-common/util';
                                                                                                                                                
  const form = encodeFormBody({
    name: 'upload',                                                                                                                             
    file: createBlob(buffer, 'image/jpeg', 'photo.jpg'),                                                                                        
  });                                                                                                                                         
                              

Implementation

• Add unexported BlobEntry class to packages/common/src/util/http.js
• Add exported createBlob(data, type, filename) factory
• Update encodeFormBody json mode to detect BlobEntry via instanceof and wrap in Blob with type + filename
• Add unit tests covering the factory output and encoder integration

Files:

• packages/common/src/util/http.js
• packages/common/test/util/http.test.js

[josephjclark]

Just thinking aloud, but would it also make sense - or maybe more sense? - to:
a) expose a createFormData() function, to get raw undici FormData object
b) expose a simple createBlob() function, to get a raw nodejs blob

This would allow users to have full control of building their own formdata object in a more normal sort of way. It would also mean the common request helper could just accept a FormData instance without needing a content type (we might need to detect it and set the headers, not sure)

Both issues could be worked around by exposing undici Form and native Blob in the runtime. Not that happy about exposing library code though - should really just be node globals in the runtime.

[josephjclark]

I suppose common could export a FormData global, available to all job code. That would be fine.

[mtuchi]

Had a sync with Joe,
We agreed on the approach for handling FormData for adaptors that need to work with files or binary data:

• FormData Implementation: We will expose undici FormData global at the job level within common. This allows job code to create a new FormData() object and attach forms and blobs directly, specifically for use cases that involve files or binary data. If an adaptor needs to pass the FormData object, its exports must be updated.