Add policy to align engines fields with ci

[UlisesGascon]

• closes: Discussion: Using engines in the package.json #286
• related: Re-thinking the discussion process #285

[rxmarbles]

LGTM

[ctcpip]

we need a note in here about the possibility of continuing to run CI in older unsupported node versions so we know if/when a change clearly breaks back-compat. (we do this for express itself, for example)

I'll try to come up with good wording for this

[UlisesGascon]

ping @ctcpip

[wesleytodd]

While I have general concerns about the decision here, I would much prefer this decision over the current state. The only thing I think is missing is the call-out that all more restrictive engines changes can only land with a MAJOR. And that we agreed major versions should not be cut just to change node support.

This means that this policy will take a while to roll out. I do not consider this blocking to merge this ADR, but I think it is something we had agreed on in a few discussions so just wanted to call it out since I didn't see it mentioned in the text of the ADR.

[voxpelli]

I think the pragmatic thing is to see the "engines" as a best effort description at describing the intended compatibility of the code at the point of release.

If the description is out of sync with reality then either reality has to adapt to the description or the other way around.

If the change of the "engines" range can be seen as a bug fix – reality was clearly different to it – then I think it's correct to fix, else I think a new major or a widened reality is needed.

Bug fixes are always breaking for those reliant on the bugged behavior and it's always a balance of factors where it's primarily a fix or a breaking change.

[ljharb]

Removing engines entirely would be explicitly declaring that you support * (the documented default), so I'm not sure why that'd be desirable, but certainly that's not a breaking change.

[blakeembrey]

I'm not sure why that'd be desirable, but certainly that's not a breaking change.

It’s not, but it’s less desirable to try and release new major versions to fix the supported version range.

@voxpelli I agree, it’s the main point of contention. We need to document this somewhere.

[jonchurch]

Notes for me summarizing while ulises talks about this bc it has been so long and I have to do this everytime:

We have engines field in our packages. We have a challenge w/ engines, the problem is if we forget to update the engines field (this has happened, I jon have done this), do we do a new major to fix the engines field? That was an open question, which has ended up being discussed in this ADR as well.

Its turned into a discussion into whether or not adding/fixing engines is always a major.

Im taking an action item to work with Ulises to caught back up on this and get a clear next step.

[ctcpip]

relevant: jshttp/mime-types#136

[ljharb]

Fixing engines is not a major if the implementation was already incompatible with the engines being excluded.

If that's the case, it's a patch! If that's not the case, then I'd suggest reconsidering changing engines in the first place :-)