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

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # 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
+
+- [#2644](https://github.com/graphcommerce-org/graphcommerce/pull/2644) [`c4ca56a`](https://github.com/graphcommerce-org/graphcommerce/commit/c4ca56a08915d918f78339ecddcc418dfc26857d) - Fix GraphQL multipart uploads (`Upload` scalar) through the Mesh. Next.js' pages-router bodyParser decodes multipart request bodies as UTF-8 text before Yoga can parse them, silently corrupting binary upload bytes (invalid UTF-8 sequences become replacement characters and the part's mime type is lost). The `/api/graphql` route now sets `bodyParser: false` so Yoga receives the raw stream, and `createServer` throws a descriptive error when it receives a multipart request whose body was already consumed by the bodyParser. ([@paales](https://github.com/paales))
+
 ## 10.1.0-canary.31
 
 ## 10.1.0-canary.30

package/api/createEnvelop.ts

@@ -8,6 +8,15 @@ export const createServer = async (endpoint: string) => {
 
   const handler = createBuiltMeshHTTPHandler()
   return async (req: NextApiRequest, res: NextApiResponse) => {
+    if (req.headers['content-type']?.startsWith('multipart/form-data') && req.body !== undefined) {
+      // Next's pages-router bodyParser has already consumed the request stream and decoded it as
+      // UTF-8 text, which corrupts binary `Upload` bytes (the multipart boundary survives, so the
+      // request would otherwise be forwarded with silently mangled file contents).
+      throw Error(
+        "Multipart GraphQL requests require Next.js' bodyParser to be disabled. Add `bodyParser: false` to the route config in pages/api/graphql.ts: export const config = { api: { externalResolver: true, bodyParser: false } }",
+      )
+    }
+
     res.setHeader('Access-Control-Allow-Origin', req.headers.origin || '*')
     const requestedHeaders = req.headers['access-control-request-headers']
     if (requestedHeaders) {

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.31",
+  "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.31",
-    "@graphcommerce/prettier-config-pwa": "^10.1.0-canary.31",
-    "@graphcommerce/typescript-config-pwa": "^10.1.0-canary.31",
+    "@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": "*"
   },