graphql-js: Getting multiple instances of graphql error despite only having a single version

@jkepps It’s been a while since I’ve thought about this but here are a few additional bits of info from what I remember.

We also had to add the following workaround to the vite config:

  resolve: {
    alias: {
      graphql: 'graphql/index.js',
    },
  },

See this discussion thread. Could be worth considering alternatives within that thread as well.

Another issue we ran into was name shadowing. We had a directory src/graphql that was also being mapped to the graphql module name and causing issues with vite. Changing the name/mapping fixed the issues there.

In our case, we put .mjs before .js in our webpack.config.js:

  resolve: {
    extensions: [".ts", ".mjs", ".json", ".js"], // IMPORTANT: .mjs has to be BEFORE .js
    plugins: [PnpWebpackPlugin],
  },

And it worked. That’s black magic.

@link2cory I think I finally discovered the root cause, it happens that serverless-offline uses worker threads to run the lambdas by default. Well, what that means, it means that the the lambda is instantiated in one worker thread and run in a different execution context so the Nexus schemas that are generated in the setup time uses one instance of graphql while the runtime checks after the lambda is setup uses a different instance of graphql.

By setting the following on serverless.ts it tells the serverless offline plugin that each request should run in a unique process, from setup to execution and in that case it will have the same graphql instance when nexus builds the schema and when graphql-js runs schema. This is similar to what happens in production, the same execution context is used on lambda setup and when requests are processed.

  custom: {
    'serverless-offline': {
      useChildProcesses: true
    }
  }

If experiencing with vitest, the workaround can be found here https://github.com/vitejs/vite/issues/7879. The config needs to be updated to:

// vite.config.ts

export default defineConfig({
  test: {
    server: {
      deps: {
        fallbackCJS: true,
      },
    },
  },
})

I thought I’d share my own solution here, so it may save someone else hours of headdesking.

My error message was ‘Expected <my schema> to be a GraphQL Schema’ which was traced to the ‘instanceof’ check in assertSchema.

I’d previously added an alias to my webpack config in line with this comment to work around the ‘multiple instances of GraphQL’ issue.

If you add this line, make sure the file extension is .mjs, not .js, as well as putting the .mjs before .js in the resolve.extensions. IE:

resolve: {
      // https://github.com/apollographql/apollo-server/issues/4637#issuecomment-830767224
      extensions: ['.ts', '.mjs', '.js'],
      alias: {
        // other aliases ...
        // https://github.com/apollographql/apollo-server/issues/4637#issuecomment-706813287
        graphql$: join(
            __dirname,
            'node_modules/graphql/index.mjs',    // NOT index.js !!!
          )
      },
}

EDIT: In fact, once you put .mjs before .js, you can just delete the alias! So that’s probably the best solution. https://github.com/apollographql/apollo-server/issues/4637#issuecomment-882188121

Maybe for anyone who’s encountering this issue where you’re seemingly getting this error for no reason. I’ve managed to track down why it was failing for me, and I’ve fixed it.

I got these errors because for some reason Webpack was importing both *.mjs files from graphql, and *.js files. This causes graphql to be instantiated twice, which results in this error. My error was due to the fact that the graphql-parse-resolve-info package is importing getArgumentValues from graphql/execution/values which Webpack decided to import from the *.js variation instead of the *.mjs one:

/***/ "../../../node_modules/graphql-parse-resolve-info/build-turbo/index.js":
/*!*****************************************************************************!*\
  !*** ../../../node_modules/graphql-parse-resolve-info/build-turbo/index.js ***!
  \*****************************************************************************/
/***/ ((__unused_webpack_module, exports, __webpack_require__) => {

"use strict";

Object.defineProperty(exports, "__esModule", ({ value: true }));
exports.getAlias = exports.simplify = exports.parse = exports.simplifyParsedResolveInfoFragmentWithType = exports.parseResolveInfo = exports.getAliasFromResolveInfo = void 0;
const assert = __webpack_require__(/*! assert */ "assert");
const graphql_1 = __webpack_require__(/*! graphql */ "../../../node_modules/graphql/index.mjs");
const values_1 = __webpack_require__(/*! graphql/execution/values */ "../../../node_modules/graphql/execution/values.js");
const debugFactory = __webpack_require__(/*! debug */ "../../../node_modules/debug/src/index.js");
const debug = debugFactory("graphql-parse-resolve-info");
// <SNIP MORE CODE IRRELEVANT>

As can be seen above it was importing the index.mjs variation from graphql but the values.js variation from graphql/execution/values. The fix is to replace the graphql/execution/values with the *.mjs variation: graphql/execution/values.mjs. Which can be done in Webpack by putting the following in your plugins array in your config:

plugins: [
  // other plugins maybe,
  new NormalModuleReplacementPlugin(
     /graphql\/execution\/values$/,
     'graphql/execution/values.mjs',
  )
],

Found a workaround, seems like an Apollo Server can fix it, but also it’d be nice if this package could make it a bit easier for people using @yaacovCR’s suggestion.

Not sure why there would be production slowdown, in production we are doing:

value instanceof constructor

Could do

value.kind === SCHEMA

Is that really slower if use symbol?

In development could do:

value.kind === SCHEMA && value.version === VERSION

@davidroeca looks like the alias by itself did the trick. many thanks! 🙏🏽

@onhate thank you!

@onhate THANK YOU so much, you just saved my day! 😄 😄 😄

@onhate thanks so much for diving deep into this. I have verified your solution in my dev environment, and now I wish I had taken a closer look at my deployed lambda because it works just fine (using stock serverless bundler) as your comment lead me to believe it would.

this seems to be quite an edge-case, so I imagine a true solution wont be super fast in the making. In the meantime I will post a link to the commit where I have this working for those who stumble upon this issue before that happens.

https://github.com/link2cory/portfolio-backend/tree/5a450bc1b2fc0e7bddd9192648a3991569273556

Thanks again for your help!

Of course, the instanceOf check is kind of complex…

what the user is trying to do is to make sure that the object is a schema.

But instead what the user does is check that the object is a schema instantiated with the same instance of the constructor for a schema.

but what we want the user to do is to check that the object is a schema instantiated with the same version of the constructor for a schema regardless of instance.

Maybe it makes sense instead to store metadata within the object that can use duck typing to easily check for whether it is a schema or not.

Same goes for the other type system objects…

And metadata can be added to determine what version of GraphQL the schema / type system object was created with…

Just thinking out loud…

Wow thank you so much for your help!