graphql is loaded twice, once as CJS and second time from the ESM

Describe the bug

I would like to use vitest to run tests on a backend graphql API. At the moment this is not possible, because graphql package is loaded twice and that wreaks havoc as graphql often does these instance checks and it relies on being a singleton.

To demonstrate a prepared a sample repo here, just do:

git checkout vitest-spec-config-wip
yarn
yarn test

It has a log in both js and mjs index files, so you can clearly see both are indeed running.

Expected result: graphql gets loaded only once.

Reproduction

https://github.com/capaj/startup-stage-checklist-api/tree/vitest-spec-config-wip

System Info

System:
    OS: Linux 5.13 Ubuntu 21.10 21.10 (Impish Indri)
    CPU: (24) x64 AMD Ryzen 9 5900X 12-Core Processor
    Memory: 8.99 GB / 62.75 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 1.22.17 - ~/.yarn/bin/yarn
    npm: 8.3.1 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Brave Browser: 100.1.37.116
    Chrome: 100.0.4896.127
    Firefox: 99.0

Used Package Manager

yarn

Logs

stdout | unknown test
loaded ESM graphql

stdout | unknown test
loaded CJS graphql

 ❯ app.spec.ts (0)

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Suites 1 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

 FAIL  app.spec.ts [ app.spec.ts ]
Error: Cannot use GraphQLScalarType "ID" 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.
 ❯ instanceOf node_modules/graphql/jsutils/instanceOf.js:43:19
 ❯ isScalarType node_modules/graphql/type/definition.js:117:37
 ❯ isType node_modules/graphql/type/definition.js:92:5
 ❯ resolveType file:/home/capaj/oss/graphql-repos/startup-stage-checklist-api/node_modules/decapi/dist/esm/services/utils/gql/types/typeResolvers.js:14:9
 ❯ compileFieldArgs file:/home/capaj/oss/graphql-repos/startup-stage-checklist-api/node_modules/decapi/dist/esm/domains/arg/compiler.js:68:36
 ❯ compileFieldConfig file:/home/capaj/oss/graphql-repos/startup-stage-checklist-api/node_modules/decapi/dist/esm/domains/field/compiler/fieldCompiler.js:11:18
 ❯ file:/home/capaj/oss/graphql-repos/startup-stage-checklist-api/node_modules/decapi/dist/esm/domains/schema/rootFields.js:19:16
 ❯ file:/home/capaj/oss/graphql-repos/startup-stage-checklist-api/node_modules/decapi/dist/esm/domains/schema/compiler.js:13:33
 ❯ getAllRootFieldsFromRegistry file:/home/capaj/oss/graphql-repos/startup-stage-checklist-api/node_modules/decapi/dist/esm/domains/schema/compiler.js:11:33

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯

Test Files  1 failed (1)
     Tests  no tests
      Time  917ms (in thread 0ms, Infinity%)


 FAIL  Tests failed. Watching for file changes...
       press h to show help, press q to quit

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it’s a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[freshollie]

I found the easiest solution was to patch the graphql package to delete the index.mjs file.

If I used the latest alpha, there are some libraries which are using cjs and so cannot import the mjs. Deleting the mjs means it always fallsback to the cjs and solves this issue for me.

[bluwy]

I did a check and noticed Vite doesn’t read from pkg.module (anymore?) in SSR. In other cases it’s likely a dual-package hazard issue and the fallbackCJS config may be the better way around it at the meantime. Closing as this is normal node behaviour out of scope of Vite.