IMO, we should align the engines to the CI versions we test for each release branch. Otherwise, we risk introducing breaking changes without realizing it.

If the package happens to work in older versions of Node.js that we haven't explicitly defined as supported, it should be considered an "unsupported feature." We should encourage end users to use at least the minimum supported version for that release branch. Otherwise, we'll end up "supporting" unintended scenarios based on environments we don't explicitly endorse, leading to issues like unexpected bug reports and slower development due to legacy version compatibility problems.

Additionally, npm is clear in its documentation: unless the user has set the engine-strict config flag, the engines field is advisory only and will simply produce warnings when your package is installed as a dependency. This reinforces the need to clearly define supported versions, ensuring that users are aware of the minimum requirements. (documentation)

agree, engines should be added where missing, and should match our CI matrix

I completely agree with the proposed solution to establish a consistent policy for updating the engines field across all packages. Ensuring that the Node.js version support is clearly defined and aligned accross the packages makes sense from a maintenance and user experience perspective.

I’m happy to contribute and help move this forward by submitting the necessary PRs to update the relevant packages. Let me know how best to coordinate on this!

100% that CI should match whatever engines says.

(Changing engines in a way that reduces support is a breaking change, even if the software didn't work on the removed envs, ftr)

I completely agree with the proposal!

I totally agree on keeping the CI in line with what the engines say

Proposal for adr created #289

responding to another issue here to keep the conversation centraliized

per what the TC agreed via consensus, "there should not be a major version rev JUST for an engines change".

However, we did not specifically decide anything with regard to this situation which is that we DID drop support, we just forgot to update the engines field. Though there haven't been a lot of cases of it, in practice, we've just updated the engines field without revving major.

I am sympathetic to the view that dropping engines when it would otherwise work with strict engine configurations may be a breaking change. Not one that I consider to be completely unacceptable, but alas...

Ultimately, due to how much of a minor/non-issue it is to leave the engines field alone in these cases, this seems like an easy decision:

• If a package is completely broken in the older node version(s), then updating engines itself is not a further breaking change -- and therefore acceptable.
• If a package still works to some extent in the older node version(s) then engines updates need a semver major.

I agree with that rubric, although because things can fail to install successfully with an engines change, there might be nonzero breakage that way.

Do you mean like, in the case where it's e.g. an unused transitive dependency? So that the fact the library doesn't work at all doesn't matter, thus the breakage via engines is the sole breakage?

no, i mean that even if it breaks at runtime in, say, node 16, if it's used inside a try/catch, then a package can still support node 16 with it - but if it adds an engines field that requires 18+, then that's a breaking change for that package and its users.

In other words, you can't ever assume that the engines field is "free" to bump, there's always risk of breakage. which is why it's critically important to always declare it, and when dropping support in a major, always bump it with the major.

sure I agree -- but I think the consideration is unchanged. it hinges on the definition of what makes a package "completely broken". I am thinking like, new node module resolution fails, so you can't even run the thing. if I can still pull in a lib as transitive, then it's not "completely broken"

Regardless, I think, in practice, we will just default to not changing in a minor in any case, because it's really low/no value to try to work out whether the change will be breaking or not given these nuances. and like.. who benefits from doing it anyway?

Exactly, I agree.

We need to make a decision on this: pillarjs/finalhandler#59

Do we merge and release as a minor? Close it? Release a major?

I am preparing the list of releases we need to do for the next express version and this one has changes to publish.

Based on what we agreed, it goes in the next major, but we don't release a major only for an engines field update. So if something else is going out, then sure, but if not, it waits until the next major with actual lib changes.

Ok, cool I should have specified in my options two for "release major now" vs "release major later". In this case we have removed a bunch of old compat things in accordance with our stated support for v18 which makes the current engines invalid. So I think this means we are good to release a new major now and call the 2.x line an administrative bump in the road right?

hmm.. looking at the changes, this appears to be a no-op for end users. seems odd to do a major rev at this point, but whatever works!

Yes, this is why I thought it was worth a bit more consideration, but we did drop deps for compat which is a meaningful change.