Is there a reason why Node.js doesn't expose the undici module?

[brettwillis]

Considering that for fine-tuned use of built-in fetch() (aka. undici) we need to use dispatchers etc, is there a reason why Node.js doesn't re-export the built-in undici module?

If we want to use those features such as dispatchers, we need to install our own (duplicate) undici dependency, which is a bit of a shame given that it is already built in to Node.js. Also, conceivably, our userland-installed dependency may not be compatible with the built in one.

[metcoder95]

TL;DR: The release schedule is not compatible between projects.

The biggest issue with doing that is the release cadence of Node.js compared to a common userland library like undici; usually new features within undici are released in a faster manner compared to Node.js release schedule, which can harm the adoption of features that are important or can be of help to users.

Take the H2 support as an example, you could already use it in fetch by installing undici newest version and setting the global dispatcher with allowH2: true, that subsequent bugfixes were applied. The current release design allows you to use those fixes, but if h2 was stable and depending on the Node.js release cycle, it would take time for the changes to reach fetch.

[brettwillis]

Good evening @metcoder95 ok let me see if I understand correctly. You're saying that because undici is not public Node.js API, that allows Node.js to adopt undici fixes and updates faster, whereas if it was public API then Node.js would have to adopt undici fixes on a slower schedule? That sounds like something that would be resolved by backporting "patch" updates to older versions of undici (but I know that's a lot more work).

The different release schedule is part of the point that I'm making: undici's fetch() implementation has dispatchers as part of it's API, however we cannot ever use dispatchers with the built-in fetch() implementation, because it does not expose the dispatcher implementations. As soon as we install userland undici to get the dispatcher implementations, it may not be compatible with the embedded version of undici which is on a different release schedule, and therefore we must drop the built-in fetch() completely and just entirely use the userland version. I.e. we should not mix userland implementations with the embedded implementation.

I guess the consequence is that the dispatcher API on built-in fetch() is not public API and should not be used?

usually new features within undici are released in a faster manner compared to Node.js release schedule

Having Node.js expose those dispatcher implementations (or just the whole embdedded undici) does not stop people installing a userland copy anyway if they want to access new features ahead of the Node.js release cycle?

[ronag]

TBH. I don't see any reason to include it. Just install undici and always get the latest version.

[KhafraDev]

there was a suggestion to expose it a while ago and was criticized pretty heavily

[metcoder95]

(but I know that's a lot more work).

Basically this haha

The different release schedule is part of the point that I'm making: undici's fetch() implementation has dispatchers as part of it's API, however we cannot ever use dispatchers with the built-in fetch() implementation, because it does not expose the dispatcher implementations. As soon as we install userland undici to get the dispatcher implementations, it may not be compatible with the embedded version of undici which is on a different release schedule, and therefore we must drop the built-in fetch() completely and just entirely use the userland version. I.e. we should not mix userland implementations with the embedded implementation.

Although I partially agree; undici handles the dispatcher API and version pretty carefully, any change on those contracts will result in a major bump that will might require some planning (just daydreaming here). And given that undici moves faster in its schedule, it often results in better stability just installing undici and using it, compared to exposing it and waiting for the next Node.js release to have a e.g. CVE fix.

[brettwillis]

Ok thanks all, I appreciate the insights, while I still think it's a shame not to be able to use the power already embedded in Node.js without installing duplicate dependencies, at least now I know it has already been considered by people a lot smarter than myself 😉