undici
undici copied to clipboard
nodejs
v7
- llhttp (@metcoder95 merges next branch) - https://github.com/nodejs/undici/pull/3388
- remove deprecated interceptor api (@metcoder95 merges next branch) #3399
- dispatcher API issues (@mcollina, @ronag, @metcoder95 )
- fetch stuff
- remove polyfills (@KhafraDev has already prepared PRs)
- add alternative to onHeaders with pre-parsed headers (@ronag )
- diagnostics channels (@mcollina )
We start with merging the next branch into main (@metcoder95) and then start working actively on v7 with a deadline relative to Node v23.
Shall we consider the exposure of the lenient flags from lhttp as part of this?
Shall we consider the exposure of the lenient flags from lhttp as part of this?
Yes, I think so.
- diagnostics channels
is this something we're absolutely landing?
Also hopefully https://github.com/nodejs/undici/pull/2727 is included in the fetch stuff, it's slightly older so I'm hoping it won't get missed.
How can i support?
Would you like to support adding the lenient flags for llhttp @Uzlopak?
I was kicking off the work for the lenient flags, but I just noticed that most of them as marked as opening a security vector if enabled; do we want to enable that within undici?
By default they are disabled sure, but do we want to expose the users to that possibility? I'd consider to not do so, cannot imagine under which circumstances (beyond legacy servers) you might want to enable this
Interceptors hasn't been dropped, but rather refactored into a new API. Check: https://undici.nodejs.org/#/docs/api/Dispatcher?id=dispatchercomposeinterceptors-interceptor
That's done.
On a different topic, I think we might want to release v7 before Node.js v23, to be included there.
Backported some of the work done for interceptors and smaller fixes at core.
Do we want to make v7 before v23 is cut? https://github.com/nodejs/Release/issues/1034
Not right now. However, if we miss the deadline for Node.js v23 (seems likely), we will definitely be dropping it, as Node.js v18 goes EOL April 2025.
@trivikr are you arguing we should drop support for Node.js v18 or not? So far it's in and it's not causing many issues.
I've discussed with @ronag in person how we can handle multiple dispatcher versions (even in minor releases). So those are actually not hard requirements.
are you arguing we should drop support for Node.js v18 or not?
Looking at the history of major version releases of undici and end-of-life of Node.js runtimes, it looks like undici@v7 should drop support for Node.js 18.x
| undici version, and release date | Min Node.js version, and end-of-life | support for EoL Node.js version |
|---|---|---|
| v4, 2021-06-21 | >=12.18, 2022-04-30 | N/A. Next version released before EoL |
| v5, 2022-03-29 | >=12.18, 2022-04-30 | 1.5+ years |
| v6, 2023-12-05 | >=18.0, 2025-04-30 | N/A. Next version released before EoL |
| v7, 2024-11-27 |
Assuming v8 of undici is released in December 2025, we can think of two options for min Node.js version support.
| undici version, and release date | Min Node.js version, and end-of-life | support for EoL Node.js version |
|---|---|---|
| v7, 2024-11-27 | >=18.0, 2025-04-30 | 6+ months. |
| v7, 2024-11-27 | >=20.0, 2026-04-30 | N/A. Next version released before EoL |
Undici can use this data to drop support for Node.js 18.x, and push undici users to upgrade. If undici plans to come up with a major release schedule in future - it can be aligned with Node.js LTS EoL (say Q2/Q3 of each year?)
Bumping for decision on supported version of Node.js.
The https://github.com/nodejs/undici/releases/tag/v7.0.0-alpha.7 was released today, and stable version is expected to be released in two days.
I have yet to see justification for dropping v18. What benefit is there in dropping it?
As time will pass, it would be harder for us to maintain it. Right now, this means using tspl instead of t.plan() for our tests, but the list can grown.
If undici plans to come up with a major release schedule in future - it can be aligned with Node.js LTS EoL (say Q2/Q3 of each year?)
Should I create a new feature request for this, if maintainers are interested in coming up with a schedule? It can start with April 2026.
Looking at the past releases, it does not look like undici needs a release schedule. But it might need in future, if undici.request is made available in Node.js just like undici.fetch
But it might need in future, if undici.request is made available in Node.js just like undici.fetch
Overall, the dispatcher versions can vary and maybe bring some troubles; not 100% sure if we need a release schedule for that, but good to keep in mind