Add Node/Browser ESM support to @apollo/client.

[brainkim]

This is a tracking issue for the work to add native ESM support for new Node versions and direct <script type="module"> references for the @apollo/client package.

This would probably mean adding "type": "module" to package.json files and potentially exports fields. It may also include changes to the build system and package artifacts. It is potentially a breaking change for unwitting developers who have imported files which we never intended to export.

Maybe this is a low priority, especially given most bundlers and front-end tools conflate and handle CommonJS and ESModules out of box, and I’m not sure what percentage of users import apollo-client from ESM-capable node versions. Maybe someone doing SSR?

Also note that this is a risky change to the codebase which will cause outages if we don’t dot our t’s and cross our i’s. See https://javascript.plainenglish.io/is-promise-post-mortem-cab807f18dcc, for instance.

@benjamn @hwillson @jcreighton

Related issues:
#81 #83

[JanNitschke]

This could also be accomplished by switching all generated module files in the dist folder to the mjs file extension and changing "module": "index.js" to "module": "index.mjs" in the package.json file. This lets node import these files directly and should not break any build tools but would beak all import specifying the file extension:

import { ApolloClient } from '@apollo/client/core/ApolloClient.js';

This could be fixed by keeping the .js files and duplicating them with the .mjs extension.

I used this to get Apollo working in a esbuild project that only works with native ESM.

[eric-burel]

Hi, this is problematic for us at Vulcan since we have moved our package library, that depends on @apollo/client, to ESM.
Our library won't work in Next and users are facing similar issues in Svelte or Nuxt.

This StackOverflow question sums it up: https://stackoverflow.com/questions/70615613/apollo-client-named-export-remove-not-found
We have the same issue with gql, useQuery etc. with no solution yet except maybe writing a custom Esbuild plugin to alter the import.

Next.js, which is based on Webpack 5, doesn't seem to support just having "module": "index.js", exports are needed instead. I could fix most issues by adding this to my @apollo/client package.json:

"exports": {
    ".": "./index.js",
    "./link/error": "./link/error/index.js"
  },

And also in ts-invariant package.json:

  "type": "module",
  "exports": {
    ".": "./lib/invariant.esm.js",
    "./process/index.js": "./process/index.js"
  },

And finally to ts-invariant/process package.json:

  "type": "module",

[eric-burel]

Here is a gist: https://gist.github.com/eric-burel/543bdc809bcc62208deabdeb004db724
Tested with Apollo 3.5.10
Add node ./fix-apollo.js to postinstall package.json

[fabis94]

Any updates here? A year later it's still an issue when trying to use @apollo/client with something like Nuxt on Node 16

file:///home/fabis/Code/speckle/speckle-website-fe/node_modules/@apollo/client/utilities/globals/fix-graphql.js:1
import { remove } from "ts-invariant/process/index.js";
         ^^^^^^
SyntaxError: Named export 'remove' not found. The requested module 'ts-invariant/process/index.js' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'ts-invariant/process/index.js';
const { remove } = pkg;

    at ModuleJob._instantiate (node:internal/modules/esm/module_job:127:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:191:5)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:337:24)
    at async __instantiateModule__ (file:///home/fabis/Code/speckle/speckle-website-fe/.nuxt/dist/server/server.mjs:23402:3)

[eric-burel]

Any updates here? A year later it's still an issue when trying to use @apollo/client with something like Nuxt on Node 16

file:///home/fabis/Code/speckle/speckle-website-fe/node_modules/@apollo/client/utilities/globals/fix-graphql.js:1
import { remove } from "ts-invariant/process/index.js";
         ^^^^^^
SyntaxError: Named export 'remove' not found. The requested module 'ts-invariant/process/index.js' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'ts-invariant/process/index.js';
const { remove } = pkg;

    at ModuleJob._instantiate (node:internal/modules/esm/module_job:127:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:191:5)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:337:24)
    at async __instantiateModule__ (file:///home/fabis/Code/speckle/speckle-website-fe/.nuxt/dist/server/server.mjs:23402:3)

It seems that exports map is not an option for Apollo because it would break older applications, so the best hope seems to figure out why bundlers are not supporting this. Next has the same issue and rely on Webpack 5, I think that's also the case for Nuxt according to what I've read online, and maybe other frameworks

[fabis94]

@eric-burel Why not just convert the imports to the format shown in the error message?

[eric-burel]

@eric-burel Why not just convert the imports to the format shown in the error message?

@benjamn can maybe have more info

I am not sure it's that easy, when your package have a mix of ES modules that can in turn import modules that are either CJS or ESM, you are up to trouble.
Technically you can change the way Apollo expose package via an export map in package.json (that's what I do and I have a setup that works ok, though I need this hot patch on postinstall), but I am not sure if it's the core issue, maybe some Webpack pros could help as well

[eric-burel]

This breaks with Jest 28 as well, I had to reintroduce @apollo/client and ts-invariant in the build:

// in my jest config
  transformIgnorePatterns: [
    "/node_modules/(?!(@apollo/client|ts-invariant))",
    "^.+\\.module\\.(css|sass|scss)$",
  ],

and also extend my patch to provide a full export map for all internal packages of @apollo/client. Finally, I needed to import "gql" from "graphql-tag" instead of @apollo/client.

Demo: VulcanJS/vulcan-npm#115

[momenthana]

I modified the package.json because I had to use esm only modules(ex: unified, remark ...)

// package.json
...
"type": "module",

a detour by applying it like this in the Jest test

// <rootDir>/lib/test/apollo.cjs
const apollo = require('@apollo/client/main');
const gql = require('graphql-tag');

module.exports = { ...apollo, gql };

// jest.config.js
...
moduleNameMapper: {
  '^@apollo/client$': '<rootDir>/lib/test/apollo',
},

with ts-jest

// jest.config.js
...
preset: 'ts-jest/presets/js-with-ts-esm',
globals: {
  'ts-jest': {
    tsconfig: 'tsconfig.json',
  },
},

// import { ApolloClient, InMemoryCache, NormalizedCacheObject, from, HttpLink } from '@apollo/client';
import { ApolloClient, InMemoryCache, NormalizedCacheObject } from '@apollo/client/core';
import { from } from '@apollo/client/link/core';
import { HttpLink } from '@apollo/client/link/http';

[stephenjason89]

Would really appreciate an update on this. Currently using it with nuxt 3

[underblob]

Node 16 SSR ESM project: we point to the internal index.js in the package. Seems to work.

import { ApolloClient, from, gql } from '@apollo/client/core/index.js';
import { HttpLink } from '@apollo/client/link/http/index.js';
import { InMemoryCache } from '@apollo/client/cache/index.js';
import { createPersistedQueryLink } from '@apollo/client/link/persisted-queries/index.js';

[stephenjason89]

@underblob Thank you, this seems to work.