Error: Cannot use GraphQLSchema "[object GraphQLSchema]" from another module or realm.

[nizulzaim]

I am using type-graphql and apollo-server-express together. There is no issue for me when running in a development environment. However, once I want to build the apps for production deployment using webpack, there is an error show:

(node:16840) UnhandledPromiseRejectionWarning: Error: Error: Cannot use GraphQLSchema "[object GraphQLSchema]" 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 behaviour. The data from one
version used in the function from another could produce confusing and
spurious results.

I have check type-graphql version and it is using graphql@15.3.0. However, the different case with apollo-server-express that still using the libraries that not support version ^15.0.0 such as graphql-subscriptions and also graphql-upload.

What is the best solution to fix this? Do we need to wait for dependencies update release?

[Alec2435]

While the actual fix should be made by the apollo team, I found that for now the following fix seems to work. You'll need to use the Webpack resolve config and add the following lines to that section of your Webpack config:

alias: {
            graphql$: path.resolve(__dirname, './node_modules/graphql/index.js'),
        },

Make sure to replace ./node_modules/ with whatever the relative path is for node_modules from your Webpack config

[nizulzaim]

Wow! Thank you very much. It worked. But hope it will break anything because migrating from graphql v14 to v15 might impact from graphql server. I already moved to express-graphql because of this.

Thanks again!

[thekevinbrown]

I'd recommend that this issue is reopened, we have a workaround but a fix would be better.

[thekevinbrown]

For the record it's also possible to get this error if you're using serverless-offline and aren't using useChildProcesses: true as they use worker threads by default, which cause this error: https://github.com/graphql/graphql-js/issues/2801

[omar-dulaimi]

@thekevinbrown I'm facing this issue right now. It's really not easy to fix it with serverless-offline. I tried a lot of workarounds.

[glasser]

We have since (as far as I know) fixed the peer dep issue, so there shouldn't be peer dep reasons for multiple graphql copies to exist.

Webpack does appear to sometimes make multiple copies of graphql anyway, but it's unclear that this is anything apollo-server can fix. See eg #4983.

[thekevinbrown]

@omar-dulaimi we're using serverless offline as well. Our setup is:

• Ensure you're using --skipCacheInvalidation with serverless offline, which is now the default but if you're on an older version it won't be.
• Don't use child processes
• Provide some kind of middleware which ensures only one request at a time gets serviced to mimic Lambda's actual behaviour on AWS. We're using this: https://www.npmjs.com/package/async-mutex and created an apollo plugin in dev only that mutexes the requests.
• Profit.

[bzuker]

For people still struggling with this, I managed to work around this issue thanks to @Alec2435's comment + adding a key to externals config in webpack:

...
externals: [
      nodeExternals(),
      nodeExternals({
        modulesDir: path.resolve(__dirname, "../../../node_modules"),
      }),
],
alias: {
   graphql$: path.resolve(__dirname, './node_modules/graphql/index.js'),
}
...

This worked for my monorepo structure with yarn workspaces

[botre]

I have also encountered this issue in my Apollo Webpack Typescript project, I have discovered the following:

The extensions order inside the Webpack configuration seems to have a major influence.

This will produce the error:

extensions: [".js", ".mjs", ".ts"],

This will not produce the error:

extensions: [".ts", ".mjs", ".js"]

[edoardo-bluframe]

Hey @botre actually nailed it

If I put .mjs before .js everything works

No need for alias - which also worked, but I believe this solution is more elegant

Can someone shed light on why the order of extensions matters and what we can do to fix this issue for good?

[thekevinbrown]

Note for 2021 with Serverless Offline, you now need:

module.exports = {
    service: 'just-for-local-development',
    plugins: ['serverless-offline'],
    custom: {
        'serverless-offline': {
            allowCache: true,
        },
    },
};

in your severless.js / serverless.yaml file.

[BrutalSimplicity]

Without the .mjs extension nothing worked.

After reading all the details of the graphqljs documentation I found this: https://github.com/graphql/graphql-js#using-in-a-browser

Building a project using GraphQL.js with webpack or rollup should just work and only include the portions of the library you use. This works because GraphQL.js is distributed with both CommonJS (require()) and ESModule (import) files. Ensure that any custom build configurations look for .mjs files!

Strange thing is I have another large monorepo project that doesn't have that extension and is using 15.3.0, but it doesn't run into this issue.

A bit baffled tbh 🤔

[yagoml]

Note for 2021 with Serverless Offline, you now need:

module.exports = {
  service: 'just-for-local-development',
  plugins: ['serverless-offline'],
  custom: {
      'serverless-offline': {
          allowCache: true,
      },
  },
};

in your severless.js / serverless.yaml file.

Thanks @thekevinbrown , after days losing hairs, was the only thing that worked here...