Description
In other words, the following dynamic imports should succeed in modern web browsers without errors:
import("https://cdn.jsdelivr.net/npm/@apollo/client@beta/core/+esm")
import("https://esm.run/@apollo/client@beta/core")Since the goal here is to load native ECMAScript modules, not UMD or CommonJS bundles, all npm dependencies of @apollo/client/core must export ECMAScript modules for the above import(...) to succeed. See #8222 (comment) for background on several packages that violated this requirement, but that we have fixed/removed/replaced. Progress!
Another remaining issue is that our ts-invariant dependency was previously polyfilling globalThis.process, but stopped (for good reasons) in apollographql/invariant-packages#94, which was released in [email protected], which will be required by @apollo/[email protected].
While many bundlers/minifiers replace process.env.NODE_ENV at build time with a string literal like "production", there are a number of libraries, including @apollo/client, graphql, and react, that publish code containing those process.env expressions, expecting them either to be stripped or polyfilled. Neither expectation is met when these packages' code is loaded from an ESM-aware CDN like https://esm.run, so the first unguarded process reference throws a fatal ReferenceError.
We are actively looking for a good alternative approach (tracking issue: #8187), but in the meantime it seems important for backwards compatibility to continue polyfilling globalThis.process.env until Apollo Client 4, by which time hopefully the graphql package will have removed its (single!) use of process.env.NODE_ENV (in instanceOf.mjs).
While we're at it, @apollo/client should make its own usages of process.env more defensive about running in environments without a global process object and no build step to remove those expressions.