Module '"buffer"' has no exported member 'Blob'

Question

Have anyone been in this situation before ? I run my code with CI/CD after nest build, it gives me error : node_modules/@types/superagent/index.d.ts:23:10 - error TS2305: Module '"buffer"' has no exported member 'Blob'. 23 import { Blob } from "buffer";

I don't know why? Please share if you got a solution for this one.

Axseed

looks like this is related with the version of your @types/node or something like that – Until

It is so weird because yesterday everything is still fine to me :( . I still use the same node version with it. – Axseed

have you versioned the lock file and ran npm ci? – Until

I will try it now. But when I run in local , it is still good? only when I push it to gitlab and run CI/CD , it gives me this error. Have you ever got something like this before ? – Axseed

I haven't. I've been using GitHub Actions in TS projects without worries so far. Maybe the version that your CI/CD end up having isn't the same as the local one due to the lack of the lock file and npm ci – Until

Yes, I got your point. But it seems like the answer from @vfrank66 is the answer I need. – Axseed

Thank you @MicaelLevi . Your comments are so helpful – Axseed

Answer 1

We had the same problem after upgrading nest 7.5.x to 8.0.0. The dependency "supertest" for "nestjs/testing" has a dependency on "@types/supertest" which wildcards "@types/superagent": "*", and that dependency has another wildcard dependency "@types/node": "*", but the types within @types/supertest actually require @types/node >=16.X.X.

So nestjs/testing -> supertest -> @types/supertest -> @types/superagent -> @types/node >= 16.X.X is your problem and error.

The comments mentioned are accurate because these package managers wildcard their dependencies to get the latest version of dependencies. They should but do not add peerDependencies with dependencies requirements such as "@types/node": "">=12.0.0 <16.0.0". Instead they say anything, "@types/node": "*" so the error is post package install, no npm warnings/errors. "It worked yesterday but not today" is your big red flag because when you ran npm install, with these wildcard dependencies even though you did not know it installed the latest version. Since it installed everything wildcard today, but not yesterday, it worked yesterday.

In addition, but also important is that you are have pinned @types/node <16.0.0 thus your error in combination with the other package changes.

One option: revert your package-lock.json changes and run npm ci

Another option: set your package.json dependency for @types/node to -> "@types/node": "^16.0.0",.

Another option: accept that wildcards are wrong and you don't trust what is going on there so pin the @types/superagent dependency to the one prior.

As for me and my family, we use nestjs with AWS lambda which runtime does not include nodejs 16, and not everyone on my team runs npm ci we more typically run npm install so the solution was

package.json

    ...
    "devDependencies": {
        ...
        "@types/node": "14.18.2",
        "@types/superagent": "4.1.10",
        "@types/supertest": "^2.0.11",
        ...

Castara

Thank you for the solution. I will try it and let you know soon. – Axseed

Thank you. To me, your first option works. – Axseed

For me the problem was a mismatch of my running node version and @types/node. So after updating types to match node major version it works. – Michealmicheil

Thank you, person with a big heart <3 – Elenoraelenore

14.8.2 doesn't seem to exist. Hugo's answer worked for me. – Gardening

@Gardening it does exist: npmjs.com/package/@types/node/v/14.18.2 – Castara

You can actually use node 14 without specifying @types/superagent with the latest versions. The following work: - node: 14.21.1 - @types/node: 14.18.34 - @types/supertest: 2.0.12 – Sacristan

Answer 2

Upgrading @types/node to ^14.18.10 and typescript to ^3.9.10 worked for me.

"devDependencies": {
  "@types/node": "^14.18.10",
  "typescript": "^3.9.10"
},

Found on this discussion from Github

Out

Answer 3

downgrading @types/superagent from v15.x.x to 14.1.14 solved the issue for me. v15 had some performance issues at the typing of this message "npm i --save @types/[email protected]" did the trick

Tisbe

Answer 4

One tip is use npm view to get some info.

If you type

npm view @types/node

That shows the ts version compatibility. In my case, Is had to upgrade @types/node to 14.14.31, because I'm using ts 3.4.2.

Lulalulea

Answer 5

if you have installed the npm, then delete the node_module file and use yarn install to add the new node_module and vice versa.

Thrave

Answer 6

I had similar issue and updated @types/node from version '13.7.0' to '^14.0.0' and it worked

Geelong