GraphQL doesn't work properly with turbopack

[chrisvanmook]

Link to reproduction

No response

Payload Version

beta.36

Node Version

v20.11.1

Next.js Version

15.0.0-rc.0

Describe the Bug

When running NextJS like it's configured in this demo repo, and run it with turbopack by adding turbo to the dev script in package.json, I get a conflict error when making a request to GraphQL. Note that without the --turbo flag it works. I initially came across this error by using Next 14 with React 18, because I wanted to integrate this in my current project, so the issue also applies to these versions. It applies to both mongodb and postgres adapters.

Reproduction Steps

1. Clone https://github.com/payloadcms/payload-3.0-demo
2. Copy .env.example to .env
3. Run start-database.sh
4. Change the dev command in package.json to "cross-env NODE_OPTIONS=--no-deprecation next dev --turbo"
5. Open http://localhost:3000/api/graphql-playground
6. Execute the following query:

query GetTopics {
  Users(page: 1) {
    docs {
      email
    }
  }
}

7. Receive the error:

"Cannot use GraphQLScalarType \"Int\" from another module or realm.\n\nEnsure that there is only one instance of \"graphql\" in the node_modules\ndirectory. If different versions of \"graphql\" are the dependencies of other\nrelied on modules, use \"resolutions\" to ensure only one version is installed.\n\nhttps://yarnpkg.com/en/docs/selective-version-resolutions\n\nDuplicate \"graphql\" modules cannot be used at the same time since different\nversions may have different capabilities and behavior. The data from one\nversion used in the function from another could produce confusing and\nspurious results."

where I would expect to receive a Forbidden 403 gql error. I've also tried this with custom collections where a set the access:read to open, same result

8. When I omit the parameters (page: 1), It works

query GetTopics {
  Users {
  	docs {
      email
    }
  }
}

Adapters and Plugins

db-mongodb, db-postgres

[megetron3]

happens here as well. same versions. i dont use --turbo. just "next dev" but still se the turbo is on so not sure how to disable it:

> next dev

   ▲ Next.js 14.0.0
   - Local:        http://localhost:3000
   - Environments: .env
   - Experiments (use at your own risk):
     · turbo

Cannot use GraphQLScalarType "String" from another module or realm.\n\nEnsure that there is only one instance of "graphql" in the node_modules\ndirectory. If different versions of "graphql" are the dependencies of other\nrelied on modules, use "resolutions" to ensure only one version is installed.\n\nhttps://yarnpkg.com/en/docs/selective-version-resolutions\n\nDuplicate "graphql" modules cannot be used at the same time since different\nversions may have different capabilities and behavior. The data from one\nversion used in the function from another could produce confusing and\nspurious results.

{
  "name": "commerce",
  "version": "1.0.0",
  "private": true,
  "packageManager": "[email protected]",
  "engines": {
    "node": ">=18",
    "pnpm": ">=7"
  },
  "scripts": {
    "dev": "NEXT_TELEMETRY_DISABLED=1 next dev",
    "build": "NEXT_TELEMETRY_DISABLED=1 next build",
    "start": "NEXT_TELEMETRY_DISABLED=1 next start",
    "lint": "NEXT_TELEMETRY_DISABLED=1 next lint",
    "lint-staged": "lint-staged",
    "prettier": "prettier --write --ignore-unknown .",
    "prettier:check": "prettier --check --ignore-unknown .",
    "test": "pnpm lint && pnpm prettier:check",
    "generate:types": "payload generate:types"
  },
  "git": {
    "pre-commit": "lint-staged"
  },
  "lint-staged": {
    "*": "prettier --write --ignore-unknown"
  },
  "dependencies": {
    "@ark-ui/react": "^1.1.0",
    "@headlessui/react": "^1.7.17",
    "@heroicons/react": "^2.0.18",
    "@orama/orama": "^1.2.9",
    "@oramacloud/client": "1.0.0-beta.21",
    "payload": "3.0.0-beta.56",
    
    "sharp": "0.32.6",
    "@payloadcms/next": "3.0.0-beta.56",
    "@payloadcms/db-mongodb": "3.0.0-beta.56",
    "@payloadcms/richtext-lexical": "3.0.0-beta.56",
    
    "graphql": "16.9.0",
    "clsx": "^2.0.0",
    "geist": "^1.0.0",
    "lodash": "^4.17.21",
    "next": "14.0.0",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "swiper": "^11.1.1"
  },
  "devDependencies": {
    "@tailwindcss/container-queries": "^0.1.1",
    "@tailwindcss/typography": "^0.5.10",
    "@types/lodash": "^4.14.195",
    "@types/node": "20.8.9",
    "@types/react": "18.2.33",
    "@types/react-dom": "18.2.14",
    "@vercel/git-hooks": "^1.0.0",
    "autoprefixer": "^10.4.16",
    "eslint": "^8.52.0",
    "eslint-config-next": "^14.0.0",
    "eslint-config-prettier": "^9.0.0",
    "eslint-plugin-unicorn": "^48.0.1",
    "lint-staged": "^15.0.2",
    "postcss": "^8.4.31",
    "prettier": "3.0.3",
    "prettier-plugin-tailwindcss": "^0.5.6",
    "tailwindcss": "^3.3.5",
    "typescript": "^5.3.3"
  },
  "resolutions": {
    "graphql": "16.9.0"
  }

}

[SimonVreman]

This is also present for me, it appears that every request using variables fails. Using dependencies:

{
  "payload": "3.0.0-beta.60",
  "next": "15.0.0-canary.64",
  "graphql": "^16.9.0"
}

Setting resolutions/overrides does not solve the issue. Switching back to webpack does fix it of course.

[JarrodMFlesch]

@AlessioGr can you check to see if this is still not working on our latest release?

[reiv]

Still getting this on 3.0.0-beta.116 with a similar query (using limit on any collection), same situation with pnpm.resolutions.

@SimonVreman how did you get it to work with webpack? I tried config.experimental.turbo = undefined in next.config.mjs to undo withPayload(...) - turbo isn't listed anymore during startup so I assume it now uses Webpack, but the result is the same.

[github-actions[bot]]

This issue has been marked as stale due to lack of activity.

To keep this issue open, please indicate that it is still relevant in a comment below.

[github-actions[bot]]

This issue was automatically closed due to lack of activity.

[SimonVreman]

@reiv Apologies for the late reply.

Just turning off turbopack resolved the issue. Your error is one I've seen in other cases too, I think it pops up on other internal failures too. From memory, using a where query across a join field also causes this. So it is (was) likely something else.

Personally, I've switched away from GraphQL entirely. Payload's support for it is lacking big time, and the numerous issues I've had have driven me to use only the Local and REST APIs.