Cannot find module 'graphql-request' or its corresponding type declarations.

[tofsjonas]

Screenshot VS Code

Screenshot npx tsc --noEmit

Description

When installing 7.0.1 typescript fails. 6.1.0 works as expected.

I have tried with both pnpm and npm. I haven't tried with yarn.

• Node v20.11.0
• Npm 10.5.0
• Pnpm 9.1.2
• Apple M1 Pro
• MacOS Sonoma 14.5 (23F79)

tsconfig.json

{
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "ES2021",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true,
    "skipLibCheck": true,
    "strictNullChecks": false,
    "noImplicitAny": false,
    "strictBindCallApply": false,
    "forceConsistentCasingInFileNames": false,
    "noFallthroughCasesInSwitch": false
  }
}

(I have tried with other tsconfig setups, but they all fail.)

Reproduction Steps/Repo Link

Repo: https://github.com/tofsjonas/graphql-request-test
Install and run

[tofsjonas]

Ok, so if I set "type":"module" in package.json it works.

Everything ELSE breaks though... 😭

Is there any way to make "type":"module" not a requirement? 🤞

[jasonkuhrt]

@tofsjonas unfortunately not, this is an ESM project. Are you stuck in the CJS world? https://github.com/jasonkuhrt/graphql-request?tab=readme-ov-file#typescript-setup

[tofsjonas]

Haha, well, I wish I wasn't.

The repo I shared was a completely fresh nest.js project. (Sure, nest.js doesn't have as many downloads as graphql-request, but it's still a significant package)

If I add "type":"module" to this tiny, tiny hello-world project I get

(In my actual project, I have hundreds of files with thousands of imports.)

To fix it I have to go into every single file that imports from another file and alter

import { AppService } from './app.service';

to

import { AppService } from './app.service.js';

Either that or figure out some bundler magic with babel or what have you.

It would be so, so very nice not to have to do that... 🥺🐶

[mrbfrank]

@tofsjonas if you use "moduleResolution": "bundler" in .tsconfig.json you won't have to add file extensions
https://www.typescriptlang.org/tsconfig/#moduleResolution

I've gotten that far updating my project, now trying to get Jest working with ESM.. So I agree this brings a challenge for some established projects.

[tofsjonas]

"moduleResolution": "bundler" fixes that particular problem, thanks for that (I was sure I had tried that already, but I guess I messed it up somehow)

Now I just have to get the ci pipeline to work again. But I guess that can wait until Monday..

Thank you both for your time! 🙏

[jasonkuhrt]

This poll might be relevant for you #863

[tofsjonas]

Er, I take it back.

When using "moduleResolution": "bundler" I didn't get any errors when running linting and tsc, so I moved on with my life. But when I tried to actually run the project I got the same error as before

Cannot find module '/Users/jonas/graphql-request-test/dist/app.module'
imported from /Users/jonas/graphql-request-test/dist/main.js

If I add .js to the import it works as expected, but I can't do that in my actual project 😞

[kolya182]

Eventually this combination worked from me:
tsconfig.json

{
  "compilerOptions": {
    "lib": ["ES2019"],
    "module": "ES6",
    "target": "ES6",
    "esModuleInterop": true,
    "moduleResolution": "bundler",
  }
}

[danzho]

Here's how you can migrate your Typescript + Node application from commonjs to ESM:

• package.json: Add top-level key pair "type": "module"
• tsconfig.json: Set "module": "Node16" and "moduleResolution": "Node16" ("target" can stay as "EsNext")
• code: Add .js extensions to all of your local module imports. For example, change import x from "./x" to import x from "./x.js". Don't try to get .ts extension to work, it's not worth it.
• code: Add "node:" prefix to Node stdlin imports like import stream from "node:stream". (not actually required since TS already knows how to resolve them)
• quirk: a lot of major libraries don't let you destructure their imports anymore once you're using ESM. one example is pg (node-postgres). you have to change import {Client} from "pg" to import pg from "pg" and then use pg.Client in your code. you also may need to change some library usage form foo(x) to foo.default(x).

I think that's it. That last step is most of the pain but if you're lucky it only affects a couple libraries you're using.

If you wonder why your Node project needs to be forced to use ESM even though everything on NPM supports commonjs except this one library, you're not alone. ;)

[jasonkuhrt]

Going to lock this issue now to keep my notification noise down. If you have comments about the library you can leave that in the discussions forum. There is also a poll I'm looking at occasionally to help gauge the impact of not supporting CJS linked to above. Sorry for users feeling the pain of CJS/ESM. Ultimately the way out of this is everyone dropping support for CJS and users upgrading their projects. Our Python 2/3 moment.