Skip to content

Dependencies (5.0) #4282

Closed
Closed

Description

@vansergen

It seems that we can remove a few dependencies before the 5.0 release:

  • methods - We can use the built-in http module:
const { METHODS } = require("http");
const methods = METHODS.map((method) => method.toLowerCase());
  • path-is-absolute - We can use the built-in path module:
const path = require("path");
const isAbsolute = path.isAbsolute("some-path");
  • safe-buffer - We can use the built-in Buffer:
const a = Buffer.from("something");
  • setprototypeof - We can use the Object.setPrototypeOf()
Object.setPrototypeOf(this.request, parent.request);
  • utils-merge - We can use the spread operator:
const opts = { expires: new Date(1), path: '/' , ...options};

Activity

  1. jonchurch commented on May 16, 2020

    @jonchurch
    Member

    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 👍

  2. xuxucode commented on May 17, 2020

    @xuxucode

    See #2755 (comment) for the 5.0 version support:
    image

  3. dougwilson commented on May 17, 2020

    @dougwilson
    Contributor

    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.

  4. xuxucode commented on May 18, 2020

    @xuxucode

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

  5. dougwilson commented on May 18, 2020

    @dougwilson
    Contributor

    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.

  6. dougwilson commented on May 26, 2020

    @dougwilson
  7. mgoffan commented on May 26, 2020

    @mgoffan

    @dougwilson Thanks for the clarification. Just noticed it was here #4171 🙂

  8. dougwilson commented on Jun 3, 2021

    @dougwilson
  9. deleted a comment from lucaslago on Jun 3, 2021
  10. deleted a comment from thernstig on Dec 31, 2021
  11. kisaragi-hiu commented on Sep 23, 2023

    @kisaragi-hiu
    • setprototypeof: Object.setPrototypeOf (Node 0.11+, )

      Object.setPrototypeOf came to Node in v6.0.0, so again, that can probably be used once version support comes that high.

      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)

  12. jonkoops commented on Dec 2, 2024

    @jonkoops
    Contributor

    PR to remove utils-merge from the dependencies is up under #6194

  13. wesleytodd commented on Jan 11, 2025

    @wesleytodd
    Member

    Going to close this as we have ongoing PRs for most of this and we don't really need a tracking issue for those.

  14. mohabdelkarim commented on Aug 19, 2026

    @mohabdelkarim

    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 typescript sketch 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.

  15. kisaragi-hiu commented on Aug 19, 2026

    @kisaragi-hiu

    @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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions