apollo-client: 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:
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
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 14
- Comments: 17 (10 by maintainers)
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…
would be great if you guys could provide an update here. thank you in advance!
What is the result of this. Is there a fix in the client library or will it ?