process is not defined in browsers

[justinfagnani]

Even though this seems to have been at least partially addressed in #1058 there are still references to process in the code, like https://github.com/graphql/graphql-js/blob/main/src/jsutils/instanceOf.ts#L12 that cause errors when loading modules in the browser.

[yaacovCR]

Can you include more details about the error you are experiencing? The ? operator in the line you referenced is supposed to help avoid an error if process is undefined...

[kettanaito]

This issue is still reproducible on the latest version graphql@16.6.0 despite the fix being merged a year ago (#3501). It does seem to exist in the latest HEAD, so I assume it hasn't been released yet?

@yaacovCR, I can provide more details about the issue.

Details

What happens?

The graphql package fails to run in the browser.

How do you know that's the case?

Because it throws the following error on runtime:

ReferenceError: process is not defined
  at /node_modules/.pnpm/graphql@16.6.0/node_modules/graphql/jsutils/instanceOf.mjs:13:3

This is a rightful error since the latest published version relies on the global process that doesn't exist in the browser.

How to reproduce this?

npm init -y
npm install graphql@16.6.0 # latest at the moment

<!-- index.html -->
<script type="module">
  import graphql from 'graphql'
</script>

// wds.js
import { startDevServer } from '@web/dev-server'

const wds = await startDevServer({
 config: {
    nodeResolve: {
      exportConditions: ['browser'],
    },
  },
})

The ESM setup may be irrelevant, I'm just sharing how I'm reproducing it right now.

node ./wds.js

Open the served index.html in the browser, open the browser's DevTools, go to "Console", see the mentioned exception.

How can this be resolved?

This package shouldn't rely on Node.js globals if it's intended to run in the browser also. Based on the existence of the #3501 and #1058, I assume that there is such an intention.

The action here may be to release the 16.x version that contained the #3501 fix so you don't have to go full major bump that's currently in alpha tag.

Let me know if I can help. I would love to see this fixed.

[Andarist]

It's worth noting here that nowadays package.json#exports are a perfect replacement for the process.env.NODE_ENV !== 'production' convention (at the expense of complicating the build process)

[abooayoob]

@Andarist Can I ask for any pointers on what this means? package.json#exports are a perfect replacement for the process.env.NODE_ENV !== 'production'

[justinfagnani]

If means that your default export condition can be the production build and the 'development' export condition can be the development build.

[yaacovCR]

The action here may be to release the 16.x version that contained the #3501 fix so you don't have to go full major bump that's currently in alpha tag.

Let me know if I can help. I would love to see this fixed.

Backporting #3501 to the 16.x branch seems like a great idea. A PR would definitely be appreciated and then we can ping @IvanGoncharov for a release. Thanks!

[kettanaito]

@yaacovCR, will open the PR then against the latest 16.x state of the repo. Will let you know.

[kettanaito]

@yaacovCR, the pull request with the backport for 16.x is open at #3887. cc @IvanGoncharov, if I may, I would appreciate a quick look at that fix to unblock MSW and other consumers experiencing this issue. Thanks!