TypeScript type checking errors as of @apollo/client@3.5.0

I’m trying to upgrade @apollo/client to latest (3.10.4) incrementally and found that once I reached 3.5.0 i started getting TypeScript compilation errors:

src/cron/runOnShortChronTick/recoverFirstOrders.ts:1:53 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("@apollo/client")' call instead.
  To convert this file to an ECMAScript module, change its file extension to '.mts', or add the field `"type": "module"` to '/Users/chad/src/smartrr/backend/package.json'.

1 import { ApolloClient, NormalizedCacheObject } from "@apollo/client";
                                                      ~~~~~~~~~~~~~~~~
My TypeScript configuration
{
    "compilerOptions": {
        "module": "nodenext",
        "target": "es2021",
        "allowJs": false,
        "jsx": "react",
        "skipLibCheck": true,
        "esModuleInterop": true,
        "allowSyntheticDefaultImports": true,
        "strict": true,
        "forceConsistentCasingInFileNames": true,
        "moduleResolution": "nodenext",
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "importHelpers": true,
        "removeComments": true,
        "sourceMap": true,
        "noErrorTruncation": true,
        "resolveJsonModule": true,
        "useUnknownInCatchVariables": false,
        "outDir": "./dist",
        "lib": [
            "dom",
            "dom.iterable",
            "esnext"
        ],
        "noEmit": true,
        "noEmitHelpers": true,
        "baseUrl": "./",
        "paths": {
            "@server/*": [
                "./src/*"
            ],
            "@server-test/*": [
                "./test/*"
            ],
            "@smartrr/shared/*": [
                "../shared/*"
            ]
        },
        "types": [
            "node",
            "jest"
        ],
        "moduleDetection": "force",
        "resolvePackageJsonExports": true,
        "resolvePackageJsonImports": true,
        "noImplicitAny": true,
        "noImplicitThis": true,
        "strictNullChecks": true,
        "strictFunctionTypes": true,
        "strictBindCallApply": true,
        "strictPropertyInitialization": true,
        "alwaysStrict": true
    },
    "include": [
        "src",
        "config",
        "test",
        "../packages",
        "*.ts"
    ],
    "exclude": [
        "./dist"
    ]
}

The forum software won’t let me post my package.json (“new users can only mention two users in a post”) but my node app is configured as a CommonJS application (not ESM) and I’m using Node.js 20.14.0.

I checked the 3.5.0 change log and nothing stood out. Does anyone have any suggestions on how to address this?

Hey @chadxz :wave:

The world of bundling seems so tricky these days. We did some work in Apollo Client 3.8 that tried to have some better compatibility with ESM/CJS builds (#10994). 3.5 was released 3 years ago, and I’m sure a lot has changed there.

As a quick test, can you see if upgrading to 3.8.0 resolves the import issue? (feel free to discard this change after, this just helps validate if that PR makes a difference here).

1 Like

Also potentially relevant:

In the 3.5.4 release notes, I see the following in the changelog:

Since Apollo Client v3.5.0, CommonJS bundles provided by @apollo/client use a .cjs file extension rather than .cjs.js , so Node.js won’t interpret them as ECMAScript modules

Perhaps you’re experiencing something here?

1 Like

Hey jerelmiller,

I have tried it for both 3.8.0 and 3.8.10. Still getting the same issue. Here’s the issue reproduced minimally with the current @apollo/client version. (codesandbox link)

Here’s a reproduction of it working prior to the upgrade to 3.5.0 (codesandbox link)

You can run tsc --noEmit on each to test.

Would love any guidance anyone could offer.