EFI: Deprecate Node.js

[sheplu]

Motivation

Express was one of (if not the first) framework built on top of Node.js. As of today, the v4 support Node.js from 0.10 (released more than 10y ago) to v20. This is a huge number of version, with the majority of them not being maintained and that should not be used.
Keeping the support on future major version is a lot of work, and by the size of express Node.js still have some code used to keep express compatibility - which can add maintenance burden and have a performance cost

Expectation

Define a rule about supporting version on Node.js
Advocate for LTS versions of the framework

Implementation

Status

Part: Technical

Draft

Some code parts of Node.js are still existing just to support Express. This is causing some performance and maintainability issues.
The Express TC should work with the Node.js team to figure out what needs to be deprecated. To have and accelerated timeline, we could deprecate all functions of Node.js core and remove them slowly, allowing us to bypass the “2 versions deprecation rule”

[UlisesGascon]

As far I know the current schedule is:

• Express@4 is supporting Node@0.10.0
• Express@5 is supporting Node@4.0.0

IMO, I strongly believe that we want to keep Express@4 and Express@5 as they are. But for the next versions we can have a different rules. I think that we can start our next major version providing support to the existing Node.js release schedule at that time.

So, if we start to work on Express@6 today, our minimum Node.js version supported will be the maintenance version (v18 end of life at 2025-04-30), but we can just start by the Active LTS version (v20 maintenance start on 2025-10-21). Obviously Express@6 will remind being updated against the newest versions of Node.js, until we move ahead with Express@7.

This way we still covering all the spectrum of Node.js over the years and we can refresh our code base more easily.

I was not aware of the "2 versions deprecation rule", but happy to learn more about it :)

[wesleytodd]

We have too many related issues open right now. I think we should consolidate these conversations before moving forward so we don't make it way more confusing than necessary. Can we close these and make one called LTS Strategy (as mentioned in #184)?

[sheplu]

if I am not mistaken, on Node.js if you want to deprecate something you would have to

• in the next major version, flag the feature as "deprecated"
• only in the next (so next next) version, you can remove it

[ljharb]

most projects don’t follow that pattern tho - in most cases, something is deprecated within the major line, and removed the next major.

That said, deprecation usually related to features, not platform support.

[rafaell-lycan]

QQ: Do we have a way to extract the Node version from NPM for the current weeks?

Node 4 is a valid choice but it wouldn't bring the same ES2015 capabilities as Node 6 which would unlock potential for a better codebase. Node 8 would be ideal IMO, especially if Express@5 will be around for a while before a new major bump.

[ljharb]

With a build process, the node version can be completely separate from what features you want to use.

[wesleytodd]

QQ: Do we have a way to extract the Node version from NPM for the current weeks?

I believe @sheplu approached npm about this and we couldn't get that. That said, we made a decision on a recent working session meeting. I believe we should close this issue in favor of the PR is either @kibertoad porting his original doc over into the admin repo and updating that or updating this one.

With a build process, the node version can be completely separate from what features you want to use.

Very true! That said we don't intent to add a build process to anything that doesn't already have it AFAIK. And I think for v5 we didn't plan on majorly changing anything to break compat other than landing an updated path-to-regexp in the router. So it is no longer about which features we will gain, we came to a consensus and are going to stick to it.