fix(package.json) Explicit drop support for node<18

[mureinik]

Followup to #54:
That PR added a statement that support for node<18 is dropped, and amended the CI accordingly.

This PR builds on that and makes this support statement explicit in the package.json.

[wesleytodd]

I knew someone would see this and open this PR. I did this intentionally. We are in a process of fixing nearly 10 years of stagnation and are attempting to make the most smooth transition we can for consumers. Since we did not introduce any changes that actually BREAK those versions I have chosen to not change the engines field. This means that we are a bit more free to steward folks forward without putting in arbitrarily roadblocks in the upgrade path.

That said, we do not intend to ship fixes for anything other that security issues to support node versions older than 18. We are working on docs and stuff for this, but it takes time and we are focused on getting the code released and stable first. So, happy to hear your opinion on this, because I anticipated it being controversial.

[mureinik]

Egg on my face!

I was not aware this was intentional - #54 didn't mention it, and I thought it was just an oversight.
Apologies for the noise.

[wesleytodd]

No apologies necessary! I was quite concerned this decision would be seen as the wrong way and I didn't want to cause more confusion by trying to preemptively explain my thinking in case it was never going to become an issue for folks. In open source it is sometimes hard to tell what folks will care about and what they will not even notice, and with the workload we have taken on trying to get these packages unstuck, I was trying to optimize for maintainer time over correctness.

[wesleytodd]

We merged this change in at least one other package. While this is considered a breaking change in the strictly technical sense, I think we may merge it since it is in line with the support policy we are taking and will be publishing other packages with this change. I will leave this comment here for a bit to see if anyone wants to block this from moving forward. If not, we can merge and release.

[ljharb]

As long as it's semver-major, it's fine :-) this isn't just in the technical sense, it will actually break things in a real sense, since many setups do check the engines field.

[wesleytodd]

This was my original argument, but I didn't want to stand in the way of progress and a few other packages (I can get links) did merge this change with the intent to release as a minor. I can't remember off hand if any of those have been released yet, but we have not had anyone willing to take a strong stance against releasing them.

To be clear, I believe we would be better off removing the engines fields from all packages except express and just documenting well the minimum supported version. That is not because I think it is the most technically correct, it is because I think it causes the least harm to users and maintainers. That said, in the discussion I was really the only person in favor of that path IIRC so I didn't fight it.

[ljharb]

I definitely disagree; keeping both the engines field and semver accurate is what does the least harm. What's the issue with a major bump of this package?

[wesleytodd]

Not a whole lot of resistance to that idea, it was just not mentioned here before. I believe it was @ctcpip who was the strongest proponent of just releasing these as minors (correct me if I am wrong on that Chris).

[ljharb]

Whenever someone does that, it breaks me, fwiw - I'd strongly urge you to either fully drop compat (including engines, in a semver-major) or not drop compat. Nobody wants semver z̲̗̼͙̥͚͛͑̏a̦̟̳͋̄̅ͬ̌͒͟ļ̟̉͌ͪ͌̃̚g͔͇̯̜ͬ̒́o̢̹ͧͥͪͬ

[ctcpip]

please see: expressjs/discussions#286 (comment)

[Phillip9587]

Closed by #119