Add note about using EOL release versions

[isaacs]

Enter your suggestions in details:

I can't send a PR, because GitHub thinks I already have a fork. (Perhaps this was originally mine from back in the day? I'm not sure.)

Here's the patch, which can be landed with git am: https://gist.github.com/isaacs/47ced4e0fa13469b847dbfa19bd376a4

From 9a03c3e2d958202a0d1b9477a25406b5bd904a30 Mon Sep 17 00:00:00 2001
From: isaacs <[email protected]>
Date: Mon, 8 Jul 2024 10:44:26 -0700
Subject: [PATCH] Add note about using EOL release versions

As much as we can recommend against this, people are still going to do it
sometimes. We may as well help users reduce the risk and also give package
authors something to point to when the predictable breakage occurs.
---
 apps/site/pages/en/about/previous-releases.mdx | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/apps/site/pages/en/about/previous-releases.mdx b/apps/site/pages/en/about/previous-releases.mdx
index 3e0014c6..7e621696 100644
--- a/apps/site/pages/en/about/previous-releases.mdx
+++ b/apps/site/pages/en/about/previous-releases.mdx
@@ -10,6 +10,15 @@ After six months, odd-numbered releases (9, 11, etc.) become unsupported, and ev
 _LTS_ release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months.
 Production applications should only use _Active LTS_ or _Maintenance LTS_ releases.
 
+## Costs and Caveats of Using Unsupported Releases
+
+In some cases, it may not be possible to upgrade a legacy application to use a supported Node.js version. While this is not recommended due to the lack of security updates, at a bare minimum the following precautions must be taken when using an <abbr title="End of Life">EOL</abbr> release:
+
+- Pin or vendor all external dependencies. That is, instead of depending on `"some-package": "^1.2.3"`, depend on `"some-package": "1.2.3"`, without the `~` or `^` character. Or, copy the dependency locally into your project, or check the `node_modules` folder into source control.
+- Carefully evaluate any dependency updates, as they may not be compatible with EOL platform versions, even within `patch` version updates, as the community gradually drops the EOL version from their CI testing environments.
+- Do not rely on being able to run the latest version of a script using `npx`, `pnpmx`, or similar.
+- Take extra care to ensure that your application is not exposed to untrusted user input, as this can expose you to known security exploits which _will not be fixed_ on EOL versions.
+
 ## Release Schedule
 
 ![Releases](https://raw.githubusercontent.com/nodejs/Release/main/schedule.svg?sanitize=true)
-- 
2.39.3 (Apple Git-146)

[isaacs]

This could also help conscientious maintenance engineers make the case to their managers that they need to invest the time to upgrade to a new node version, or at least to do the work required to stay protected if they're not going to.

[mcollina]

I’m personally not in agreement with pinning version as a strategy because users would still be exposed to nested dependency changes.

In fact, the only solution is for maintainers to bump the major when dropping a supported engine.

[isaacs]

I’m personally not in agreement with pinning version as a strategy because users would still be exposed to nested dependency changes.

This is incorrect. It does protect against nested dependency changes, because npm prioritizes selecting versions that do not have an engines mismatch. The only case where it would be a problem is if a transitive dependency restricts its engines, but the direct dependency does not, then the direct dep starts requiring the new transitive dep, and you install the new version of the direct dependency. But if you're not updating anything (because you're pinning deps) then this can't happen.

For library authors, you can solve the problem by setting node-version in the project's .npmrc file, so that you'll be restricted to only selecting matching versions and get warned when the condition is violated (you can also use engines-strict=true to make that a crash instead of a warning), regardless of what node version you're actually using. But this is not necessary for production applications, which is the context of the added note here. Perhaps it could be expanded to provide guidance to library authors who wish to safely (or at least, less unsafely) maintain support for EOL versions?

[isaacs]

This is incorrect. It does protect against nested dependency changes, because npm prioritizes selecting versions that do not have an engines mismatch.

Welp, apparently I'm wrong about that. It's not properly prioritizing engine matches over mismatches when it should result in a lower version number being selected.

That's confusing, because the code has been there for a long time to do this, but apparently it's busted or being overridden or something.

[ljharb]

Indeed, if npm worked that way, then dropping engine support wouldn't be a semver-major.

[isaacs]

Ah, it's this bug, that I tried to fix 3 years ago: npm/npm-pick-manifest#33

[ovflowd]

@isaacs should we still make a PR to apply the patch from the opening post? Sorry I didn't get if the comments here resolved the initial concerns or not 🤔

[isaacs]

@ovflowd Because of the npm-pick-manifest issue I linked to, the advice is not as complete as I'd thought. Ie, when I told @mcollina he was incorrect, I was in fact the incorrect one. (I was correct about the intended design of the code in question, but it has a bug that has not been fixed.) It is still enough for app devs to lock down or vendor their dependencies, assuming they're very careful about all updates from that point forward, but it's not as trivial as it should be to avoid engine mismatches.

If someone wants to open a PR with the patch I presented here, that's of course fine with me.

[aduh95]

Wouldn't using a lockfile be a better strategy than pinning deps? I doesn't help libraries, but the patch clearly mentions "application".

[mcollina]

I think this can be closed.