fix(deps): Allow Node 20.9.0 and higher

[RobinTail]

This relates to...

#3880

Rationale

While dropping Node 18 support for v7, almost the entire Node 20.x support was also dropped unreasonably.
The engines should declare the minimum requirements for the environment to run the software.
It should not be the latest patch available at the moment, it should not be a favourite version of a particular individual, but a reasonable limitation based on the internal architecture and further development strategy.
Node 20.9.0 is the LTS version of 20.x and undici works perfectly fine with it, so I'm suggesting to correct the minimum supported Node version from 20.18.1 to 20.9.0.

Changes

• Allow Node.js starting from 20.9.0
• Test against that version as well

Features

None

Bug Fixes

None

Breaking Changes and Deprecations

None

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Benchmarked (optional)
• Documented
• Review ready
• In review
• Merge ready

[mcollina]

I'm not comfortable with this change, as it would consider us recommending the use a version of Node.js that is full of security issues:

➜  ~ nvm use 20.9.0
Now using node v20.9.0 (npm v10.1.0)
➜  ~ npx is-my-node-vulnerable                                                                                                                                        Need to install the following packages:
is-my-node-vulnerable@1.6.1
Ok to proceed? (y) y

                                                                                                                                                                      ██████   █████  ███    ██  ██████  ███████ ███████
██   ██ ██   ██ ████   ██ ██       ██      ██   ██
██   ██ ███████ ██ ██  ██ ██   ███ █████   ███████
██   ██ ██   ██ ██  ██ ██ ██    ██ ██      ██   ██
██████  ██   ██ ██   ████  ██████  ███████ ██   ██

                                                                                                                                                                      The current Node.js version (v20.9.0) is vulnerable to the following CVEs:

(...)

The last security release is v20.15.1. I'm ok in using that as a criteria, even if we should recommend to always use the latest version of a given LTS line.

[RobinTail]

as it would consider us recommending

@mcollina , Please don't invent nonsense when the real meaning of things is clearly documented.

[mcollina]

Stating that the module works on anything after XX means that we guarantee that it will keep working on XX, which we don't want to ensure (and that was my intention on the PR). v20.18.1 marks the point in which v20 goes in maintenance mode, and therefore the likelihood of changes are minimal.

To reiterate: the requirement is not unreasonable as stated in the OP. It was actually well reasoned, but just using criteria that are not of your liking.

Supporting old versions of Node.js is a lot of hard work, and reducing the maintenance burden is actually a priority. You can keep using undici v6 for quite a few more years, so there is no real urgency of updating.

[mcollina]

I've tried to run the undici test suite on v20.9.0 and one of the wpt fails:

================================================================================================
Started /Users/matteo/Repositories/undici/test/fixtures/wpt/mimesniff/mime-types/parsing.any.js
[1/1] FAILED - /Users/matteo/Repositories/undici/test/fixtures/wpt/mimesniff/mime-types/parsing.any.js
File timed out after 60000ms

[KhafraDev]

I've tried to run the undici test suite on v20.9.0 and one of the wpt fails:

that test should be version-independent, it's purely string parsing. I can take a look at it, because realistically it should never fail.

[metcoder95]

Unless using --engine-strict, you should still be able to use the v7 of undici in a "non-supported" version, npm does not fail unless explicitly said.

I get the point you are trying to make. On top of what was stated by @mcollina, this was set in a major version for the same reason, as it is a breaking change, the contract is always respected.

[RobinTail]

Unless using --engine-strict, you should still be able to use the v7 of undici in a "non-supported" version, npm does not fail unless explicitly said.

It's opposite for yarn. It does not allow engines violation without --ignore-engines, @metcoder95

I get the point you are trying to make

The point I'm making is that npm and yarn are specific cases of a package managers, their behaviour should not justify anything. On contrary, engines is a well documented public declaration of software compatibility that should not be misused.

[metcoder95]

It's opposite for yarn. It does not allow engines violation without --ignore-engines

Yeah, that's one of the biggest downsides when standardization has not been set.

On contrary, engines is a well documented public declaration of software compatibility that should not be misused.

See what you mean, but I wouldn't say is misused; the change was introduced as part of a semver major, meaning that the communication of a possible incompatibility problem was well stated through the use of an standardised communication (semver).

I'd say that a clear misusage would be if we added this as part of v6.x minor update, as we will be violating a communication standard previously agreed we follow.

[RobinTail]

meaning that the communication of a possible incompatibility problem was well stated

But there is no incompatibility with 20.9.0, @metcoder95 .
So the communication itself was the act of misleading.

[artur-ma]

meaning that the communication of a possible incompatibility problem was well stated

But there is no incompatibility with 20.9.0, @metcoder95 . So the communication itself was the act of misleading.

I wouldn't call this

You can specify the version of node that your stuff works on

as "clearly" documented, its more a "quick description" rather than a standard like RFC

In the "engine" section the authors put the versions they are ready to support, the fact that current version runs on version 20.9 does not mean the next minor will support it. By setting the "engine" to a specific version, you are indicating that usage on a "non-supported" version is at the user's own risk.