@frontera-sdk/core 1.50.54 → 1.50.56

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@frontera-sdk/core",
-  "version": "1.50.54",
+  "version": "1.50.56",
   "description": "Frontera app runtime: the platform bridge client, app bootstrap and typed platform client.",
   "keywords": [
     "frontera",

package/src/transport.ts

@@ -175,12 +175,26 @@ export async function httpRequest<T>(
     ...authHeaders(config),
     accept: 'application/json',
   }
-  if (options.body !== undefined) headers['content-type'] = 'application/json'
+  // FormData carries its own multipart content type WITH a boundary, which only
+  // it can generate — setting one here, or stringifying it, produces a body the
+  // server cannot parse. `httpRequestRaw` has always known this; `httpRequest`
+  // did not, so an upload through the ergonomic path serialised to `{}` and the
+  // server saw no file at all.
+  const isFormData = typeof FormData !== 'undefined' && options.body instanceof FormData
+  if (options.body !== undefined && !isFormData) headers['content-type'] = 'application/json'
 
   const response = await fetchImpl(buildUrl(config, path, options.query), {
     method: options.method ?? 'GET',
     headers,
-    body: options.body === undefined ? undefined : JSON.stringify(options.body),
+    body:
+      options.body === undefined
+        ? undefined
+        : isFormData
+          ? // `FormData`, not `BodyInit`: the guard above narrowed it to exactly
+            // that, and `BodyInit` is a DOM-lib global the CLI's tsconfig does
+            // not load — naming it here fails that package's typecheck.
+            (options.body as FormData)
+          : JSON.stringify(options.body),
     signal: options.signal,
   })