feat: replace instanceOf with unique Symbol checks

[n1ru4l]

This is the first step for a potential reintroduction of CommonJS alongside ESM that avoids the dual package hazard instanceOf issues.

~~In addition, I think it would make sense to introduce and assert a flag on globalThis in order to avoid multiple GraphQL.js versions being used together (unless there is a valid use case) that should be importet at the top of each entry-point file.~~

entry-shim.ts

const versionSymbol = Symbol.for("loaded-graphql-version")

if (globalThis[versionSymbol] && globalThis[versionSymbol] !== version) {
  throw new Error("Tried loading two different GraphQL versions. Please resolve your resolutions.")
}

globalThis[Symbol.for("graphql-version")] = version

Update: I don't think we should manually assert the GraphQL version with an entry-shim as described above. Resolving a single version of GraphQL is the responsibility of the package manager.

The motivation behind this PR is the reality that CommonJS and ESM will co-exist for some more time until the whole ecosystem catches up. See https://github.com/graphql/graphql-js/issues/3603

---

Related:

• https://github.com/graphql/graphql-js/issues/3603
• https://github.com/graphql/graphql-js/pull/3616

[netlify[bot]]

✅ Deploy Preview for compassionate-pike-271cb3 ready!

Name	Link
🔨 Latest commit	5bdfe613f839e9a8b7bccf6d5e7993bdc69bc142
🔍 Latest deploy log	https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/62b0c97843924f00087bca26
😎 Deploy Preview	https://deploy-preview-3617--compassionate-pike-271cb3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[yaacovCR]

Makes sense to me in terms of separating version checks from instanceOf checks, the two are related, but ultimately separate concerns. I guess the version check changes should be part of this PR if old instanceOf behavior is being deprecated.

[Fundamentally, I don't think we should be doing version checks. If the TS type signatures align, imo that is the package manager's responsibility and graphql-js should get out of the way.

But considering we currently do, I guess it is reasonable to continue.]

[yaacovCR]

Review requested? Approach seems great -- although we also need to decide about whether/where/how to enforce common version.

Generally, I think we need feedback from @IvanGoncharov or perhaps the larger graphql-js-wg or even the main graphql-wg to figure out which way forward on esm only.

[IvanGoncharov]

We have two use cases that this change potentially can solve:

1. CJS/ESM
2. passing Schema to workers, see #2801

However #2 is need to be confirmed, see: https://github.com/graphql/graphql-js/issues/2801#issuecomment-1154000057

Do you know any other use case this change solves beyond ESM/CJS?

[IvanGoncharov]

I'm asking because if we just addressing CJS/MJS here, we need to compare it with the solution from #3361 or other similar solutions.

[n1ru4l]

@IvanGoncharov I am not a big fan of https://github.com/graphql/graphql-js/pull/3361 as it would require using resolution overwrites. On yarn using resolutions is straightforward and handy. On npm, you will have to use third-party packages. 🙁 (https://www.npmjs.com/package/npm-force-resolutions)