[TypeScript] error TS7016: Could not find a declaration file for module 'node-fetch'.

[MrChip53]

trafficstars

I am getting this error when trying to use tsc:

node_modules/@discordjs/rest/dist/lib/handlers/IHandler.d.ts:1:34 - error TS7016: Could not find a declaration file for module 'node-fetch'. '/home/chris/WebstormProjects/socom-discord-bot/node_modules/node-fetch/lib/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/node-fetch` if it exists or add a new declaration (.d.ts) file containing `declare module 'node-fetch';`

1 import type { RequestInit } from 'node-fetch';

It seems to be the same issue as this project had: https://github.com/apollographql/apollo-tooling/issues/1686

I may be wrong but I believe this package needs to be a dependency of the rest node module.

• Priority this issue should have – please be realistic and elaborate if possible: Highest, this is breaking TypeScript compilations

[FrancisUsher]

I was encountering this error, and I was able to use the workaround of adding the following to my package.json dependencies:

"@types/node-fetch": "^2.5.10"

Note the version is not 3.x as would be installed if you did npm i @types/node-fetch normally. Instead I matched it to the version in the @discordjs/rest package.

Not sure why it requires this peer dependency, I think this should be handled within the @discordjs/rest package itself.

Also for what it's worth I think this issue might belong in the @discordjs/modules repo

[ImRodry]

I don't see how this issue belongs here though, the package doesn't even have node-fetch as a dependency 🤔

[MrChip53]

I don't see how this issue belongs here though, the package doesn't even have node-fetch as a dependency thinking

This may need triaged somewhere. This is relative to the rest npm package.

"dependencies": {
		"@discordjs/collection": "^0.1.6",
		"@sapphire/async-queue": "^1.1.4",
		"@sapphire/snowflake": "^1.3.5",
		"abort-controller": "^3.0.0",
		"discord-api-types": "^0.18.1",
		"form-data": "^4.0.0",
		"node-fetch": "^2.6.1",
		"tslib": "^2.3.0"
	},
	"devDependencies": {
		"@types/node-fetch": "^2.5.10"
	}

There are the deps in the package.json I have for it in my node_modules folder. It seems it actually does have @types/node-fetch listed. Any idea why it isnt pulling that dep into my project?

Edit: I deleted package lock and node_modules, ran npm install. Seems to be working fine. I'll close this and reopen if I confirm its breaking and not fixed.

Edit2: Forgot I commented my offending code out. It's still an issue.

[iShibi]

npm doesn't install devDependencies of a package. This is the desired behaviour but it creates issues if the package is importing types from one of the devDependencies and your project is in TS.

The solution is to install that dev dependency yourself...or ask the maintainers of the said package to put it under dependencies instead 👀

[sindrekjr]

This is a strange error, and putting a @types packages under dependencies doesn't seem like a satisfactory solution on any level since they're strictly only required for development.

Personally I would just install it as a devDep since that solves the problem, but it makes you wonder if it should've been registered as a peerDep on a lower level package somewhere.

[DTrombett]

What about using the --skibLibCheck flag 🤔

[vladfrangu]

Ironically, this is an issue that node-fetch v3 solved, with the caveat it's ESM only*

Usually, I've recommended using skipLibCheck for issues like these, but I know some people are against turning that off. In discord.js, we added @types/ws as a dependency and I suppose we can do that here too for node-fetch

* It's ESM only, but they suggest a super simple wrapper for CJS users in their readme, so it's not a big problem

[MrChip53]

If it is improper to add it as a regular dependency is fine although if you all ever updated node fetch then it would fall on me to keep my types package up to date. Maybe this is just a shortcoming of npm as a whole.

[sindrekjr]

I would argue it's a shortcoming of the convention of using @types packages. In general they are a net positive for the npm community because it means we can have typescript types even if the actual package (node-fetch) hasn't supplied them on its own, but in practice it means that we're inevitably gonna run into issues when making a package that uses typescript but depends on an underlying package that doesn't.

It seems to rarely be an issue but it happens.