Duplicate "graphql" modules cannot be used at the same time since different versions...

[Stupidism]

Bug Report

I'm using payload in a nx monorepo, I met this error after upgrading payload to the newest version. And I found it was upgraded in 1.4.0.

nx run seo-payload:serve

 >  NX   USING REMOTE CACHE


> nx run seo-payload:serve

chunk (runtime: config) config.js (config) 283 KiB [entry] [rendered]
chunk (runtime: main) main.js (main) 11.7 KiB [entry] [rendered]
webpack compiled successfully (1799b20c209ec786)
Debugger listening on ws://localhost:9229/20d445a8-52d6-422f-9523-b6edace32404
Debugger listening on ws://localhost:9229/20d445a8-52d6-422f-9523-b6edace32404
For help, see: https://nodejs.org/en/docs/inspector
body-parser deprecated undefined extended: provide extended option dist/apps/seo-payload/main.js:388:27
[02:01:19] INFO (payload): Starting Payload...

/Users/stupidism/Documents/jerry-serverless/node_modules/payload/node_modules/graphql/jsutils/instanceOf.js:44
            throw new Error(`Cannot use ${className} "${stringifiedValue}" from another module or realm.
                  ^
Error: Cannot use GraphQLScalarType "DateTime" from another module or realm.

Ensure that there is only one instance of "graphql" in the node_modules
directory. If different versions of "graphql" are the dependencies of other
relied on modules, use "resolutions" to ensure only one version is installed.

https://yarnpkg.com/en/docs/selective-version-resolutions

Duplicate "graphql" modules cannot be used at the same time since different
versions may have different capabilities and behavior. The data from one
version used in the function from another could produce confusing and
spurious results.
    at instanceOf (/Users/stupidism/Documents/jerry-serverless/node_modules/payload/node_modules/graphql/jsutils/instanceOf.js:44:19)
    at isScalarType (/Users/stupidism/Documents/jerry-serverless/node_modules/payload/node_modules/graphql/type/definition.js:117:37)
    at isType (/Users/stupidism/Documents/jerry-serverless/node_modules/payload/node_modules/graphql/type/definition.js:92:5)
    at isNullableType (/Users/stupidism/Documents/jerry-serverless/node_modules/payload/node_modules/graphql/type/definition.js:440:10)
    at new GraphQLNonNull (/Users/stupidism/Documents/jerry-serverless/node_modules/payload/node_modules/graphql/type/definition.js:394:5)
    at /Users/stupidism/Documents/jerry-serverless/node_modules/payload/dist/collections/graphql/init.js:101:23
    at Array.forEach (<anonymous>)
    at initCollectionsGraphQL (/Users/stupidism/Documents/jerry-serverless/node_modules/payload/dist/collections/graphql/init.js:60:38)
    at registerSchema (/Users/stupidism/Documents/jerry-serverless/node_modules/payload/dist/graphql/registerSchema.js:58:24)
    at init (/Users/stupidism/Documents/jerry-serverless/node_modules/payload/dist/init.js:79:38)
^C%

Steps to Reproduce

Other Details

[jmikrut]

Hey @Stupidism — this is actually not a bug with Payload and more of a restriction with GraphQL itself.

I assume that this is related to a custom GraphQL mutation or query that you have written. If you import types directly from a GraphQL dependency, this can arise.

Notice in our docs how we provide GraphQL as an argument to custom queries and mutations - this is why. This is literally the same exact GraphQL dependency that Payload uses, so if you use types coming from that GraphQL argument, you will not see this issue.

Otherwise, if you follow the suggested GraphQL solution in the error message, and specify a resolutions to GraphQL in your package.json, that should allow you to dodge this issue as well.

I will convert this to a discussion and we can keep convo going there. But this is expected and there is little that Payload can do to rectify this, unfortunately. Got me a few times myself when having multiple copies / versions of GraphQL installed.