Discussion: Using engines in the package.json

[UlisesGascon]

Currently some packages has drop support to Node.js prior to v18, seems like we didn't upgrade the engines field in the package.json discordantly.

So, I will like to discuss if this a policy that we should follow as an organization to all the packages (so in that case we can also document it).

⚠️ So far seems like Express actually updated the package (ref) but not in others like finalhandler (ref)

Ref:

• Missing engines Field Update for Node.js Version Support in v2.0.0 pillarjs/finalhandler#64
• fix(package.json) Explicit drop support for node<18 pillarjs/finalhandler#59 (great context on why not update by @wesleytodd )

cc: @expressjs/express-tc @Phillip9587

[UlisesGascon]

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)

[ctcpip]

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

[Phillip9587]

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!

[ljharb]

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)

[inigomarquinez]

I completely agree with the proposal!

[bjohansebas]

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

[UlisesGascon]

Proposal for adr created #289