@graphcommerce/graphql-mesh 10.1.0-canary.32 → 10.1.0-canary.34

package/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Change Log
 
+## 10.1.0-canary.34
+
+## 10.1.0-canary.33
+
+### Patch Changes
+
+- [#2648](https://github.com/graphcommerce-org/graphcommerce/pull/2648) [`24541b8`](https://github.com/graphcommerce-org/graphcommerce/commit/24541b8d3d7f5de80ebc7b9a03d439b4347eb9e6) - Fix multipart file uploads through the mesh returning "Unable to parse the request." in `next dev` (turbopack). `customFetch` used `globalThis.fetch` (undici) inside Next, while `@graphql-tools/executor-http` builds upload bodies with `FormData` from `@whatwg-node/fetch`. In `next dev`, `@whatwg-node/fetch` is evaluated while `next.config.ts` loads — before any `__NEXT` global exists — so its Next.js detection fails and it exports its ponyfills. Undici doesn't recognize the ponyfill `FormData` and stringified the request body to the literal `[object Object]`. `customFetch` now always uses the fetch exported by `@whatwg-node/fetch`, which is `globalThis.fetch` whenever the native path is active and the matching ponyfill fetch otherwise, so fetch and `FormData` always come from the same implementation family. ([@paales](https://github.com/paales))
+
 ## 10.1.0-canary.32
 
 ### Patch Changes

package/customFetch.ts

@@ -2,8 +2,19 @@ import fetchRetry from 'fetch-retry'
 import type { RequestInitWithRetry } from 'fetch-retry'
 
 const fetcher = fetchRetry(
-  // eslint-disable-next-line @typescript-eslint/no-unsafe-argument, no-underscore-dangle, @typescript-eslint/no-var-requires
-  process.env.__NEXT_PROCESSED_ENV ? globalThis.fetch : require('@whatwg-node/fetch').fetch,
+  /**
+   * Always use the fetch that `@whatwg-node/fetch` exports, never `globalThis.fetch` directly. When
+   * `@whatwg-node/fetch` detects a Next.js runtime it re-exports the native fetch primitives (so
+   * inside Next this IS `globalThis.fetch`/undici, keeping SSL handshakes alive), but when that
+   * detection fails — `next dev` (turbopack) evaluates it while loading `next.config.ts` (via
+   * `@graphql-codegen/cli`), before any `__NEXT` global exists — it exports its ponyfills instead.
+   * In that case `@graphql-tools/executor-http` builds multipart upload bodies with the ponyfill
+   * `FormData`, which undici doesn't recognize and stringifies to the literal `[object Object]`
+   * (Magento: "Unable to parse the request."). The fetch implementation must therefore always come
+   * from the same family as the `FormData`/`File` classes executor-http uses.
+   */
+  // eslint-disable-next-line @typescript-eslint/no-unsafe-argument, @typescript-eslint/no-var-requires
+  require('@whatwg-node/fetch').fetch,
 )
 
 /**

package/package.json

@@ -2,7 +2,7 @@
   "name": "@graphcommerce/graphql-mesh",
   "homepage": "https://www.graphcommerce.org/",
   "repository": "github:graphcommerce-org/graphcommerce",
-  "version": "10.1.0-canary.32",
+  "version": "10.1.0-canary.34",
   "dependencies": {
     "@whatwg-node/fetch": "^0.10.13",
     "fetch-retry": "^5.0.6",
@@ -20,9 +20,9 @@
   },
   "peerDependencies": {
     "@apollo/client": "*",
-    "@graphcommerce/eslint-config-pwa": "^10.1.0-canary.32",
-    "@graphcommerce/prettier-config-pwa": "^10.1.0-canary.32",
-    "@graphcommerce/typescript-config-pwa": "^10.1.0-canary.32",
+    "@graphcommerce/eslint-config-pwa": "^10.1.0-canary.34",
+    "@graphcommerce/prettier-config-pwa": "^10.1.0-canary.34",
+    "@graphcommerce/typescript-config-pwa": "^10.1.0-canary.34",
     "@graphql-mesh/runtime": "*",
     "@graphql-mesh/types": "*"
   },