Expose Undici's ProxyAgent and setGlobalDispatcher within Node

[pimterry]

Originally posted by @pimterry in #42814 (comment)

As a motivating example: I'd love to automatically support global Fetch in https://www.npmjs.com/package/global-agent (drop-in lib to make all Node HTTP use the system proxy) but even though Node bundles Undici AFAICT this isn't possible without adding a full separate Undici dep to that lib, which would more than double its size, just [EDIT: largely] to ship code that's already present in Node itself.

This would be immediately solved if ProxyAgent and setGlobalDispatcher were exposed explicitly somewhere in future.

I've just done a quick test on main in Undici: exposing ProxyAgent & setGlobalDispatcher explicitly increases the Undici bundle size from 334.2kb to 336.0kb (+1.8kb / +0.5%).

Could these APIs be included and exposed in future? Agents for HTTP are a very core API that it would be useful to have usable out of the box, the equivalent functionality is usable OOTB for the legacy http module APIs, and 2kb is not a significant jump in bundle size for this functionality.

[targos]

setGlobalDispatcher is exposed:

global[Symbol.for('undici.globalDispatcher.1')] = yourDispatcher;

[pimterry]

Replying to the last comment from @mcollina in the previous issue:

I would recommend opening up a separate issue about this topic and bringing it to the TSC. I don't think the whole of Undici has the stability guarantees needed to be part of the Node.js LTS cycle yet.

This makes sense! I'm not aware of Undici's process around stability guarantees like this, but I can understand how there are constraints there.

I do understand this isn't a top top priority since installing & importing Undici elsewhere is a usable workaround, so there's certainly no rush just would justify shipping an unstable API unnecessarily. I do think that the current situation isn't a good end state though, and there are good options we can aim for to fix this, so it would be great to find agreement to aim in that direction in the medium term.

I'm not sure how to take anything to the TSC, but very happy to be included on any discussion of this any time.

[pimterry]

global[Symbol.for('undici.globalDispatcher.1')] = yourDispatcher;

That's does work as a workaround, but it's not especially nice as the official API for this, and I think ProxyAgent needs to be available too to make this usable for global Fetch.

[mcollina]

I don't think we should expose undici further until we want to consider fetch as stable.

[frank-dspeed]

which part of the fetch spec is unstable or problematic i do not get it fetch is the same as XMLHTTPRequests but async
so it is equal to the https http and so on request methods/get

and i found zero parts of the spec in fetch that could harm nodejs

so my question what is blocking why not adopting it? The cache can be in memfs or even turned off by design or not implemented but what else could be blocking?

is it about context related policy header handling?

[mcollina]

@frank-dspeed I don't understand how this comment is relevant to this issue. We shipped fetch() in Node v18 unflagged. How are we not adopting it?

Node.js fetch() is not stable yet because

1. it misses features
2. there are incompatibilities between Browser envs and Server envs that needs to be sorted (spec deviations)
3. there are plenty of bugs still

We still need time to figure out all those details before calling it stable and then having to do breaking changes to correct mistakes.

Anyhow, I think this discussion is out of topic. I'll hide both of our comments - this issue is about a specific detail of the implementation, not fetch in Node.js.

[sosoba]

@mcollina
I don't think we should expose undici further until we want to consider fetch as stable.

2022-11-14, Version 19.1.0

• drop fetch experimental warning (Matteo Collina) lib: drop fetch experimental warning #45287

[mcollina]

That does not mark it stable, on purpose. It's the first step on that journey. This is something we might want to consider right now.