The commit adds undici (another Node.js project at https://github.com/nodejs/undici ) as a dependency and exposes its `fetch` - the code changes you see are probably just adding a flag :)

> I just wonder how come features like this that kind of seems obvious to include in the ecosystem takes quite some time to land?

I answered that below (check it out) but note how expensive adding a bad API is vs. asking people for one more `npm install` :) There is more discussion in https://github.com/nodejs/node/issues/19393 and in https://docs.google.com/document/d/1tn_-0S_FG_sla81wFohi8Sc8... a discussion from 2018 we had on it

Ok cool and thanks for the clarification, I imagined it was more to the topic than I realized.

Last question I have is will this be included in the next version of the LTS version or how do experimental features usually progress for someone who are unfamiliar?

Can't wait until I can use fetch in my codebase without any additional dependencies!

I had a quick look, the implementation is interesting

Node uses undici JS library. Undici includes a C HTTP parser that is used via webassembly. The parser is generated from rules that are implemented in JS/TS using llparse framework.

A native C binary there in the middle is quite surprising.

To add, unidici is an http client. Node already has http / https, but unidici is much faster and probably has other improvements, too.

They could have built a fetch interface on top of http, but they probably saw an opportunity to make more drastic improvements.

my guess is that this adds stuff to the global object which has backwards compatibility concerns.

And with every public API: Once you add it, you can't really hope to ever change it and even bug-fixes could be breaking some user's code (because they relied on the bug), so you have to be very careful to ship your public API as bug-free as possible.

Yes I could imagine and I have experience of developing apis with "bugs" that you kind of need to keep since people come to depend on it working a certain way.

But I can't help to feel like Node is progressing kind of slow compared to other languages / tools. This is just a personal impression from a bystander who is not really into the actual progression though. I have a feeling that node used to push new features all the time but in last couple of years have stagnated somewhat. Stuff like imports etc is still not really here.

I understand that developing an api that has such huge userbase as node is a massive undertaking that probably has issues that I can't imagine but it doesn't really help me in my day-to-day experience with it.

I think some of it is because Node doesn’t have very many ways to let people know about potentially breaking changes. A compiler (like Elixir) has an opportunity to communicate potential breaking changes to the user before the program actually runs, and a static type system (like Rust) makes it easy to detect such broken code and reject it outright instead of silently changing behavior. It’s harder for Node: where would the diagnostic even go? The console? Some apps use Curses, so this will break them, and many of them send their own logs through something other than the console, so nobody’s actually watching it.

Node also isn’t actually a language, so there’s a lot of stuff that Node developers get in new version, but it’s actually being done in the V8 project.

Meh, the js/ts ecosystem breaks things all the time. At least 2 weeks ago you couldn’t run typescript with ts-node, unless you explicitly enabled highly experimental loader flags.

And this is no obscure corner case, ts-node is huge

Adding 8k lines is hardly a small change.