test and development should both invoke the non-production behavior.

To minimize the size of this PR, I'd personally rewrite this to just:

const isProduction = process.env.NODE_ENV !== 'development' && process.env.NODE_ENV !== 'test';

Then the lower lines in this PR shouldn't be needed.

9654570

so this is now:

const isProduction = globalThis.process == null || (process.env.NODE_ENV !== 'development' && process.env.NODE_ENV !== 'test');

retaining the check to see whether process is defined globally

JoviDeCroock/graphql-minifier-experiments#1

I have not gone through all the bundlers, but I think that flipping the default would require us changing our instructions about what to set globalThis.process to, now we would have to set to null

https://github.com/graphql/graphql-js/blob/16.x.x/website/docs/tutorials/going-to-production.md

and if I remember correctly, the reason that is in at all is to support cloudflare.

So I am not sure if I want to move forward with this PR actually.... as if we have a better long-term solution, we should move to that without this intermediate stage......?

@JoviDeCroock @benjie @phryneas

Long-term solution: 3 versions of this file - one with the development export condition, without any of this logic, one with the production export condition without any of this, and one default that falls back to this (or a similar) solution.

@phryneas I closed #4221 because once we use an imports map, it becomes tricky to use graphql in browsers in a bundler-free manner. I think unfortunately using the exports map and publishing instanceOf might have the same problem.

@yaacovCR What problems are you seeing?
Generally, I'd say that unless we publish only a single file, users will have to adopt import maps, but that's the future of ESM on the web anyways.

PS: see https://github.com/apollographql/apollo-client/blob/main/integration-tests/browser-esm/html/jspm-prepared.html for an example

(That said, if we were to continue with #4221, we would need to ship a rolled-up browser entry point that didn't reference imports - maybe with a separate development and production build.
To be honest, I don't really think we'd need sub-entrypoint browser builds, people who run without a bundler probably don't care about saving bundlesize anyways.)

I’m not sure if we want to require the use of an import map but I would definitely defer to @JoviDeCroock on that.

@phryneas Import maps are still being adopted and imho aren't in a well enough state yet for a reference implementation based on a standard to adopt nor is the spec far along enough for it. My two cents here being that either we remove instanceof all together and replace it with a branded symbol/types only approach or we keep the status quo but default to production instead.