fix: handle arrays properly in FormData

[omarmciver]

Description

This PR fixes an issue with FormData handling when arrays are involved, particularly for multi-file uploads.

The Problem

When an API endpoint accepts an array of files (or any array in FormData), the current implementation incorrectly converts the entire array to a string representation instead of properly appending each item individually to the FormData object.

Example scenario:

// API expects multiple file attachments
const files = [file1, file2, file3];
api.uploadMultiple({ files });

// Current behavior: FormData contains
// "files" => "[object File],[object File],[object File]" ❌

// Expected behavior: FormData should contain
// "files" => file1
// "files" => file2  
// "files" => file3 ✅

The Solution

This fix modifies the FormData content formatter to:

1. Detect when a property value is an array
2. Iterate through each item in the array
3. Properly append each item individually to FormData
4. Preserve the correct handling of Blob/File types vs other data types

Changes Made

• Updated templates/base/http-clients/fetch-http-client.ejs to handle arrays in FormData
• Added test fixture formdata-arrays.json to verify the fix
• All existing tests pass with updated snapshots

Use Cases

This fix is essential for:

• Multi-file upload endpoints
• Batch document processing APIs
• Any FormData field that accepts multiple values
• Services handling attachments (e.g., agreement management systems)

Testing

• ✅ All existing tests pass
• ✅ Snapshots updated to reflect the new array handling
• ✅ Added test fixture for multi-file upload scenario

Backwards Compatibility

This change is fully backwards compatible:

• Single values continue to work as before
• Arrays are now handled correctly instead of being stringified
• No breaking changes to the API

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 3d33625f568f6fe313be9a3852453663b5cb4de4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[omarmciver]

@lc-soft Thank you for the excellent code review! I've implemented both of your suggestions:

1. ✅ Simplified Blob check: Removed redundant File instanceof check since File extends Blob
2. ✅ Fixed string handling: Added explicit string type check to prevent double-stringification

The updated code now correctly handles:

• Blob/File types: Passed directly to FormData ✅
• Strings: Passed directly without JSON.stringify ✅
• Objects/Arrays: JSON.stringify applied ✅
• Numbers/Booleans: JSON.stringify applied ✅

Most importantly: The original bug fix (handling arrays in FormData for multi-file uploads) still works perfectly! 🎉

Changes pushed in commit b9da1cd

[omarmciver]

✅ Tests fixed!

Updated all test snapshots to reflect the refactored FormData handling. All 133 tests now passing.

Changes in commit 6e854b8:

• 28 snapshot files updated
• 114 snapshots refreshed
• All tests green ✅

[Saeid-Za]

Thank you for the PR. I'm curious, is there a standard way to map a nested object with files to a form data recursively? so that we could extend it to support nested objects or provide a way for users to define the mapper function.

[smorimoto]

@codex review

[chatgpt-codex-connector[bot]]

Codex Review: Didn't find any major issues. Another round soon, please!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[smorimoto]

bugbot run

[nicotu01]

Hi @omarmciver , I'm interested by this bug fix. Is this PR still ongoing?

[omarmciver]

@nicotu01

I'm stepping back from this PR. The core fix for FormData array handling works correctly and was approved by @lc-soft after addressing their feedback.

Since then, this PR has become a target for multiple AI code review bots (Cursor Bugbot, GitHub Copilot) that are suggesting changes that would actually reintroduce the original bug.

Specifically, Copilot's suggestion to use template literal coercion (${formItem}) instead of JSON.stringify() for objects would cause nested objects to serialize as [object Object] — which is exactly the kind of broken behavior we're trying to avoid.

I don't have the bandwidth to continuously defend a working fix against AI reviewers that don't understand the full context of the problem.

For anyone else hitting this issue: the fix is straightforward. You can grab it from my branch or just override the fetch-http-client.ejs template in your project with proper array iteration in the FormData formatter.