Open dmaesj opened 9 months ago
Thanks for bringing this up. Node.js's new built-in fetch() function actually doesn't lean on the traditional http and https modules we've been using for ages. Instead, it's built on a shiny new HTTP stack named undici, crafted from scratch.
Now, because fetch() is running on this separate stack, the usual suspects—the options we pass to http.get and friends—won't work here. But here's a curious thing: the docs mention you can pass a custom Dispatcher object to tweak how fetch() behaves. Through this, you can dive deep down and configure the Client itself, even setting up the TLS client certificate for your requests.
Here's the catch though – the undici that comes bundled with Node.js is not readily accessible for us to require() and use. The undici version is statically linked with your Node.js version.
I'll need to investigate further and future proof it, as this might cause breakage with newer releases of node that would come out or just very hard to diagnose bugs. Unblocking cloudflare workers does seem like a good compromise though
Can this library be updated to use the Fetch API? Currently running into issues using this on a cloudflare workers project.
Uncaught TypeError: globalThis.XMLHttpRequest is not a constructor
node_modules/.pnpm/rollup-plugin-node-polyfills@0.2.1/node_modules/rollup-plugin-node-polyfills/polyfills/http-lib/capability.js at null. (index.js:15:56) in init
at null. (index.js:6424:5) in
node_modules/.pnpm/rollup-plugin-node-polyfills@0.2.1/node_modules/rollup-plugin-node-polyfills/polyfills/http-lib/request.js
at null. (index.js:7386:5) in node-modules-polyfills:http
at null. (index.js:15:56) in init
at null. (index.js:7507:21) in node-modules-polyfills-commonjs:http
at null. (index.js:18:50) in __require2
at null. (index.js:17037:31) in