Types are broken with `compilerOptions.module` set to `nodenext` due to imports missing file extensions

Intended outcome:

Projects with TypeScript config compilerOptions.module set to nodenext or node16 should be able to import @apollo/client modules with working types. This is critical for using TypeScript correctly with modern Node.js packages or projects that use the package exports field, ESM in .mjs files, etc.

Actual outcome:

Types are broken for @apollo/client modules that have types that import other modules/types without correctly specifying the file extensions in the imports.

How to reproduce the issue:

In package.json:

{
  "name": "demo",
  "private": true,
  "dependencies": {
    "@apollo/client": "^3.6.9"
  }
}

In jsconfig.json:

{
  "compilerOptions": {
    "maxNodeModuleJsDepth": 10,
    "module": "nodenext",
    "noEmit": true,
    "strict": true
  }
}

In demo.mjs:

// @ts-check

import { ApolloLink } from "@apollo/client/link/core/ApolloLink.js";

new ApolloLink((request) => {
  console.log(request);
})

Notice how the types are incomplete for the ApolloLink constructor arguments and fall back to any:

If you dig into the types for it, you can see that the RequestHandler type is being imported incorrectly (missing the file extension) from ./types, and TypeScript is unable to tell what its type is:

If you change the import path to ./types.js (add the missing file extension), the types start to work:

Ultimately fixing the types where ApolloLink is being constructed in the project:

All imports, including for type only imports, should specify the full path including the file name for the module being imported.

As a side note, type only imports should use the type keyword but currently they don’t:

https://github.com/apollographql/apollo-client/blob/289336a5e126cb4b4ca9ec08badc68c9cd3e50fd/src/link/core/ApolloLink.ts#L4-L10

E.g:

import type {
  NextLink,
  Operation,
  RequestHandler,
  FetchResult,
  GraphQLRequest
} from './types.js';

Versions

• Node.js: v18.4.0
• typescript: v4.7.4
• @apollo/client: v3.6.9

[shaunco]

Any updates on this? This is causing us quite a bit of pain as we try to move from CJS to ESM, and it seems like a pretty simple fix for the Apollo client…

[GeenCo86]

We were able to resolve this same issue for AS4 via apollographql/apollo-server#6731

What is the result of this. Is there a fix in the client library or will it ?