-
Notifications
You must be signed in to change notification settings - Fork 565
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(deps): Allow Node 20.9.0 and higher #3918
base: main
Are you sure you want to change the base?
Conversation
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:
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. |
@mcollina , Please don't invent nonsense when the real meaning of things is clearly documented. |
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. |
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. |
Unless using I get the point you are trying to make. On top of what was stated by @mcollina, this was set in a |
It's opposite for
The point I'm making is that |
Yeah, that's one of the biggest downsides when standardization has not been set.
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 |
But there is no incompatibility with 20.9.0, @metcoder95 . |
I wouldn't call this
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. |
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
Features
None
Bug Fixes
None
Breaking Changes and Deprecations
None
Status