-
Notifications
You must be signed in to change notification settings - Fork 15
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
Discussion: Using engines in the package.json #286
Comments
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 |
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 |
TC agreed today:
This is my understanding from today's discussion; others please correct anything if I've gotten it wrong. |
EDIT: I can ask this in slack or find it myself.
Did y'all see that post from the fastify folks about this? They had removed it because of the pain it caused. I think we can avoid that as long as we really pick the absolute minimum we support in the major line and dont change it at all for the entire major. But just wanted to call it out in case y'all hand't seen it (
I am 👍 on this. |
It's also worth running tests in both "first" and "latest" of a line - iow, if you support |
I might have missed it in here, but as we had folks start opening PRs for this in the code and learn yesterday I realized that it wasn't clearly called out that changing the engines field is considered a breaking change. And while we changed it in |
It is here: #289. I think the major point of the ADR is that the CI should match the engines, and we should include engines where is missing. So, if we decide to drop support in the CI, it then affects the engines... so that is a major. Adding an That said, I agree that simply bumping Node.js for the sake of bumping Node does not justify a major change, but this might be something to cover in a different ADR related to "when to do a major?" :) |
@UlisesGascon unfortunately adding an |
@ljharb I’ve noticed that many packages list in their |
@Phillip9587 Its almost a philosophical question – it’s like bug fixes that are breaking changes but are breaking changes that restore the intended functionality. In the strict way of interpretations they need to be major releases, but some common sense is needed To me it would make sense to release it as patch – it would be the most correct from the perspective of this at its core being a “bug fix” – ensuring the range is updated in all places. I believe that @ljharb follows a stricter interpretation than me, and that’s fine, ultimately you need to decide with what you think is the most correct according to SemVer – whether you consider it a bug fix or a new breaking change. |
@Phillip9587 again, yes - adding engines is only nonbreaking if every engine on which it already works is included in the range. Indeed “works” can be vague/gray, but despite the impossibility of describing a rubric, I’ve almost never found it a difficult decision to make ad hoc. |
@ljharb It will only break when strict engine checks are used and only when installed on engine versions that might anyhow no longer be compatible with the code. The older engine versions are only safe if the support is rolled back to that of the engine declaration, the current major is marked as deprecated, encouraging them to downgrade or upgrade to a new major with correct claims or the current major gets patched (and the previous releases of it possibly deprecated) I typically think this should be a major, but in this case I think it’s to be seen as a bug that people upgrading should have already adapted to |
Many tools check the engines field, and nonzero breakage is breakage, full stop. I agree that whatever it worked on is what should end up in engines and CI, and then to reduce that, a major bump should occur. Obviously it’s fine to skip the “fix engines/ci to match reality” step as long as engines isn’t released in a non-major. |
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).
Ref:
cc: @expressjs/express-tc @Phillip9587
The text was updated successfully, but these errors were encountered: