build(deps): bump actions/download-artifact from 4.3.0 to 5.0.0 (#6793)

Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 4.3.0 to 5.0.0.
- [Release notes](https://github.com/actions/download-artifact/releases)
- [Commits](d3f86a106a...634f93cb29)

---
updated-dependencies:
- dependency-name: actions/download-artifact
  dependency-version: 5.0.0
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

.eslintrc.yml

@@ -8,3 +8,7 @@ rules:
   indent: [error, 2, { MemberExpression: "off", SwitchCase: 1 }]
   no-trailing-spaces: error
   no-unused-vars: [error, { vars: all, args: none, ignoreRestSiblings: true }]
+  no-restricted-globals:
+    - error
+    - name: Buffer
+      message: Use `import { Buffer } from "node:buffer"` instead of the global Buffer.

.github/workflows/ci.yml

@@ -11,8 +11,6 @@ on:
     paths-ignore:
       - '*.md'
   pull_request:
-    paths-ignore:
-      - '*.md'
   workflow_dispatch:
 
 permissions:
@@ -29,11 +27,11 @@ jobs:
     name: Lint
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+      - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
         with:
           persist-credentials: false
       - name: Setup Node.js
-        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
+        uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
         with:
           node-version: 'lts/*'
 
@@ -55,12 +53,12 @@ jobs:
 
     runs-on: ${{ matrix.os }}
     steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+      - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
         with:
           persist-credentials: false
 
       - name: Setup Node.js ${{ matrix.node-version }}
-        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
+        uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
         with:
           node-version: ${{ matrix.node-version }}
 
@@ -95,7 +93,7 @@ jobs:
       contents: read
       checks: write
     steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+      - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
         with:
           persist-credentials: false
 
@@ -104,7 +102,7 @@ jobs:
         run: sudo apt-get -y install lcov
 
       - name: Collect coverage reports
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        uses: actions/download-artifact@634f93cb2916e3fdff6788551b99b062d0335ce0 # v5.0.0
         with:
           path: ./coverage
           pattern: coverage-node-*

.github/workflows/codeql.yml

@@ -39,13 +39,13 @@ jobs:
 
     steps:
       - name: Checkout repository
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+        uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
         with:
           persist-credentials: false
 
       # Initializes the CodeQL tools for scanning.
       - name: Initialize CodeQL
-        uses: github/codeql-action/init@28deaeda66b76a05916b6923827895f2b14ab387 # v3.28.16
+        uses: github/codeql-action/init@3599b3baa15b485a2e49ef411a7a4bb2452e7f93 # v3.29.5
         with:
           languages: ${{ matrix.language }}
           config: |
@@ -71,4 +71,4 @@ jobs:
       #   ./location_of_script_within_repo/buildscript.sh
 
       - name: Perform CodeQL Analysis
-        uses: github/codeql-action/analyze@28deaeda66b76a05916b6923827895f2b14ab387 # v3.28.16
+        uses: github/codeql-action/analyze@3599b3baa15b485a2e49ef411a7a4bb2452e7f93 # v3.29.5

.github/workflows/legacy.yml

@@ -37,12 +37,12 @@ jobs:
 
     runs-on: ${{ matrix.os }}
     steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+      - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
         with:
           persist-credentials: false
 
       - name: Setup Node.js ${{ matrix.node-version }}
-        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
+        uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
         with:
           node-version: ${{ matrix.node-version }}
 
@@ -77,7 +77,7 @@ jobs:
       contents: read
       checks: write
     steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+      - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
         with:
           persist-credentials: false
 
@@ -86,7 +86,7 @@ jobs:
         run: sudo apt-get -y install lcov
 
       - name: Collect coverage reports
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        uses: actions/download-artifact@634f93cb2916e3fdff6788551b99b062d0335ce0 # v5.0.0
         with:
           path: ./coverage
           pattern: coverage-node-*

.github/workflows/scorecard.yml

@@ -32,12 +32,12 @@ jobs:
 
     steps:
       - name: "Checkout code"
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+        uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
         with:
           persist-credentials: false
 
       - name: "Run analysis"
-        uses: ossf/scorecard-action@f49aabe0b5af0936a0987cfb85d86b75731b0186 # v2.4.1
+        uses: ossf/scorecard-action@4eaacf0543bb3f2c246792bd56e8cdeffafb205a # v2.4.3
         with:
           results_file: results.sarif
           results_format: sarif
@@ -67,6 +67,6 @@ jobs:
 
       # Upload the results to GitHub's code scanning dashboard.
       - name: "Upload to code-scanning"
-        uses: github/codeql-action/upload-sarif@28deaeda66b76a05916b6923827895f2b14ab387 # v3.28.16
+        uses: github/codeql-action/upload-sarif@3599b3baa15b485a2e49ef411a7a4bb2452e7f93 # v3.29.5
         with:
           sarif_file: results.sarif

.gitignore

@@ -5,6 +5,10 @@ npm-shrinkwrap.json
 *.log
 *.gz
 
+# Yarn
+yarn-error.log
+yarn.lock
+
 # Coveralls
 .nyc_output
 coverage

Charter.md

@@ -1,92 +0,0 @@
-# Express Charter
-
-## Section 0: Guiding Principles
-
-The Express project is part of the OpenJS Foundation which operates
-transparently, openly, collaboratively, and ethically.
-Project proposals, timelines, and status must not merely be open, but
-also easily visible to outsiders.
-
-## Section 1: Scope
-
-Express is a HTTP web server framework with a simple and expressive API
-which is highly aligned with Node.js core. We aim to be the best in
-class for writing performant, spec compliant, and powerful web servers
-in Node.js. As one of the oldest and most popular web frameworks in
-the ecosystem, we have an important place for new users and experts
-alike.
-
-### 1.1: In-scope
-
-Express is made of many modules spread between three GitHub Orgs:
-
-- [expressjs](https://github.com/expressjs/): Top level middleware and
-  libraries
-- [pillarjs](https://github.com/pillarjs/): Components which make up
-  Express but can also be used for other web frameworks
-- [jshttp](https://github.com/jshttp/): Low level HTTP libraries
-
-### 1.2: Out-of-Scope
-
-Section Intentionally Left Blank
-
-## Section 2: Relationship with OpenJS Foundation CPC.
-
-Technical leadership for the projects within the OpenJS Foundation is
-delegated to the projects through their project charters by the OpenJS
-Cross Project Council (CPC). In the case of the Express project, it is
-delegated to the Express Technical Committee ("TC").
-
-This Technical Committee is in charge of both the day-to-day operations
-of the project, as well as its technical management. This charter can
-be amended by the TC requiring at least two approvals and a minimum two
-week comment period for other TC members or CPC members to object. Any
-changes the CPC wishes to propose will be considered a priority but
-will follow the same process.
-
-### 2.1 Other Formal Project Relationships
-
-Section Intentionally Left Blank
-
-## Section 3: Express Governing Body
-
-The Express project is managed by the Technical Committee ("TC").
-Members can be added to the TC at any time. Any committer can nominate
-another committer to the TC and the TC uses its standard consensus
-seeking process to evaluate whether or not to add this new member.
-Members who do not participate consistently at the level of a majority
-of the other members are expected to resign.
-
-## Section 4: Roles & Responsibilities
-
-The Express TC manages all aspects of both the technical and community
-parts of the project. Members of the TC should attend the regular
-meetings when possible, and be available for discussion of time
-sensitive or important issues.
-
-### Section 4.1 Project Operations & Management
-
-Section Intentionally Left Blank
-
-### Section 4.2: Decision-making, Voting, and/or Elections
-
-The Express TC uses a "consensus seeking" process for issues that are
-escalated to the TC. The group tries to find a resolution that has no
-open objections among TC members. If a consensus cannot be reached
-that has no objections then a majority wins vote is called. It is also
-expected that the majority of decisions made by the TC are via a
-consensus seeking process and that voting is only used as a last-resort.
-
-Resolution may involve returning the issue to committers with
-suggestions on how to move forward towards a consensus. It is not
-expected that a meeting of the TC will resolve all issues on its
-agenda during that meeting and may prefer to continue the discussion
-happening among the committers.
-
-### Section 4.3: Other Project Roles
-
-Section Intentionally Left Blank
-
-## Section 5: Definitions
-
-Section Intentionally Left Blank

Code-Of-Conduct.md

@@ -1,139 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-As a member of the Open JS Foundation, Express has adopted the
-[Contributor Covenant 2.0][cc-20-doc].
-
-If an issue arises and you cannot resolve it directly with the parties
-involved, you can report it to the Express project TC through the following
-email: express-coc@lists.openjsf.org
-
-In addition, the OpenJS Foundation maintains a Code of Conduct Panel (CoCP).
-This is a foundation-wide team established to manage escalation when a reporter
-believes that a report to a member project or the CPC has not been properly
-handled. In order to escalate to the CoCP send an email to
-coc-escalation@lists.openjsf.org.
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in our
-community a harassment-free experience for everyone, regardless of age, body
-size, visible or invisible disability, ethnicity, sex characteristics, gender
-identity and expression, level of experience, education, socio-economic status,
-nationality, personal appearance, race, religion, or sexual identity and
-orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming,
-diverse, inclusive, and healthy community.
-
-## Our Standards
-
-Examples of behavior that contributes to a positive environment for our
-community include:
-
-* Demonstrating empathy and kindness toward other people
-* Being respectful of differing opinions, viewpoints, and experiences
-* Giving and gracefully accepting constructive feedback
-* Accepting responsibility and apologizing to those affected by our mistakes,
-  and learning from the experience
-* Focusing on what is best not just for us as individuals, but for the overall
-  community
-
-Examples of unacceptable behavior include:
-
-* The use of sexualized language or imagery, and sexual attention or advances
-  of any kind
-* Trolling, insulting or derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or email address,
-  without their explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-## Enforcement Responsibilities
-
-Community leaders are responsible for clarifying and enforcing our standards of
-acceptable behavior and will take appropriate and fair corrective action in
-response to any behavior that they deem inappropriate, threatening, offensive,
-or harmful.
-
-Community leaders have the right and responsibility to remove, edit, or reject
-comments, commits, code, wiki edits, issues, and other contributions that are
-not aligned to this Code of Conduct, and will communicate reasons for
-moderation decisions when appropriate.
-
-## Scope
-
-This Code of Conduct applies within all community spaces, and also applies when
-an individual is officially representing the community in public spaces.
-Examples of representing our community include using an official e-mail
-address, posting via an official social media account, or acting as an
-appointed representative at an online or offline event.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported to the community leaders responsible for enforcement at
-express-coc@lists.openjsf.org. All complaints will be reviewed and
-investigated promptly and fairly.
-
-All community leaders are obligated to respect the privacy and security of the
-reporter of any incident.
-
-## Enforcement Guidelines
-
-Community leaders will follow these Community Impact Guidelines in determining
-the consequences for any action they deem in violation of this Code of Conduct:
-
-### 1. Correction
-
-**Community Impact**: Use of inappropriate language or other behavior deemed
-unprofessional or unwelcome in the community.
-
-**Consequence**: A private, written warning from community leaders, providing
-clarity around the nature of the violation and an explanation of why the
-behavior was inappropriate. A public apology may be requested.
-
-### 2. Warning
-
-**Community Impact**: A violation through a single incident or series of
-actions.
-
-**Consequence**: A warning with consequences for continued behavior. No
-interaction with the people involved, including unsolicited interaction with
-those enforcing the Code of Conduct, for a specified period of time. This
-includes avoiding interactions in community spaces as well as external channels
-like social media. Violating these terms may lead to a temporary or permanent
-ban.
-
-### 3. Temporary Ban
-
-**Community Impact**: A serious violation of community standards, including
-sustained inappropriate behavior.
-
-**Consequence**: A temporary ban from any sort of interaction or public
-communication with the community for a specified period of time. No public or
-private interaction with the people involved, including unsolicited
-interaction with those enforcing the Code of Conduct, is allowed during this
-period. Violating these terms may lead to a permanent ban.
-
-### 4. Permanent Ban
-
-**Community Impact**: Demonstrating a pattern of violation of community
-standards, including sustained inappropriate behavior,  harassment of an
-individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence**: A permanent ban from any sort of public interaction within the
-project community.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant, version 2.0][cc-20-doc].
-
-Community Impact Guidelines were inspired by
-[Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
-
-[cc-20-doc]: https://www.contributor-covenant.org/version/2/0/code_of_conduct/
-
-For answers to common questions about this code of conduct, see the FAQ at
-https://www.contributor-covenant.org/faq. Translations are available at
-https://www.contributor-covenant.org/translations.

Collaborator-Guide.md

@@ -1,51 +0,0 @@
-# Express Collaborator Guide
-
-## Website Issues
-
-Open issues for the expressjs.com website in https://github.com/expressjs/expressjs.com.
-
-## PRs and Code contributions
-
-* Tests must pass.
-* Follow the [JavaScript Standard Style](https://standardjs.com/) and `npm run lint`.
-* If you fix a bug, add a test.
-
-## Branches
-
-Use the `master` branch for bug fixes or minor work that is intended for the
-current release stream.
-
-Use the correspondingly named branch, e.g. `5.0`, for anything intended for
-a future release of Express.
-
-## Steps for contributing
-
-1. [Create an issue](https://github.com/expressjs/express/issues/new) for the
-   bug you want to fix or the feature that you want to add.
-2. Create your own [fork](https://github.com/expressjs/express) on GitHub, then
-   checkout your fork.
-3. Write your code in your local copy. It's good practice to create a branch for
-   each new issue you work on, although not compulsory.
-4. To run the test suite, first install the dependencies by running `npm install`,
-   then run `npm test`.
-5. Ensure your code is linted by running `npm run lint` -- fix any issue you
-   see listed.
-6. If the tests pass, you can commit your changes to your fork and then create
-   a pull request from there. Make sure to reference your issue from the pull
-   request comments by including the issue number e.g. `#123`.
-
-## Issues which are questions
-
-We will typically close any vague issues or questions that are specific to some
-app you are writing. Please double check the docs and other references before
-being trigger happy with posting a question issue.
-
-Things that will help get your question issue looked at:
-
-* Full and runnable JS code.
-* Clear description of the problem or unexpected behavior.
-* Clear description of the expected result.
-* Steps you have taken to debug it yourself.
-
-If you post a question and do not outline the above items or make it easy for
-us to understand and reproduce your issue, it will be closed.

Contributing.md

@@ -1,245 +0,0 @@
-# Express.js Community Contributing Guide 1.0
-
-The goal of this document is to create a contribution process that:
-
-* Encourages new contributions.
-* Encourages contributors to remain involved.
-* Avoids unnecessary processes and bureaucracy whenever possible.
-* Creates a transparent decision making process that makes it clear how
-contributors can be involved in decision making.
-
-## Vocabulary
-
-* A **Contributor** is any individual creating or commenting on an issue or pull request.
-* A **Committer** is a subset of contributors who have been given write access to the repository.
-* A **Project Captain** is the lead maintainer of a repository.
-* A **TC (Technical Committee)** is a group of committers representing the required technical
-expertise to resolve rare disputes.
-* A **Triager** is a subset of contributors who have been given triage access to the repository.
-
-## Logging Issues
-
-Log an issue for any question or problem you might have. When in doubt, log an issue, and
-any additional policies about what to include will be provided in the responses. The only
-exception is security disclosures which should be sent privately.
-
-Committers may direct you to another repository, ask for additional clarifications, and
-add appropriate metadata before the issue is addressed.
-
-Please be courteous and respectful. Every participant is expected to follow the
-project's Code of Conduct.
-
-## Contributions
-
-Any change to resources in this repository must be through pull requests. This applies to all changes
-to documentation, code, binary files, etc. Even long term committers and TC members must use
-pull requests.
-
-No pull request can be merged without being reviewed.
-
-For non-trivial contributions, pull requests should sit for at least 36 hours to ensure that
-contributors in other timezones have time to review. Consideration should also be given to
-weekends and other holiday periods to ensure active committers all have reasonable time to
-become involved in the discussion and review process if they wish.
-
-The default for each contribution is that it is accepted once no committer has an objection.
-During a review, committers may also request that a specific contributor who is most versed in a
-particular area gives a "LGTM" before the PR can be merged. There is no additional "sign off"
-process for contributions to land. Once all issues brought by committers are addressed it can
-be landed by any committer.
-
-In the case of an objection being raised in a pull request by another committer, all involved
-committers should seek to arrive at a consensus by way of addressing concerns being expressed
-by discussion, compromise on the proposed change, or withdrawal of the proposed change.
-
-If a contribution is controversial and committers cannot agree about how to get it to land
-or if it should land then it should be escalated to the TC. TC members should regularly
-discuss pending contributions in order to find a resolution. It is expected that only a
-small minority of issues be brought to the TC for resolution and that discussion and
-compromise among committers be the default resolution mechanism.
-
-## Becoming a Triager
-
-Anyone can become a triager! Read more about the process of being a triager in
-[the triage process document](Triager-Guide.md).
-
-Currently, any existing [organization member](https://github.com/orgs/expressjs/people) can nominate
-a new triager. If you are interested in becoming a triager, our best advice is to actively participate
-in the community by helping triaging issues and pull requests. As well we recommend
-to engage in other community activities like attending the TC meetings, and participating in the Slack
-discussions. If you feel ready and have been helping triage some issues, reach out to an active member of the organization to ask if they'd
-be willing to support you. If they agree, they can create a pull request to formalize your nomination. In the case of an objection to the nomination, the triage team is responsible for working with the individuals involved and finding a resolution.
-
-You can also reach out to any of the [organization members](https://github.com/orgs/expressjs/people)
-if you have questions or need guidance.
-
-## Becoming a Committer
-
-All contributors who have landed significant and valuable contributions should be onboarded in a timely manner,
-and added as a committer, and be given write access to the repository.
-
-Committers are expected to follow this policy and continue to send pull requests, go through
-proper review, and have other committers merge their pull requests.
-
-## TC Process
-
-The TC uses a "consensus seeking" process for issues that are escalated to the TC.
-The group tries to find a resolution that has no open objections among TC members.
-If a consensus cannot be reached that has no objections then a majority wins vote
-is called. It is also expected that the majority of decisions made by the TC are via
-a consensus seeking process and that voting is only used as a last-resort.
-
-Resolution may involve returning the issue to project captains with suggestions on
-how to move forward towards a consensus. It is not expected that a meeting of the TC
-will resolve all issues on its agenda during that meeting and may prefer to continue
-the discussion happening among the project captains.
-
-Members can be added to the TC at any time. Any TC member can nominate another committer
-to the TC and the TC uses its standard consensus seeking process to evaluate whether or
-not to add this new member. The TC will consist of a minimum of 3 active members and a
-maximum of 10. If the TC should drop below 5 members the active TC members should nominate
-someone new. If a TC member is stepping down, they are encouraged (but not required) to
-nominate someone to take their place.
-
-TC members will be added as admin's on the Github orgs, npm orgs, and other resources as
-necessary to be effective in the role.
-
-To remain "active" a TC member should have participation within the last 12 months and miss
-no more than six consecutive TC meetings. Our goal is to increase participation, not punish
-people for any lack of participation, this guideline should be only be used as such
-(replace an inactive member with a new active one, for example). Members who do not meet this
-are expected to step down. If A TC member does not step down, an issue can be opened in the
-discussions repo to move them to inactive status. TC members who step down or are removed due
-to inactivity will be moved into inactive status.
-
-Inactive status members can become active members by self nomination if the TC is not already
-larger than the maximum of 10. They will also be given preference if, while at max size, an
-active member steps down.
-
-## Project Captains
-
-The Express TC can designate captains for individual projects/repos in the
-organizations. These captains are responsible for being the primary
-day-to-day maintainers of the repo on a technical and community front.
-Repo captains are empowered with repo ownership and package publication rights.
-When there are conflicts, especially on topics that effect the Express project
-at large, captains are responsible to raise it up to the TC and drive
-those conflicts to resolution. Captains are also responsible for making sure
-community members follow the community guidelines, maintaining the repo
-and the published package, as well as in providing user support.
-
-Like TC members, Repo captains are a subset of committers.
-
-To become a captain for a project the candidate is expected to participate in that
-project for at least 6 months as a committer prior to the request. They should have
-helped with code contributions as well as triaging issues. They are also required to
-have 2FA enabled on both their GitHub and npm accounts.
-
-Any TC member or an existing captain on the **same** repo can nominate another committer 
-to the captain role. To do so, they should submit a PR to this document, updating the 
-**Active Project Captains** section (while maintaining the sort order) with the project 
-name, the nominee's GitHub handle, and their npm username (if different).
-- Repos can have as many captains as make sense for the scope of work.
-- A TC member or an existing repo captain **on the same project** can nominate a new captain. 
-  Repo captains from other projects should not nominate captains for a different project.
-
-The PR will require at least 2 approvals from TC members and 2 weeks hold time to allow 
-for comment and/or dissent.  When the PR is merged, a TC member will add them to the 
-proper GitHub/npm groups.
-
-### Active Projects and Captains
-
-- [`expressjs/badgeboard`](https://github.com/expressjs/badgeboard): @wesleytodd
-- [`expressjs/basic-auth-connect`](https://github.com/expressjs/basic-auth-connect): @ulisesGascon
-- [`expressjs/body-parser`](https://github.com/expressjs/body-parser): @wesleytodd, @jonchurch, @ulisesGascon
-- [`expressjs/compression`](https://github.com/expressjs/compression): @ulisesGascon
-- [`expressjs/connect-multiparty`](https://github.com/expressjs/connect-multiparty): @ulisesGascon
-- [`expressjs/cookie-parser`](https://github.com/expressjs/cookie-parser): @wesleytodd, @UlisesGascon
-- [`expressjs/cookie-session`](https://github.com/expressjs/cookie-session): @ulisesGascon
-- [`expressjs/cors`](https://github.com/expressjs/cors): @jonchurch, @ulisesGascon
-- [`expressjs/discussions`](https://github.com/expressjs/discussions): @wesleytodd
-- [`expressjs/errorhandler`](https://github.com/expressjs/errorhandler): @ulisesGascon
-- [`expressjs/express-paginate`](https://github.com/expressjs/express-paginate): @ulisesGascon
-- [`expressjs/express`](https://github.com/expressjs/express): @wesleytodd, @ulisesGascon
-- [`expressjs/expressjs.com`](https://github.com/expressjs/expressjs.com): @crandmck, @jonchurch, @bjohansebas
-- [`expressjs/flash`](https://github.com/expressjs/flash): @ulisesGascon
-- [`expressjs/generator`](https://github.com/expressjs/generator): @wesleytodd
-- [`expressjs/method-override`](https://github.com/expressjs/method-override): @ulisesGascon
-- [`expressjs/morgan`](https://github.com/expressjs/morgan): @jonchurch, @ulisesGascon
-- [`expressjs/multer`](https://github.com/expressjs/multer): @LinusU, @ulisesGascon
-- [`expressjs/response-time`](https://github.com/expressjs/response-time): @UlisesGascon
-- [`expressjs/serve-favicon`](https://github.com/expressjs/serve-favicon): @ulisesGascon
-- [`expressjs/serve-index`](https://github.com/expressjs/serve-index): @ulisesGascon
-- [`expressjs/serve-static`](https://github.com/expressjs/serve-static): @ulisesGascon
-- [`expressjs/session`](https://github.com/expressjs/session): @ulisesGascon
-- [`expressjs/statusboard`](https://github.com/expressjs/statusboard): @wesleytodd
-- [`expressjs/timeout`](https://github.com/expressjs/timeout): @ulisesGascon
-- [`expressjs/vhost`](https://github.com/expressjs/vhost): @ulisesGascon
-- [`jshttp/accepts`](https://github.com/jshttp/accepts): @blakeembrey
-- [`jshttp/basic-auth`](https://github.com/jshttp/basic-auth): @blakeembrey
-- [`jshttp/compressible`](https://github.com/jshttp/compressible): @blakeembrey
-- [`jshttp/content-disposition`](https://github.com/jshttp/content-disposition): @blakeembrey
-- [`jshttp/content-type`](https://github.com/jshttp/content-type): @blakeembrey
-- [`jshttp/cookie`](https://github.com/jshttp/cookie): @blakeembrey
-- [`jshttp/etag`](https://github.com/jshttp/etag): @blakeembrey
-- [`jshttp/forwarded`](https://github.com/jshttp/forwarded): @blakeembrey
-- [`jshttp/fresh`](https://github.com/jshttp/fresh): @blakeembrey
-- [`jshttp/http-assert`](https://github.com/jshttp/http-assert): @wesleytodd, @jonchurch, @ulisesGascon
-- [`jshttp/http-errors`](https://github.com/jshttp/http-errors): @wesleytodd, @jonchurch, @ulisesGascon
-- [`jshttp/media-typer`](https://github.com/jshttp/media-typer): @blakeembrey
-- [`jshttp/methods`](https://github.com/jshttp/methods): @blakeembrey
-- [`jshttp/mime-db`](https://github.com/jshttp/mime-db): @blakeembrey, @UlisesGascon
-- [`jshttp/mime-types`](https://github.com/jshttp/mime-types): @blakeembrey, @UlisesGascon
-- [`jshttp/negotiator`](https://github.com/jshttp/negotiator): @blakeembrey
-- [`jshttp/on-finished`](https://github.com/jshttp/on-finished): @wesleytodd, @ulisesGascon
-- [`jshttp/on-headers`](https://github.com/jshttp/on-headers): @blakeembrey
-- [`jshttp/proxy-addr`](https://github.com/jshttp/proxy-addr): @wesleytodd, @ulisesGascon
-- [`jshttp/range-parser`](https://github.com/jshttp/range-parser): @blakeembrey
-- [`jshttp/statuses`](https://github.com/jshttp/statuses): @blakeembrey
-- [`jshttp/type-is`](https://github.com/jshttp/type-is): @blakeembrey
-- [`jshttp/vary`](https://github.com/jshttp/vary): @blakeembrey
-- [`pillarjs/cookies`](https://github.com/pillarjs/cookies): @blakeembrey
-- [`pillarjs/csrf`](https://github.com/pillarjs/csrf): @ulisesGascon
-- [`pillarjs/encodeurl`](https://github.com/pillarjs/encodeurl): @blakeembrey
-- [`pillarjs/finalhandler`](https://github.com/pillarjs/finalhandler): @wesleytodd, @ulisesGascon
-- [`pillarjs/hbs`](https://github.com/pillarjs/hbs): @ulisesGascon
-- [`pillarjs/multiparty`](https://github.com/pillarjs/multiparty): @blakeembrey
-- [`pillarjs/parseurl`](https://github.com/pillarjs/parseurl): @blakeembrey
-- [`pillarjs/path-to-regexp`](https://github.com/pillarjs/path-to-regexp): @blakeembrey
-- [`pillarjs/request`](https://github.com/pillarjs/request): @wesleytodd
-- [`pillarjs/resolve-path`](https://github.com/pillarjs/resolve-path): @blakeembrey
-- [`pillarjs/router`](https://github.com/pillarjs/router): @wesleytodd, @ulisesGascon
-- [`pillarjs/send`](https://github.com/pillarjs/send): @blakeembrey
-- [`pillarjs/understanding-csrf`](https://github.com/pillarjs/understanding-csrf): @ulisesGascon
-
-### Current Initiative Captains
-
-- Triage team [ref](https://github.com/expressjs/discussions/issues/227): @UlisesGascon
-
-## Developer's Certificate of Origin 1.1
-
-```text
-By making a contribution to this project, I certify that:
-
- (a) The contribution was created in whole or in part by me and I
-     have the right to submit it under the open source license
-     indicated in the file; or
-
- (b) The contribution is based upon previous work that, to the best
-     of my knowledge, is covered under an appropriate open source
-     license and I have the right under that license to submit that
-     work with modifications, whether created in whole or in part
-     by me, under the same open source license (unless I am
-     permitted to submit under a different license), as indicated
-     in the file; or
-
- (c) The contribution was provided directly to me by some other
-     person who certified (a), (b) or (c) and I have not modified
-     it.
-
- (d) I understand and agree that this project and the contribution
-     are public and that a record of the contribution (including all
-     personal information I submit with it, including my sign-off) is
-     maintained indefinitely and may be redistributed consistent with
-     this project or the open source license(s) involved.
-```

Readme-Guide.md

@@ -1,125 +0,0 @@
-# README guidelines
-
-Every module in the expressjs, pillarjs, and jshttp organizations should have
-a README file named `README.md`. The purpose of the README is to:
-
-- Explain the purpose of the module and how to use it.
-- Act as a landing page (both on GitHub and npmjs.com) for the module to help
-  people find it via search. Middleware module READMEs are also incorporated
-  into https://expressjs.com/en/resources/middleware.html.
-- Encourage community contributions and participation.
-
-Use the [README template](https://github.com/expressjs/express/wiki/README-template)
-to quickly create a new README file.
-
-## Top-level items
-
-**Badges** (optional): At the very top (with no subheading), include any
-applicable badges, such as npm version/downloads, build status, test coverage,
-and so on. Badges should resolve properly (not display a broken image).
-
-Possible badges include:
-- npm version: `[![NPM Version][npm-image]][npm-url]`
-- npm downloads: `[![NPM Downloads][downloads-image]][downloads-url]`
-- Build status: `[![Build Status][travis-image]][travis-url]`
-- Test coverage: `[![Test Coverage][coveralls-image]][coveralls-url]`
-- Tips: `[![Gratipay][gratipay-image]][gratipay-url]`
-
-**Summary**: Following badges, provide a one- or two-sentence description of
-what the module does. This should be the same as the npmjs.org blurb (which
-comes from the description property of `package.json`). Since npm doesn't
-handle markdown for the blurb, avoid using markdown in the summary sentence.
-
-**TOC** (Optional): For longer READMEs, provide a table of contents that has
-a relative link to each section. A tool such as
-[doctoc](https://www.npmjs.com/package/doctoc) makes it very easy to generate
-a TOC.
-
-## Overview
-
-Optionally, include a section of one or two paragraphs with more high-level
-information on what the module does, what problems it solves, why one would
-use it and how.  Don't just repeat what's in the summary.
-
-## Installation
-
-Required. This section is typically just:
-
-```sh
-$ npm install module-name
-```
-
-But include any other steps or requirements.
-
-NOTE: Use the `sh` code block to make the shell command display properly on
-the website.
-
-## Basic use
-
-- Provide a general description of how to use the module with code sample.
-  Include any important caveats or restrictions.
-- Explain the most common use cases.
-- Optional: a simple "hello world" type example (where applicable). This
-  example is in addition to the more comprehensive [example section](#examples)
-  later.
-
-## API
-
-Provide complete API documentation.
-
-Formatting conventions: Each function is listed in a 3rd-level heading (`###`),
-like this:
-
-```
-### Function_name(arg, options [, optional_arg]  ... )
-```
-
-**Options objects**
-
-For arguments that are objects (for example, options object), describe the
-properties in a table, as follows. This matches the formatting used in the
-[Express API docs](https://expressjs.com/en/4x/api.html).
-
-|Property | Description | Type | Default|
-|----------|-----------|------------|-------------|
-|Name of the property in `monospace`. | Brief description | String, Number, Boolean, etc. | If applicable.|
-
-If all the properties are required (i.e. there are no defaults), then you
-can omit the default column.
-
-Instead of very lengthy descriptions, link out to subsequent paragraphs for
-more detailed explanation of specific cases (e.g. "When this property is set
-to 'foobar', xyz happens; see <link to following section >.)
-
-If there are options properties that are themselves options, use additional
-tables. See [`trust proxy` and `etag` properties](https://expressjs.com/en/4x/api.html#app.settings.table).
-
-## Examples
-
-Every README should have at least one example; ideally more.  For code samples,
-be sure to use the `js` code block, for proper display in the website, e.g.:
-
-```js
-var csurf = require('csurf')
-...
-```
-
-## Tests
-
-What tests are included.
-
-How to run them.
-
-The convention for running tests is `npm test`. All our projects should follow
-this convention.
-
-## Contributors
-
-Names of module "owners" (lead developers) and other developers who have
-contributed.
-
-## License
-
-Link to the license, with a short description of what it is, e.g. "MIT" or
-whatever. Ideally, avoid putting the license text directly in the README; link
-to it instead.

Readme.md

@@ -2,25 +2,32 @@
 
 **Fast, unopinionated, minimalist web framework for [Node.js](https://nodejs.org).**
 
-**This project has a [Code of Conduct][].**
+**This project has a [Code of Conduct].**
 
 ## Table of contents
 
-* [Installation](#Installation)
-* [Features](#Features)
-* [Docs & Community](#docs--community)
-* [Quick Start](#Quick-Start)
-* [Running Tests](#Running-Tests)
-* [Philosophy](#Philosophy)
-* [Examples](#Examples)
-* [Contributing to Express](#Contributing)
-* [TC (Technical Committee)](#tc-technical-committee)
-* [Triagers](#triagers)
-* [License](#license)
+- [Table of contents](#table-of-contents)
+- [Installation](#installation)
+- [Features](#features)
+- [Docs \& Community](#docs--community)
+- [Quick Start](#quick-start)
+- [Philosophy](#philosophy)
+- [Examples](#examples)
+- [Contributing](#contributing)
+  - [Security Issues](#security-issues)
+  - [Running Tests](#running-tests)
+- [Current project team members](#current-project-team-members)
+  - [TC (Technical Committee)](#tc-technical-committee)
+    - [TC emeriti members](#tc-emeriti-members)
+  - [Triagers](#triagers)
+    - [Emeritus Triagers](#emeritus-triagers)
+- [License](#license)
 
 
 [![NPM Version][npm-version-image]][npm-url]
 [![NPM Downloads][npm-downloads-image]][npm-downloads-url]
+[![Linux Build][github-actions-ci-image]][github-actions-ci-url]
+[![Test Coverage][coveralls-image]][coveralls-url]
 [![OpenSSF Scorecard Badge][ossf-scorecard-badge]][ossf-scorecard-visualizer]
 
 
@@ -33,7 +40,9 @@ app.get('/', (req, res) => {
   res.send('Hello World')
 })
 
-app.listen(3000)
+app.listen(3000, () => {
+  console.log('Server is running on http://localhost:3000')
+})
 ```
 
 ## Installation
@@ -137,18 +146,15 @@ node examples/content-negotiation
 
 ## Contributing
 
-  [![Linux Build][github-actions-ci-image]][github-actions-ci-url]
-  [![Test Coverage][coveralls-image]][coveralls-url]
-
 The Express.js project welcomes all constructive contributions. Contributions take many forms,
 from code for bug fixes and enhancements, to additions and fixes to documentation, additional
 tests, triaging incoming pull requests and issues, and more!
 
-See the [Contributing Guide](Contributing.md) for more technical details on contributing.
+See the [Contributing Guide] for more technical details on contributing.
 
 ### Security Issues
 
-If you discover a security vulnerability in Express, please see [Security Policies and Procedures](Security.md).
+If you discover a security vulnerability in Express, please see [Security Policies and Procedures](SECURITY.md).
 
 ### Running Tests
 
@@ -164,7 +170,9 @@ Then run `npm test`:
 npm test
 ```
 
-## People
+## Current project team members
+
+For information about the governance of the express.js project, see [GOVERNANCE.md](https://github.com/expressjs/discussions/blob/HEAD/docs/GOVERNANCE.md).
 
 The original author of Express is [TJ Holowaychuk](https://github.com/tj)
 
@@ -245,7 +253,7 @@ The original author of Express is [TJ Holowaychuk](https://github.com/tj)
   * [dakshkhetan](https://github.com/dakshkhetan) - **Daksh Khetan** (he/him)
   * [lucasraziel](https://github.com/lucasraziel) - **Lucas Soares Do Rego**
   * [mertcanaltin](https://github.com/mertcanaltin) - **Mert Can Altin**
-  
+
 </details>
 
 
@@ -263,4 +271,5 @@ The original author of Express is [TJ Holowaychuk](https://github.com/tj)
 [npm-version-image]: https://badgen.net/npm/v/express
 [ossf-scorecard-badge]: https://api.scorecard.dev/projects/github.com/expressjs/express/badge
 [ossf-scorecard-visualizer]: https://ossf.github.io/scorecard-visualizer/#/projects/github.com/expressjs/express
-[Code of Conduct]: https://github.com/expressjs/express/blob/master/Code-Of-Conduct.md
+[Code of Conduct]: https://github.com/expressjs/.github/blob/HEAD/CODE_OF_CONDUCT.md
+[Contributing Guide]: https://github.com/expressjs/.github/blob/HEAD/CONTRIBUTING.md

Release-Process.md

@@ -1,202 +0,0 @@
-# Express Release Process
-
-This document contains the technical aspects of the Express release process. The
-intended audience is those who have been authorized by the Express Technical
-Committee (TC) to create, promote and sign official release builds for Express,
-as npm packages hosted on https://npmjs.com/package/express.
-
-## Who can make releases?
-
-Release authorization is given by the Express TC. Once authorized, an individual
-must have the following access permissions:
-
-### 1. Github release access
-
-The individual making the release will need to be a member of the
-expressjs/express team with Write permission level so they are able to tag the
-release commit and push changes to the expressjs/express repository
-(see Steps 4 and 5).
-
-### 2. npmjs.com release access
-
-The individual making the release will need to be made an owner on the
-`express` package on npmjs.com so they are able to publish the release
-(see Step 6).
-
-## How to publish a release
-
-Before publishing, the following preconditions should be met:
-
-- A release proposal issue or tracking pull request (see "Proposal branch"
-  below) will exist documenting:
-  - the proposed changes
-  - the type of release: patch, minor or major
-  - the version number (according to semantic versioning - https://semver.org)
-- The proposed changes should be complete.
-
-There are two main release flows: patch and non-patch.
-
-The patch flow is for making **patch releases**. As per semantic versioning,
-patch releases are for simple changes, eg: typo fixes, patch dependency updates,
-and simple/low-risk bug fixes. Every other type of change is made via the
-non-patch flow.
-
-### Branch terminology
-
-"Master branch"
-
-- There is a branch in git used for the current major version of Express, named
-  `master`.
-- This branch contains the completed commits for the next patch release of the
-  current major version.
-- Releases for the current major version are published from this branch.
-
-"Version branch"
-
-- For any given major version of Express (current, previous or next) there is
-  a branch in git for that release named `<major-version>.x` (eg: `4.x`).
-- This branch points to the commit of the latest tag for the given major version.
-
-"Release branch"
-
-- For any given major version of Express, there is a branch used for publishing
-  releases.
-- For the current major version of Express, the release branch is the
-  "Master branch" named `master`.
-- For all other major versions of Express, the release branch is the
-  "Version branch" named `<major-version>.x`.
-
-"Proposal branch"
-
-- A branch in git representing a proposed new release of Express. This can be a
-  minor or major release, named `<major-version>.0` for a major release,
-  `<major-version>.<minor-version>` for a minor release.
-- A tracking pull request should exist to document the proposed release,
-  targeted at the appropriate release branch. Prior to opening the tracking
-  pull request the content of the release may have be discussed in an issue.
-- This branch contains the commits accepted so far that implement the proposal
-  in the tracking pull request.
-
-### Pre-release Versions
-
-Alpha and Beta releases are made from a proposal branch. The version number should be
-incremented to the next minor version with a `-beta` or `-alpha` suffix.
-For example, if the next beta release is `5.0.1`, the beta release would be `5.0.1-beta.0`.
-The pre-releases are unstable and not suitable for production use.
-
-### Patch flow
-
-In the patch flow, simple changes are committed to the release branch which
-acts as an ever-present branch for the next patch release of the associated
-major version of Express.
-
-The release branch is usually kept in a state where it is ready to release.
-Releases are made when sufficient time or change has been made to warrant it.
-This is usually proposed and decided using a github issue.
-
-### Non-patch flow
-
-In the non-patch flow, changes are committed to a temporary proposal branch
-created specifically for that release proposal. The branch is based on the
-most recent release of the major version of Express that the release targets.
-
-Releases are made when all the changes on a proposal branch are complete and
-approved. This is done by merging the proposal branch into the release branch
-(using a fast-forward merge), tagging it with the new version number and
-publishing the release package to npmjs.com.
-
-### Flow
-
-Below is a detailed description of the steps to publish a release.
-
-#### Step 1. Check the release is ready to publish
-
-Check any relevant information to ensure the release is ready, eg: any
-milestone, label, issue or tracking pull request for the release. The release
-is ready when all proposed code, tests and documentation updates are complete
-(either merged, closed or re-targeted to another release).
-
-#### Step 2. (Non-patch flow only) Merge the proposal branch into the release branch
-
-In the patch flow: skip this step.
-
-In the non-patch flow:
-```sh
-$ git checkout <release-branch>
-$ git merge --ff-only <proposal-branch>
-```
-
-<release-branch> - see "Release branch" of "Branches" above.
-<proposal-branch> - see "Proposal branch" of "Non-patch flow" above.
-
-> [!NOTE]
-> You may need to rebase the proposal branch to allow a fast-forward
-> merge. Using a fast-forward merge keeps the history clean as it does
-> not introduce merge commits.
-
-### Step 3. Update the History.md and package.json to the new version number
-
-The changes so far for the release should already be documented under the
-"unreleased" section at the top of the History.md file, as per the usual
-development practice. Change "unreleased" to the new release version / date.
-Example diff fragment:
-
-```diff
--unreleased
--==========
-+4.13.3 / 2015-08-02
-+===================
-```
-
-The version property in the package.json should already contain the version of
-the previous release. Change it to the new release version.
-
-Commit these changes together under a single commit with the message set to
-the new release version (eg: `4.13.3`):
-
-```sh
-$ git checkout <release-branch>
-<..edit files..>
-$ git add History.md package.json
-$ git commit -m '<version-number>'
-```
-
-### Step 4. Identify and tag the release commit with the new release version
-
-Create a lightweight tag (rather than an annotated tag) named after the new
-release version (eg: `4.13.3`).
-
-```sh
-$ git tag <version-number>
-```
-
-### Step 5. Push the release branch changes and tag to github
-
-The branch and tag should be pushed directly to the main repository
-(https://github.com/expressjs/express).
-
-```sh
-$ git push origin <release-branch>
-$ git push origin <version-number>
-```
-
-### Step 6. Publish to npmjs.com
-
-Ensure your local working copy is completely clean (no extra or changed files).
-You can use `git status` for this purpose.
-
-```sh
-$ npm login <npm-username>
-$ npm publish
-```
-
-> [!NOTE]
-> The version number to publish will be picked up automatically from 
-> package.json.
-          
-### Step 7. Update documentation website
-
-The documentation website https://expressjs.com/ documents the current release version in various places. To update these, follow these steps:
-
-1. Manually run the [`Update External Docs` workflow](https://github.com/expressjs/expressjs.com/actions/workflows/update-external-docs.yml) in expressjs.com repository.
-2. Add a new section to the [changelog](https://github.com/expressjs/expressjs.com/blob/gh-pages/en/changelog/index.md) in the expressjs.com website.

Triager-Guide.md

@@ -1,72 +0,0 @@
-# Express Triager Guide
-
-## Issue Triage Process
-
-When a new issue or pull request is opened the issue will be labeled with `needs triage`.
-If a triage team member is available they can help make sure all the required information
-is provided. Depending on the issue or PR there are several next labels they can add for further
-classification:
-
-* `needs triage`: This can be kept if the triager is unsure which next steps to take
-* `awaiting more info`: If more info has been requested from the author, apply this label.
-* `bug`: Issues that present a reasonable conviction there is a reproducible bug.
-* `enhancement`: Issues that are found to be a reasonable candidate feature additions.
-
-If the issue is a question or discussion, it should be moved to GitHub Discussions.
-
-### Moving Discussions and Questions to GitHub Discussions
-
-For issues labeled with `question` or `discuss`, it is recommended to move them to GitHub Discussions instead:
-
-* **Questions**: User questions that do not appear to be bugs or enhancements should be moved to GitHub Discussions.
-* **Discussions**: Topics for discussion should be moved to GitHub Discussions. If the discussion leads to a new feature or bug identification, it can be moved back to Issues.
-
-In all cases, issues may be closed by maintainers if they don't receive a timely response when
-further information is sought, or when additional questions are asked.
-
-## Approaches and Best Practices for getting into triage contributions
-
-Review the organization's [StatusBoard](https://expressjs.github.io/statusboard/),
-pay special attention to these columns: stars, watchers, open issues, and contributors.
-This gives you a general idea about the criticality and health of the repository.
-Pick a few projects based on that criteria, your interests, and skills (existing or aspiring).
-
-Review the project's contribution guideline if present. In a nutshell,
-commit to the community's standards and values. Review the
-documentation, for most of the projects it is just the README.md, and
-make sure you understand the key APIs, semantics, configurations, and use cases.
-
-It might be helpful to write your own test apps to re-affirm your
-understanding of the key functions. This may identify some gaps in
-documentation, record those as they might be good PR's to open.
-Skim through the issue backlog; identify low hanging issues and mostly new ones.
-From those, attempt to recreate issues based on the OP description and
-ask questions if required. No question is a bad question!
-
-## Removal of Triage Role
-
-There are a few cases where members can be removed as triagers:
-
-- Breaking the CoC or project contributor guidelines
-- Abuse or misuse of the role as deemed by the TC
-- Lack of participation for more than 6 months
-
-If any of these happen we will discuss as a part of the triage portion of the regular TC meetings.
-If you have questions feel free to reach out to any of the TC members.
-
-## Other Helpful Hints:
-
-- Everyone is welcome to attend the [Express Technical Committee Meetings](https://github.com/expressjs/discussions#expressjs-tc-meetings), and as a triager, it might help to get a better idea of what's happening with the project.
-- When exploring the module's functionality there are a few helpful steps:
-  - Turn on `DEBUG=*` (see https://www.npmjs.com/package/debug) to get detailed log information
-  - It is also a good idea to do live debugging to follow the control flow, try using `node --inspect`
-  - It is a good idea to make at least one pass of reading through the entire source
-- When reviewing the list of open issues there are some common types and suggested actions:
-  - New/unattended issues or simple questions: A good place to start
-  - Hard bugs & ongoing discussions: always feel free to chime in and help
-  - Issues that imply gaps in the documentation: open PRs with changes or help the user to do so
-- For recurring issues, it is helpful to create functional examples to demonstrate (publish as gists or a repo)
-- Review and identify the maintainers. If necessary, at-mention one or more of them if you are unsure what to do
-- Make sure all your interactions are professional, welcoming, and respectful to the parties involved.
-- When an issue refers to security concerns, responsibility is delegated to the repository captain or the security group in any public communication. 
-  - If an issue has been open for a long time, the person in charge should be contacted internally through the private Slack chat.

lib/request.js

@@ -282,12 +282,12 @@ req.is = function is(types) {
  */
 
 defineGetter(req, 'protocol', function protocol(){
-  var proto = this.connection.encrypted
+  var proto = this.socket.encrypted
     ? 'https'
     : 'http';
   var trust = this.app.get('trust proxy fn');
 
-  if (!trust(this.connection.remoteAddress, 0)) {
+  if (!trust(this.socket.remoteAddress, 0)) {
     return proto;
   }
 
@@ -406,7 +406,7 @@ defineGetter(req, 'host', function host(){
   var trust = this.app.get('trust proxy fn');
   var val = this.get('X-Forwarded-Host');
 
-  if (!val || !trust(this.connection.remoteAddress, 0)) {
+  if (!val || !trust(this.socket.remoteAddress, 0)) {
     val = this.get('Host');
   } else if (val.indexOf(',') !== -1) {
     // Note: X-Forwarded-Host is normally only ever a

lib/response.js

@@ -14,6 +14,7 @@
 
 var contentDisposition = require('content-disposition');
 var createError = require('http-errors')
+var deprecate = require('depd')('express');
 var encodeUrl = require('encodeurl');
 var escapeHtml = require('escape-html');
 var http = require('node:http');
@@ -31,6 +32,7 @@ var send = require('send');
 var extname = path.extname;
 var resolve = path.resolve;
 var vary = require('vary');
+const { Buffer } = require('node:buffer');
 
 /**
  * Response prototype.
@@ -825,6 +827,18 @@ res.redirect = function redirect(url) {
     address = arguments[1]
   }
 
+  if (!address) {
+    deprecate('Provide a url argument');
+  }
+
+  if (typeof address !== 'string') {
+    deprecate('Url must be a string');
+  }
+
+  if (typeof status !== 'number') {
+    deprecate('Status must be a number');
+  }
+
   // Set location header
   address = this.location(address).get('Location');
 

lib/utils.js

@@ -18,7 +18,9 @@ var etag = require('etag');
 var mime = require('mime-types')
 var proxyaddr = require('proxy-addr');
 var qs = require('qs');
-var querystring = require('querystring');
+var querystring = require('node:querystring');
+const { Buffer } = require('node:buffer');
+
 
 /**
  * A list of lowercased HTTP methods that are supported by Node.js.

package.json

@@ -39,6 +39,7 @@
     "cookie": "^0.7.1",
     "cookie-signature": "^1.2.1",
     "debug": "^4.4.0",
+    "depd": "^2.0.0",
     "encodeurl": "^2.0.0",
     "escape-html": "^1.0.3",
     "etag": "^1.8.1",
@@ -64,7 +65,7 @@
     "after": "0.8.2",
     "connect-redis": "^8.0.1",
     "cookie-parser": "1.4.7",
-    "cookie-session": "2.1.0",
+    "cookie-session": "2.1.1",
     "ejs": "^3.1.10",
     "eslint": "8.47.0",
     "express-session": "^1.18.1",
@@ -72,7 +73,7 @@
     "marked": "^15.0.3",
     "method-override": "3.0.0",
     "mocha": "^10.7.3",
-    "morgan": "1.10.0",
+    "morgan": "1.10.1",
     "nyc": "^17.1.0",
     "pbkdf2-password": "1.2.1",
     "supertest": "^6.3.0",
@@ -83,13 +84,13 @@
   },
   "files": [
     "LICENSE",
-    "History.md",
     "Readme.md",
     "index.js",
     "lib/"
   ],
   "scripts": {
     "lint": "eslint .",
+    "lint:fix": "eslint . --fix",
     "test": "mocha --require test/support/env --reporter spec --check-leaks test/ test/acceptance/",
     "test-ci": "nyc --exclude examples --exclude test --exclude benchmarks --reporter=lcovonly --reporter=text npm test",
     "test-cov": "nyc --exclude examples --exclude test --exclude benchmarks --reporter=html --reporter=text npm test",

test/express.json.js

@@ -2,6 +2,7 @@
 
 var assert = require('node:assert')
 var AsyncLocalStorage = require('node:async_hooks').AsyncLocalStorage
+const { Buffer } = require('node:buffer');
 
 var express = require('..')
 var request = require('supertest')

test/express.raw.js

@@ -5,6 +5,7 @@ var AsyncLocalStorage = require('node:async_hooks').AsyncLocalStorage
 
 var express = require('..')
 var request = require('supertest')
+const { Buffer } = require('node:buffer');
 
 describe('express.raw()', function () {
   before(function () {

test/express.static.js

@@ -3,6 +3,8 @@
 var assert = require('node:assert')
 var express = require('..')
 var path = require('node:path')
+const { Buffer } = require('node:buffer');
+
 var request = require('supertest')
 var utils = require('./support/utils')
 

test/express.text.js

@@ -2,7 +2,7 @@
 
 var assert = require('node:assert')
 var AsyncLocalStorage = require('node:async_hooks').AsyncLocalStorage
-
+const { Buffer } = require('node:buffer');
 var express = require('..')
 var request = require('supertest')
 

test/express.urlencoded.js

@@ -2,6 +2,7 @@
 
 var assert = require('node:assert')
 var AsyncLocalStorage = require('node:async_hooks').AsyncLocalStorage
+const { Buffer } = require('node:buffer');
 
 var express = require('..')
 var request = require('supertest')

test/req.protocol.js

@@ -39,7 +39,7 @@ describe('req', function(){
         app.enable('trust proxy');
 
         app.use(function(req, res){
-          req.connection.encrypted = true;
+          req.socket.encrypted = true;
           res.end(req.protocol);
         });
 

test/res.append.js

@@ -108,7 +108,7 @@ function shouldHaveHeaderValues (key, values) {
   return function (res) {
     var headers = res.headers[key.toLowerCase()]
     assert.ok(headers, 'should have header "' + key + '"')
-    assert.strictEqual(headers.length, values.length, 'should have ' + values.length + ' occurances of "' + key + '"')
+    assert.strictEqual(headers.length, values.length, 'should have ' + values.length + ' occurrences of "' + key + '"')
     for (var i = 0; i < values.length; i++) {
       assert.strictEqual(headers[i], values[i])
     }

test/res.attachment.js

@@ -1,5 +1,7 @@
 'use strict'
 
+const { Buffer } = require('node:buffer');
+
 var express = require('../')
   , request = require('supertest');
 

test/res.download.js

@@ -3,6 +3,7 @@
 var after = require('after');
 var assert = require('node:assert')
 var AsyncLocalStorage = require('node:async_hooks').AsyncLocalStorage
+const { Buffer } = require('node:buffer');
 
 var express = require('..');
 var path = require('node:path')

test/res.send.js

@@ -1,6 +1,7 @@
 'use strict'
 
 var assert = require('node:assert')
+const { Buffer } = require('node:buffer');
 var express = require('..');
 var methods = require('../lib/utils').methods;
 var request = require('supertest');

test/res.sendFile.js

@@ -3,6 +3,7 @@
 var after = require('after');
 var assert = require('node:assert')
 var AsyncLocalStorage = require('node:async_hooks').AsyncLocalStorage
+const { Buffer } = require('node:buffer');
 
 var express = require('../')
   , request = require('supertest')

test/support/utils.js

@@ -5,6 +5,7 @@
  */
 
 var assert = require('node:assert');
+const { Buffer } = require('node:buffer');
 
 /**
  * Module exports.

test/utils.js

@@ -1,6 +1,7 @@
 'use strict'
 
 var assert = require('node:assert');
+const { Buffer } = require('node:buffer');
 var utils = require('../lib/utils');
 
 describe('utils.etag(body, encoding)', function(){