lquixada / cross-fetch

Universal WHATWG Fetch API for Node, Browsers and React Native.
MIT License
1.66k stars 102 forks source link

TypeScript conflicts with polyfill and cloudflare workers-types #174

Open jmaroeder opened 10 months ago

jmaroeder commented 10 months ago

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: https://github.com/lquixada/cross-fetch/blob/1fb2350e9e26bdc1a7903b8d5d051828503fbff6/polyfill/package.json#L7

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).