Missing "exports" property in package.json

[dchenk]

Intended outcome:
Importing '@apollo/client' into an ES module works.

In my experimenting with a fix, I found antfu-collective/vite-ssg#241 and added the postinstall script to add an exports property to the package.json files in the client and client/core packages.

The client package:

"exports": {
    ".": {
      "import": "./index.js",
      "require": "./main.cjs",
      "types": "./index.d.ts"
    },
    "./core": {
      "import": "./index.js",
      "require": "./core.cjs",
      "types": "./index.d.ts"
    },
    "./react": {
      "import": "./react/index.js",
      "require": "./react/react.cjs",
      "types": "./react/index.d.ts"
    },
    "./react/context": {
      "import": "./react/context/index.js",
      "require": "./react/context/context.cjs",
      "types": "./react/context/index.d.ts"
    },
    "./*": "./*"
  }

The client/core package:

  "exports": {
    ".": {
      "require": "./core.cjs",
      "import": "./index.js",
      "types": "./index.d.ts"
    }
  }

Actual outcome:
Error from Node.js:

SyntaxError: Named export 'ApolloClient' not found. The requested module '@apollo/client' is a CommonJS module, which may not support all module.exports as named exports.

How to reproduce the issue:
Install Node.js version 18.7.0. Set up a project with "type": "module". Install @apollo/client and import it this way:

import { ApolloClient } from '@apollo/client';

Run Node.

Versions

  System:
    OS: macOS 12.4
  Binaries:
    Node: 18.7.0 - ~/.nvm/versions/node/v18.7.0/bin/node
    npm: 8.15.0 - ~/.nvm/versions/node/v18.7.0/bin/npm
  Browsers:
    Chrome: 103.0.5060.134
    Safari: 15.5
  npmPackages:
    @apollo/client: ^3.6.9 => 3.6.9 

[websitevirtuoso]

D we have any changes by this? I have the same problem with 2 more files
import { onError } from '@apollo/client/link/error'
import { setContext } from '@apollo/client/link/context'

[jonkoops]

I can confirm this also fixes issues with module resolution when using TS Node and ESM.

[JasonKleban]

Is this the right fix or the wrong fix, maintainers? Is it a simple PR?

[revmischa]

Any chance this improves tree-shaking when using esbuild?

[benmccann]

You can see that the package is broken by checking its validity with publint: https://publint.dev/@apollo/client@3.7.14

[phryneas]

@benmccann it is not "broken".
That validator has two complaints:

• .cjs.native.js files being CommonJs with a .js file extension. React Native expects files to have a .native.js file extension. These files are only ever read by the React Native Bundler, and that bundler handles these files just fine.
  No other environment will ever read these files. This is not a problem.
• The absence of a exports field. I guess, I should add some context on this - more context can be found in Add export specification #9697 (comment) and Update module resolution to NodeNext #10620 (comment).
  Generally, after many other packages trying this and breaking things, adding an exports field is largely seen as a breaking change in the maintainer community. We will do this with the release of Apollo Client 4, but we cannot just release a Apollo Client 4 to add this, and we cannot release a version of Apollo Client 3 with exports.
  As exports is a relatively (yeah, I get it, with stuff like module formats "relatively" can mean very long timespans) new addition to the ecosystem and some major tools still have not figured out a coherent & easy-to-implement story about it, this is not "broken", it's something that validator would like to see there, but that's not here there for reasons of backwards compat.

It's an unfortunate situation, but nothing we can immediately act upon without breaking Apollo Client for tons of installations.

[jakeisnt]

Why not re-release and bump the major version? It's not difficult to explain why and there won't then be compatibility issues.

[benmccann]

.cjs.native.js files being CommonJs with a .js file extension. React Native expects files to have a .native.js file extension. These files are only ever read by the React Native Bundler, and that bundler handles these files just fine.
No other environment will ever read these files. This is not a problem.

Thanks for pointing this out. I filed an issue with the validator so that hopefully we avoid false reports in the future: publint/publint#41

we cannot release a version of Apollo Client 3 with exports.

Agreed that adding exports is a breaking change

this is not "broken"

I think it's correct to say that the issues in the validator are not indicative of something being broken. However, the package is still broken when used directly in a Node.js ESM project without bundling as can be seen in the original issue description, so I'm afraid there is still an issue here besides just following the latest trends and practices unfortunately. Understandable that you'd like to group breaking changes together into a new major release though. Is there anywhere to track when a new major might occur? We've been getting bug reports about this for a couple years (#8218), so I'm sure users are eager to see a new major