feat: function that replaces all the objects from Node.js core with the ones from undici.

[metcoder95]

          >  it would cause very hard to debug issues

This is the reason why we didn't implement this feature.

---

How about we get the undici version number from process.versions, find out if they are compatible, and if not consider them different?

I still think we should add a undici.installGlobals() function that replaces all the objects from Node.js core with the ones from undici.

Originally posted by @mcollina in #2659 (comment)

[KhafraDev]

Rather than relying on kState, which most/all fetch classes use to some extent, we can instead add another symbol to each class that contains its type, for example: [kType] = 'Headers'. Then it should be fine to take the symbol from node classes if it exists or fallback to instanceof. AFAIK this is similar to what Deno does, and it's not vulnerable to Symbol.hasInstance shenanigans, and there's also little chance that we need to introduce a breaking change once it's implemented. We could add in a method to webidl to "brand" these classes, along the lines of:

const kType = require('./symbols')

webidl.brand = function (Clazz, name) {
  Object.defineProperty(Clazz.prototype, kType, { value: name })
}

webidl.isBranded = function (instance, name) {
  return instance?.[kType] === name
}

class Response { ... }

webidl.brand(Response, 'Response')

webidl.isBranded(new globalThis.Response(...))
webidl.isBranded(new (require('undici').Response)(...))

Alternatively, we can just provide a way of overriding the globals - maybe via a loader or manual api or both. The issue then being with interop with things in node core which relies on the bundled version of undici (such as WebAssembly.instantiateStreaming or OutgoingMessage.setHeaders).

A third option is just to document this difference, rather than attempting to implement incomplete/problematic solutions.

[KhafraDev]

How about we get the undici version number from process.versions, find out if they are compatible, and if not consider them different?

This can't lead anywhere but confusing behavior. It can also lock people into old versions of undici. But even more of a problem is that kState, as I mentioned before, can't reliably be used to detect which class it is being used in. Most properties are either optional or overlap between classes. It wouldn't be a sound change either, and addition could break it or maybe there won't be anything else to check at some point...

[metcoder95]

Like your suggestions, overall I would like to know exactly what do we want problems do we want to solve or what use cases do we want to enable; as I see it, the options we have are orthogonal.

Solving the type inference/checking SGTM to follow your suggestion of using a kType symbol, it overall will simplify a lot of things meanwhile keeping the sanity of the checks.

For undici "patching", the scope might be different, as it will enable several use cases that we might need to be aware of.
I like the idea of bringing the possibility of loading a version of undici different to the current one loaded in node. This has the potential of being really beneficial to situations where new features of undici are of desire for some users but Node hasn't cope with it yeat because of its release cycle (e.g. fetch updates, or so).

Programmatic seems like a must of enabling this, but loader can be interesting to explore.

One thing we should not do at all, is do this in auto; implementers should explicitly call whatever API we come with to patch Node's undici

[mcollina]

Solving the type inference/checking SGTM to follow your suggestion of using a kType symbol, it overall will simplify a lot of things meanwhile keeping the sanity of the checks.

That solves it for me, as long as kType is a private symbol, which would not solve the problem of using two incompatible versions of undici together.

[metcoder95]

Could this be considered close as per #4286?