Linus Unnebäck

> Except for typescript where it's translated into a require() call, which is what we want to avoid with this wrapper... This is fixed in the latest TypeScript beta, which...

Looks like a great list! - Re. #1347, I think that we should remove the `main` field as well. - Node.js v14.18.0 added `Blob` directly to core, can we set...

> [...] , don't do this yet. @yinzara we will continue to fix critical bugs and security issues in 2.x, so there should be nothing preventing anyone to stay on...

> Type 'Request' is missing the following properties from type 'Body': size, bufferts This is interesting, it seems like our typings aren't compatible with those in dom.d.ts 🤔

Potentially something like this could work? ```ts import fetch, { Headers, Request, Response } from 'node-fetch'; if (!('fetch' in globalThis)) { Object.assign(globalThis, { fetch, Headers, Request, Response }) } ```

Hmmmm, `credentials` is listed as one of the options that we do not implement. ref: https://github.com/node-fetch/node-fetch#class-request Should we really add it to the type definitions if we don't support it?...

It's unfortunate that a 3.x version of `@types/node-fetch` got published, but unfortunately there isn't anything that we can do about this here. I would recommend opening an issue on https://github.com/DefinitelyTyped/DefinitelyTyped...

`ts-node` has experimental support for ESM, you can use it as such: ```sh node --loader ts-node/esm ./my-script.ts ``` Full instructions is available here: https://github.com/TypeStrong/ts-node/issues/1007

Unless TypeScript provides a native json type (https://github.com/microsoft/TypeScript/issues/1897), I think that `unknown` is absolutely preferred over `any`. If you have it return `any`, you don't get any type safety at...

@Richienb hmm, the documentation for the type you linked says this though 🤔 > Don't use this as a direct return type as the user would have to double-cast it:...