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 👍

See #2755 (comment) for the 5.0 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.

Got it, I misunderstood it before, I thought we just need to support LTS at that time.

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 Thanks for the clarification. Just noticed it was here #4171 🙂