Description
#148 seems to have introduced a regression of sorts when using a library which has its own definitions of types used by fetch
.
The following code worked fine with earlier versions, but it appears that the introduction of types
to polyfill/package.json
causes some conflicts to occur:
cross-fetch/polyfill/package.json
Line 7 in 1fb2350
Here is an example project.
package.json
{
"name": "cross-fetch-cloudflare-workers-types",
"version": "1.0.0",
"main": "index.ts",
"license": "MIT",
"devDependencies": {
"@cloudflare/workers-types": "4.20230904.0",
"cross-fetch": "4.0.0",
"typescript": "5.2.2"
}
}
tsconfig.json
{
"compilerOptions": {
"lib": ["esnext"],
"module": "esnext",
"moduleResolution": "node",
"strict": true,
"target": "esnext",
"types": ["@cloudflare/workers-types/2022-11-30"]
}
}
index.ts
import 'cross-fetch/polyfill';
export default {
async fetch(request: Request) {
const response = new Response();
return new Response(`request method: ${request.method}`);
},
};
Running tsc
on this project leads to a bunch of errors about conflicts between node_modules/typescript/lib/lib.dom.d.ts
and node_modules/@cloudflare/workers-types/2022-11-30/index.d.ts
.
I have discovered a workaround - creating an empty file and remapping the path in tsconfig's compilerOptions
:
"paths": {
"cross-fetch/polyfill": ["./.sink.d.ts"]
},
However, it seems like cross-fetch/polyfill
shouldn't be specifying a specific types
, and should instead be relying on tsconfig
to include the appropriate types (either via lib
or types
).