You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Good conversation to have! Please don't take this response as a rebuttal, but as the start of a conversation and me thinking out loud.
The methods package essentially is just that snippet, and has zero dependencies of its own. (Although it might be worth revisiting, I don't fully understand the value of the fallback behavior defined in the package for Node versions that don't have http.METHODS).
It exists so that anyone in the ecosystem can use that same standard helper without having to keep that utility code in their own codebase. Having it as a package is essentially the same as if we had that same snippet of code in a utils folder, guarantees that any changes that ever need to happen to it will be synced across every package that uses it. Express maintains that package, as the jshttp org is under the Express project umbrella. For context on a similar choice to use a package vs a oneliner, see this exchange between @dougwilson and I where I learned a little about our choice on these things. Also, in v5 router is being moved into it's own package, which is the system in Express that uses methods the most. Having it as a package ensures that both router, the express tests, and the application system are all using the exact same snippet at all times.
I can't find where path-is-absolute is used in Express, so I don't have anything to say about that, but if it is being used I would agree that's a simple one to replace since it's introduction in Node v0.11.2 👍
safe-buffer can be dropped once Express' lower bound of support is at Node.js v6, I'm still not 100% sure what version v5 will support down to, but that is a good candidate as well once we are there.
Object.setPrototypeOf came to Node in v6.0.0, so again, that can probably be used once version support comes that high.
The spread ... operator came in at Node.js v8.0.0, so same story as the other version support 👍
I'm not sure if my comment is being misread here, but it is that we will support down to the LTS at the time, not that we won't support more than that. There has been further discussion since that thread, including in TC meetings, which is what @jonchurch is trying to represent. The version of support we are always aim for is as wide as possible, but there is a balance. Dropping versions for us is more about what we get for it, unrelated to what is supported by the Node.js project. But we will always support at least down to the current LTS version, no exceptions.
No problem. Also (sorry!) to clarify: it doesn't mean this discussion is over at all; just it will help us to have discussions like this where we specify what the change in Node.js requirement will be for each one (like @jonchurch listed) so we can make decisions on what to do, etc.
@mohabdelkarim I will note "just sharing" is more than zero cost when it is not useful. Consider this is an issue closed 2 years ago as a planning issue for a release that happened in September 2024 - in an issue like this, you have just pinged 9 people with a thing "in case it's useful" (it is not). This has negative, not zero, value.
As another random vaguely in the community I'd like to ask you or your agents to think and read more before "sharing in case it is useful".
Activity
jonchurch commentedon May 16, 2020
Good conversation to have! Please don't take this response as a rebuttal, but as the start of a conversation and me thinking out loud.
The
methodspackage essentially is just that snippet, and has zero dependencies of its own. (Although it might be worth revisiting, I don't fully understand the value of the fallback behavior defined in the package for Node versions that don't havehttp.METHODS).It exists so that anyone in the ecosystem can use that same standard helper without having to keep that utility code in their own codebase. Having it as a package is essentially the same as if we had that same snippet of code in a utils folder, guarantees that any changes that ever need to happen to it will be synced across every package that uses it. Express maintains that package, as the
jshttporg is under the Express project umbrella. For context on a similar choice to use a package vs a oneliner, see this exchange between @dougwilson and I where I learned a little about our choice on these things. Also, in v5routeris being moved into it's own package, which is the system in Express that usesmethodsthe most. Having it as a package ensures that bothrouter, the express tests, and theapplicationsystem are all using the exact same snippet at all times.I can't find where
path-is-absoluteis used in Express, so I don't have anything to say about that, but if it is being used I would agree that's a simple one to replace since it's introduction in Node v0.11.2 👍safe-buffercan be dropped once Express' lower bound of support is at Node.js v6, I'm still not 100% sure what version v5 will support down to, but that is a good candidate as well once we are there.Object.setPrototypeOfcame to Node in v6.0.0, so again, that can probably be used once version support comes that high.The spread
...operator came in at Node.js v8.0.0, so same story as the other version support 👍xuxucode commentedon May 17, 2020
See #2755 (comment) for the 5.0 version support:

dougwilson commentedon May 17, 2020
I'm not sure if my comment is being misread here, but it is that we will support down to the LTS at the time, not that we won't support more than that. There has been further discussion since that thread, including in TC meetings, which is what @jonchurch is trying to represent. The version of support we are always aim for is as wide as possible, but there is a balance. Dropping versions for us is more about what we get for it, unrelated to what is supported by the Node.js project. But we will always support at least down to the current LTS version, no exceptions.
xuxucode commentedon May 18, 2020
Got it, I misunderstood it before, I thought we just need to support LTS at that time.
dougwilson commentedon May 18, 2020
No problem. Also (sorry!) to clarify: it doesn't mean this discussion is over at all; just it will help us to have discussions like this where we specify what the change in Node.js requirement will be for each one (like @jonchurch listed) so we can make decisions on what to do, etc.
dougwilson commentedon May 26, 2020
mgoffan commentedon May 26, 2020
@dougwilson Thanks for the clarification. Just noticed it was here #4171 🙂
dougwilson commentedon Jun 3, 2021
kisaragi-hiu commentedon Sep 23, 2023
setprototypeof: Object.setPrototypeOf (Node 0.11+, )MDN says setPrototypeOf was added in Node 0.12, and a quick check with nvm shows that this is indeed true (absent in 0.10, present in 0.11 and 0.12+); not Node 6.
So the ponyfill is needed in Express 4 as it supports Node 0.10+, but as 5.0.0beta1 already bumped the minimum Node version to 4, it no longer will be.
array-flatten: Array.prototype.flat (Node 11+, 2018)If the plan is still for Express 5 to only raise the minimum Node version to 4, this would still be necessary.
Spread syntax is Node 5 (2015), Object Spread is Node 8.3 (2017)
jonkoops commentedon Dec 2, 2024
PR to remove
utils-mergefrom the dependencies is up under #6194wesleytodd commentedon Jan 11, 2025
Going to close this as we have ongoing PRs for most of this and we don't really need a tracking issue for those.
mohabdelkarim commentedon Aug 19, 2026
Hey, I dug back into this idea and wrote up a short note here: analysis.
Express 5.0 will eliminate legacy dependencies by leveraging built‑in Node.js APIs.
Node.js 14 LTS unified core APIs enable removal of external packages in Express5.
There's also a small
typescriptsketch in the write-up (rough, not a real patch).Rough effort guess from the write-up: about 32 hours. Not affiliated with this project, just sharing in case it's useful.
kisaragi-hiu commentedon Aug 19, 2026
@mohabdelkarim I will note "just sharing" is more than zero cost when it is not useful. Consider this is an issue closed 2 years ago as a planning issue for a release that happened in September 2024 - in an issue like this, you have just pinged 9 people with a thing "in case it's useful" (it is not). This has negative, not zero, value.
As another random vaguely in the community I'd like to ask you or your agents to think and read more before "sharing in case it is useful".