From e2995a098f8e8c5c1c02eb2b43504b1a032d8737 Mon Sep 17 00:00:00 2001 From: erradim <107002413+erradim@users.noreply.github.com> Date: Tue, 13 Feb 2024 23:03:13 +0100 Subject: [PATCH 01/51] minor spelling mistake (#163) Co-authored-by: Mahmoud <107002413+mahmoud21a@users.noreply.github.com> --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 50686b6..d904f66 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ This repository is used for generalized Express.js discussions. ## Express.js TC meetings -The Express.js Technical Committe (TC) meets online every other week, providing +The Express.js Technical Committee (TC) meets online every other week, providing a live stream of the discussion and a recording of past meetings. Topics for the meetings are determined on an as-needed basis and may be technical or management of nature. From 664d94907390f19fbb05dfe757831d6fd1bfbc48 Mon Sep 17 00:00:00 2001 From: Igor Savin Date: Thu, 29 Feb 2024 01:03:50 +0100 Subject: [PATCH 02/51] Express LTS strategy (#199) * first draft * Update docs/LTS-strategy.md Co-authored-by: Wes Todd * Update docs/LTS-strategy.md Co-authored-by: Wes Todd * Update docs/LTS-strategy.md Co-authored-by: Wes Todd * Update docs/LTS-strategy.md Co-authored-by: Jordan Harband * Update docs/LTS-strategy.md Co-authored-by: Wes Todd * Improve wording * Update docs/LTS-strategy.md Co-authored-by: Jordan Harband * Add clarity on regular semver major cadence --------- Co-authored-by: Igor Savin Co-authored-by: Wes Todd Co-authored-by: Jordan Harband --- docs/LTS-strategy.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 docs/LTS-strategy.md diff --git a/docs/LTS-strategy.md b/docs/LTS-strategy.md new file mode 100644 index 0000000..da89f48 --- /dev/null +++ b/docs/LTS-strategy.md @@ -0,0 +1,42 @@ +# Express LTS Strategy + +## Goals + +* Maintain strict Node.js version support within a single Express major release +* Provide good experience for users who want to keep their Express projects that up-to-date +* Avoid stagnation and blocking innovation that is good for the end users +* Ensure good ergonomics and developer experience for Express maintainers + +## Non-Goals + +* Only support the active LTS releases of Node.js +* Release semver major versions on a regular cadence just for the sake of dropping Node.js version support when there are no clear benefits for doing so, and there are no other breaking changes planned for the release. +* Prioritize "support older Node.js versions" over other factors. We aim to maintain a healthy balance between backwards compatibility and toolchain modernization + +### Rationale behind dropping support for old Node.js versions + +* Avoid blocking Node.js core from making progress and removing deprecated parts of the codebase +* Avoid getting outdated bug reports or security issues +* Keep options open for adopting newer patterns and tooling + +### Rationale behind conservative policy of breaking changes + +* Minimize disruption for end users +* Be mindful of the fact that some users are still running obsolete versions of Node in production + +### Guidelines for dropping support of Node.js versions + +* In order to smoothen the experience of users updating to a new semver major Express version, Express should always support at least one even numbered Node.js version above the current lowest supported one before the drop can be considered. For example, if the lowest supported version is 20, Express support for Node 20 cannot be dropped until Express supports at least Node 22. This ensures that Express updates can be done independently from the Node.js version update. +* Version support removal must come with clear benefits for one of the three - Express users, Express maintainers, or the Node.js core project. Version support is not dropped on a merely time-based basis, or otherwise arbitrarily. +* Any discontinuation of a Node.js version support is always a semver major release. + +### Active branches + +* Several semver major branches will be maintained at the same time while we have overlapping supported versions +* No features are backported to older semver major branches +* Critical bugfixes will be backported to older supported semver major branches +* Security fixes will be backported to older supported semver major branches + +### Release calendar + +* There is a regular cadence of semver major releases (details TBD). However, if no breaking changes were introduced between the last semver major and the scheduled date of the release of the new one, the new semver major release is skipped. \ No newline at end of file From ccd9301a441123f3863098b41b3cb6fa3e98cdaa Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Mon, 11 Mar 2024 14:16:51 -0500 Subject: [PATCH 03/51] feat: use pkgjs/meet to generate meeting agenda (#206) --- .github/ISSUE_TEMPLATE/meeting-tc.md | 43 ++++++++++++++++++++++++++++ .github/workflows/meetings.yml | 26 +++++++++++++++++ 2 files changed, 69 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/meeting-tc.md create mode 100644 .github/workflows/meetings.yml diff --git a/.github/ISSUE_TEMPLATE/meeting-tc.md b/.github/ISSUE_TEMPLATE/meeting-tc.md new file mode 100644 index 0000000..1d04c96 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/meeting-tc.md @@ -0,0 +1,43 @@ +## Date/Time + +| Timezone | Date/Time | +|----------|-----------| +<%= [ + 'America/Los_Angeles', + 'America/Denver', + 'America/Chicago', + 'America/New_York', + 'Europe/London', + 'Europe/Amsterdam', + 'Europe/Moscow', + 'Asia/Kolkata', + 'Asia/Shanghai', + 'Asia/Tokyo', + 'Australia/Sydney' +].map((zone) => { + return `| ${zone} | ${date.setZone(zone).toFormat('EEE dd-MMM-yyyy HH:mm (hh:mm a)')} |` +}).join('\n') %> + +Or in your local time: +* https://www.timeanddate.com/worldclock/?iso=<%= date.toFormat("yyyy-MM-dd'T'HH:mm:ss") %> + +## Agenda + +Extracted from **<%= agendaLabel %>** labelled issues and pull requests from **<%= owner %>/<%= repo %>** prior to the meeting. + +<%= agendaIssues.map((i) => { + return `* ${i.html_url}` +}).join('\n') %> + +## Invited + +@expressjs/express-tc + +## Links + +* Minutes: + +### Joining the meeting + +* link for participants: TBD +* For those who just want to watch: TBD diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml new file mode 100644 index 0000000..c1b864e --- /dev/null +++ b/.github/workflows/meetings.yml @@ -0,0 +1,26 @@ +name: Schedule Meetings +on: + pull_request: + push: + branches: + - main + schedule: + - cron: '0 0 * * 1' +jobs: + build: + runs-on: ubuntu-latest + steps: + - name: Technical Committee + uses: 'pkgjs/meet@v0' + with: + issueTitle: '<%= date.toFormat("yyyy-MM-dd") %> Express TC Meeting' + token: ${{ secrets.GITHUB_TOKEN }} + orgs: expressjs,pillarjs,jshttp + agendaLabel: 'top priority' + meetingLabels: 'meeting' + # We alternate between two time slots: + # 1. Starting on 2024-03-04 at 9pm UTC (2024-03-04T21:00:00.0Z) with a period of 4 weeks (P4W) + # 2. Starting on 2024-03-20 at 9pm UTC (2024-03-20T21:00:00.0Z) with a period of 4 weeks (P4W) + schedules: '2024-03-04T21:00:00.0Z/P4W,2024-03-20T21:00:00.0Z/P4W' + createWithin: 'P1W' + issueTemplate: 'meeting-tc.md' From 913b1601ba0196a87baee06e23202707ab1845c8 Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Tue, 12 Mar 2024 11:09:39 -0500 Subject: [PATCH 04/51] fix: main => master --- .github/workflows/meetings.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index c1b864e..2de33c8 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -3,7 +3,7 @@ on: pull_request: push: branches: - - main + - master schedule: - cron: '0 0 * * 1' jobs: From bb62c4832aec4b9bf4f44a51206f9071baaabbf4 Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Tue, 12 Mar 2024 11:17:45 -0500 Subject: [PATCH 05/51] fix: align meeting period to calendar --- .github/workflows/meetings.yml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 2de33c8..5d7213a 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -7,7 +7,7 @@ on: schedule: - cron: '0 0 * * 1' jobs: - build: + meeting: runs-on: ubuntu-latest steps: - name: Technical Committee @@ -19,8 +19,8 @@ jobs: agendaLabel: 'top priority' meetingLabels: 'meeting' # We alternate between two time slots: - # 1. Starting on 2024-03-04 at 9pm UTC (2024-03-04T21:00:00.0Z) with a period of 4 weeks (P4W) - # 2. Starting on 2024-03-20 at 9pm UTC (2024-03-20T21:00:00.0Z) with a period of 4 weeks (P4W) - schedules: '2024-03-04T21:00:00.0Z/P4W,2024-03-20T21:00:00.0Z/P4W' + # 1. Starting on 2024-03-04 at 9pm UTC (2024-03-04T21:00:00.0Z) with a period of 2 weeks (P2W) + # 2. Starting on 2024-03-20 at 9pm UTC (2024-03-20T21:00:00.0Z) with a period of 2 weeks (P2W) + schedules: '2024-03-04T21:00:00.0Z/P2W,2024-03-20T21:00:00.0Z/P2W' createWithin: 'P1W' issueTemplate: 'meeting-tc.md' From 39ee9a4a2d5645af7040114a1b0ae8303f5da619 Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Sat, 16 Mar 2024 09:28:10 -0500 Subject: [PATCH 06/51] fix: run meeting job every day --- .github/workflows/meetings.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 5d7213a..2a445a6 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -5,7 +5,7 @@ on: branches: - master schedule: - - cron: '0 0 * * 1' + - cron: '0 0 * * *' jobs: meeting: runs-on: ubuntu-latest From 8c37aafd202fb7c1bf24c46d921ee2ff70fe6591 Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Tue, 19 Mar 2024 09:31:50 -0500 Subject: [PATCH 07/51] fix: updated template and split to two meetings --- .../{meeting-tc.md => meeting.md} | 8 +++++-- .github/workflows/meetings.yml | 24 +++++++++++++++---- 2 files changed, 25 insertions(+), 7 deletions(-) rename .github/ISSUE_TEMPLATE/{meeting-tc.md => meeting.md} (66%) diff --git a/.github/ISSUE_TEMPLATE/meeting-tc.md b/.github/ISSUE_TEMPLATE/meeting.md similarity index 66% rename from .github/ISSUE_TEMPLATE/meeting-tc.md rename to .github/ISSUE_TEMPLATE/meeting.md index 1d04c96..c4c2249 100644 --- a/.github/ISSUE_TEMPLATE/meeting-tc.md +++ b/.github/ISSUE_TEMPLATE/meeting.md @@ -31,7 +31,11 @@ Extracted from **<%= agendaLabel %>** labelled issues and pull requests from **< ## Invited +This meeting is open for anyone who wants to attend. Reminder to follow our [Code of Conduct](https://github.com/expressjs/express/blob/master/Code-Of-Conduct.md). + @expressjs/express-tc +@expressjs/triagers +@expressjs/security-wg ## Links @@ -39,5 +43,5 @@ Extracted from **<%= agendaLabel %>** labelled issues and pull requests from **< ### Joining the meeting -* link for participants: TBD -* For those who just want to watch: TBD +* link for participants: https://zoom-lfx.platform.linuxfoundation.org/meeting/95266714809?password=f37cff1b-cb3a-4a21-9425-210e4714c72e +* For those who just want to watch: https://www.youtube.com/@expressjs-official diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 2a445a6..91a9199 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -16,11 +16,25 @@ jobs: issueTitle: '<%= date.toFormat("yyyy-MM-dd") %> Express TC Meeting' token: ${{ secrets.GITHUB_TOKEN }} orgs: expressjs,pillarjs,jshttp + agendaLabel: 'tc agenda' + meetingLabels: 'meeting' + # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 + # Starting on 2024-03-18 at 9pm UTC (2024-03-18T21:00:00.0Z) with a period of 2 weeks (P2W) + schedules: '2024-03-18T21:00:00.0Z/P2W' + createWithin: 'P1W' + issueTemplate: 'meeting.md' + + - name: Working Session + uses: 'pkgjs/meet@v0' + with: + issueTitle: '<%= date.toFormat("yyyy-MM-dd") %> Express Working Session' + token: ${{ secrets.GITHUB_TOKEN }} + orgs: expressjs,pillarjs,jshttp agendaLabel: 'top priority' meetingLabels: 'meeting' - # We alternate between two time slots: - # 1. Starting on 2024-03-04 at 9pm UTC (2024-03-04T21:00:00.0Z) with a period of 2 weeks (P2W) - # 2. Starting on 2024-03-20 at 9pm UTC (2024-03-20T21:00:00.0Z) with a period of 2 weeks (P2W) - schedules: '2024-03-04T21:00:00.0Z/P2W,2024-03-20T21:00:00.0Z/P2W' + # Converting the second time slot to a "working session" + # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 + # Starting on 2024-03-27 at 9pm UTC (2024-03-27T21:00:00.0Z) with a period of 2 weeks (P2W) + schedules: '2024-03-27T21:00:00.0Z/P2W' createWithin: 'P1W' - issueTemplate: 'meeting-tc.md' + issueTemplate: 'meeting.md' From 1e45c74f0245817e71828b7a37aa3859489273e5 Mon Sep 17 00:00:00 2001 From: ctcpip Date: Tue, 6 Aug 2024 17:23:52 -0500 Subject: [PATCH 08/51] =?UTF-8?q?=F0=9F=94=A7=20update=20meeting=20times?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .github/workflows/meetings.yml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 91a9199..aba8cfe 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -19,8 +19,8 @@ jobs: agendaLabel: 'tc agenda' meetingLabels: 'meeting' # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 - # Starting on 2024-03-18 at 9pm UTC (2024-03-18T21:00:00.0Z) with a period of 2 weeks (P2W) - schedules: '2024-03-18T21:00:00.0Z/P2W' + # Starting on 2024-03-18 at 8pm UTC (2024-03-18T21:00:00.0Z) with a period of 2 weeks (P2W) + schedules: '2024-03-18T20:00:00.0Z/P2W' createWithin: 'P1W' issueTemplate: 'meeting.md' @@ -34,7 +34,7 @@ jobs: meetingLabels: 'meeting' # Converting the second time slot to a "working session" # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 - # Starting on 2024-03-27 at 9pm UTC (2024-03-27T21:00:00.0Z) with a period of 2 weeks (P2W) - schedules: '2024-03-27T21:00:00.0Z/P2W' + # Starting on 2024-03-27 at 8pm UTC (2024-03-27T21:00:00.0Z) with a period of 2 weeks (P2W) + schedules: '2024-03-27T20:00:00.0Z/P2W' createWithin: 'P1W' issueTemplate: 'meeting.md' From 91704b5e5d75944fd3c4fa364d473c705841e046 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Mon, 28 Oct 2024 21:31:49 +0100 Subject: [PATCH 09/51] docs: Add ADR template (#291) --- docs/adr/adr-template.md | 74 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 docs/adr/adr-template.md diff --git a/docs/adr/adr-template.md b/docs/adr/adr-template.md new file mode 100644 index 0000000..0709318 --- /dev/null +++ b/docs/adr/adr-template.md @@ -0,0 +1,74 @@ +# ADR template + +This is the base template that we use + +``` +# ADR [Number]: [Title of Decision] + +## Status +[Proposed | Accepted | Deprecated | Superseded by ADR [number]] + +## Submitters +[List of people who proposed this decision. Include GitHub usernames or names with contact information if needed.] +- @username1 +- @username2 + +## Decision Owners +[List of people responsible for driving the decision and following up on its implementation. This may include teams or subject matter experts.] +- @owner1 +- @team1 + +## Context +Describe the problem, need, or feature request that prompted this decision. Include any relevant background information, constraints, and considerations that were taken into account. + +- **Why do we need this decision?** +- **What problem does it solve or avoid?** +- **Are there any existing issues/discussions/pull requests related to this?** (Include links to relevant GitHub issues, forum threads, or discussion channels.) + +## Decision +Clearly state the decision that was made. Describe the chosen solution or approach in detail so that others can understand what was decided. + +- **What will be done?** +- **What will not be done?** (If applicable, specify what was explicitly ruled out.) + +## Rationale +Explain why this decision was made, including a discussion of the alternatives considered and why they were not chosen. + +- **Alternatives Considered:** + - Alternative 1: [Description and reasons for rejection] + - Alternative 2: [Description and reasons for rejection] +- **Pros and Cons**: Outline the pros and cons of the chosen solution. +- **Why is this decision the best option?** (Explain the key factors that influenced this choice.) + +## Consequences +Describe the positive and negative outcomes of the decision, including any potential risks or technical debt. + +- **Positive Impact**: What benefits does this decision bring to the project? +- **Negative Impact**: What challenges or limitations does this introduce? +- **Mitigations**: How will we address potential drawbacks or issues? + +## Implementation +(Optional, if relevant) +Outline the steps required to implement the decision. This section is particularly useful if the decision involves a series of actions or a roadmap. + +- **Phase 1**: [Description] +- **Phase 2**: [Description] +- **Estimated Effort**: Provide a rough estimate of time or effort needed. + +## References +Include any external links, documents, discussions, or research that were referenced during the decision-making process. + +- [Link to relevant GitHub issue or pull request](#) +- [Link to forum discussion](#) +- [Documentation or research sources](#) + + +## Changelog +Track changes or updates to this ADR over time. Include the date, author, and a brief description of each change. + +- **[YYYY-MM-DD]**: [@username] - [Brief description of the change] + - Example: **[2024-10-22]**: @owner1 - Updated the decision to include support for Redis caching. +- **[YYYY-MM-DD]**: [@username] - [Brief description of the change] + - Example: **[2025-01-15]**: @username2 - Deprecated this ADR due to a shift in the database strategy. + +``` \ No newline at end of file From 2ee2a5aaa6619744c44034482f6f64eee1bd9a84 Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Wed, 6 Nov 2024 11:07:13 +0000 Subject: [PATCH 10/51] feat: add funding use guidelines (#299) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: ctcpip Co-authored-by: Ulises Gascón --- docs/adr/adr-template.md | 18 +++++++++++--- docs/adr/funding-guidelines.md | 44 ++++++++++++++++++++++++++++++++++ 2 files changed, 59 insertions(+), 3 deletions(-) create mode 100644 docs/adr/funding-guidelines.md diff --git a/docs/adr/adr-template.md b/docs/adr/adr-template.md index 0709318..d06f6f9 100644 --- a/docs/adr/adr-template.md +++ b/docs/adr/adr-template.md @@ -2,23 +2,30 @@ This is the base template that we use -``` +```md + # ADR [Number]: [Title of Decision] ## Status + [Proposed | Accepted | Deprecated | Superseded by ADR [number]] ## Submitters + [List of people who proposed this decision. Include GitHub usernames or names with contact information if needed.] + - @username1 - @username2 ## Decision Owners + [List of people responsible for driving the decision and following up on its implementation. This may include teams or subject matter experts.] + - @owner1 - @team1 ## Context + Describe the problem, need, or feature request that prompted this decision. Include any relevant background information, constraints, and considerations that were taken into account. - **Why do we need this decision?** @@ -26,12 +33,14 @@ Describe the problem, need, or feature request that prompted this decision. Incl - **Are there any existing issues/discussions/pull requests related to this?** (Include links to relevant GitHub issues, forum threads, or discussion channels.) ## Decision + Clearly state the decision that was made. Describe the chosen solution or approach in detail so that others can understand what was decided. - **What will be done?** - **What will not be done?** (If applicable, specify what was explicitly ruled out.) ## Rationale + Explain why this decision was made, including a discussion of the alternatives considered and why they were not chosen. - **Alternatives Considered:** @@ -41,6 +50,7 @@ Explain why this decision was made, including a discussion of the alternatives c - **Why is this decision the best option?** (Explain the key factors that influenced this choice.) ## Consequences + Describe the positive and negative outcomes of the decision, including any potential risks or technical debt. - **Positive Impact**: What benefits does this decision bring to the project? @@ -48,6 +58,7 @@ Describe the positive and negative outcomes of the decision, including any poten - **Mitigations**: How will we address potential drawbacks or issues? ## Implementation + (Optional, if relevant) Outline the steps required to implement the decision. This section is particularly useful if the decision involves a series of actions or a roadmap. @@ -56,14 +67,15 @@ Outline the steps required to implement the decision. This section is particular - **Estimated Effort**: Provide a rough estimate of time or effort needed. ## References + Include any external links, documents, discussions, or research that were referenced during the decision-making process. - [Link to relevant GitHub issue or pull request](#) - [Link to forum discussion](#) - [Documentation or research sources](#) - ## Changelog + Track changes or updates to this ADR over time. Include the date, author, and a brief description of each change. - **[YYYY-MM-DD]**: [@username] - [Brief description of the change] @@ -71,4 +83,4 @@ Track changes or updates to this ADR over time. Include the date, author, and a - **[YYYY-MM-DD]**: [@username] - [Brief description of the change] - Example: **[2025-01-15]**: @username2 - Deprecated this ADR due to a shift in the database strategy. -``` \ No newline at end of file +``` diff --git a/docs/adr/funding-guidelines.md b/docs/adr/funding-guidelines.md new file mode 100644 index 0000000..2c43854 --- /dev/null +++ b/docs/adr/funding-guidelines.md @@ -0,0 +1,44 @@ +--- +name: Funding Use Guidelines +description: Guidelines for spending project funding +labels: ADR +--- + +# ADR [Number]: Funding Use Guidelines + +## Status + +Proposed + +## Submitters + +- @ctcpip +- @UlisesGascon +- @wesleytodd + +## Decision Owners + +- @expressjs/express-tc + +## Context + +We have an Open Collective but we originally decided to wait on setting guidelines for how we will spend the funds. Now that we have landed PRs to include the `funding` field in `package.json` and also a link in the footer of the website, we wanted to have some loose guidelines so contributors know a little about how we intend to use financial support for the project. + +## Decision + +Funds are not automatically distributed. + +TC members may request funds to be distributed for the following purposes: + +- Living expenses (food, shelter, medicine/healthcare, transportation, utilities) + - The requester need not specify any detail other than the amount being requested. +- Travel (hotel and airfare) to events related to Express or the greater Node/JS ecosystem. _Legal Requirement: at least 18 years old and recognized as adults in both the country of departure and the destination country, based on local laws (ref: [Age of Majority](https://en.wikipedia.org/wiki/Age_of_majority))_ + - The requester should specify the event, location, and cost estimates for hotel and airfare. +- Equipment and hardware (devices, screens, internet services) + - The requester should specify the type of equipment or service needed and how it relates to their work on Express. + +Requests will be reviewed at the next possible opportunity, privately during an Express TC meeting. The Express TC also reserves the right to amend these guidelines via our standard decision making process. + +## Implementation + +Once approved, we will add this doc to the appropriate places within our project documentation (the contributing guide, website, OC landing page, etc). From 4cbf46e4d75b9aa80615723f89411e9aefe50d84 Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Sun, 1 Dec 2024 21:28:31 -0500 Subject: [PATCH 11/51] ci: follow 'agenda' label --- .github/workflows/meetings.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index aba8cfe..55e4113 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -30,7 +30,7 @@ jobs: issueTitle: '<%= date.toFormat("yyyy-MM-dd") %> Express Working Session' token: ${{ secrets.GITHUB_TOKEN }} orgs: expressjs,pillarjs,jshttp - agendaLabel: 'top priority' + agendaLabel: 'top priority, agenda' meetingLabels: 'meeting' # Converting the second time slot to a "working session" # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 From 2b598a7059bd15b4af8fd26a667f019502eaeb12 Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Fri, 10 Jan 2025 15:36:22 -0500 Subject: [PATCH 12/51] fix: update meeting links and schedules in templates --- .github/ISSUE_TEMPLATE/meeting.md | 2 +- .github/workflows/meetings.yml | 10 ++++++---- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/meeting.md b/.github/ISSUE_TEMPLATE/meeting.md index c4c2249..f9843c7 100644 --- a/.github/ISSUE_TEMPLATE/meeting.md +++ b/.github/ISSUE_TEMPLATE/meeting.md @@ -43,5 +43,5 @@ This meeting is open for anyone who wants to attend. Reminder to follow our [Cod ### Joining the meeting -* link for participants: https://zoom-lfx.platform.linuxfoundation.org/meeting/95266714809?password=f37cff1b-cb3a-4a21-9425-210e4714c72e +* link for participants: <%= meetingLink %> * For those who just want to watch: https://www.youtube.com/@expressjs-official diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 55e4113..1f9f626 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -19,9 +19,10 @@ jobs: agendaLabel: 'tc agenda' meetingLabels: 'meeting' # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 - # Starting on 2024-03-18 at 8pm UTC (2024-03-18T21:00:00.0Z) with a period of 2 weeks (P2W) - schedules: '2024-03-18T20:00:00.0Z/P2W' + # Starting on 2024-03-18 at 9pm UTC (2024-03-18T21:00:00.0Z) with a period of 2 weeks (P2W) + schedules: '2024-03-18T21:00:00.0Z/P2W' createWithin: 'P1W' + meetingLink: 'https://zoom-lfx.platform.linuxfoundation.org/meeting/95266714809?password=f37cff1b-cb3a-4a21-9425-210e4714c72e' issueTemplate: 'meeting.md' - name: Working Session @@ -34,7 +35,8 @@ jobs: meetingLabels: 'meeting' # Converting the second time slot to a "working session" # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 - # Starting on 2024-03-27 at 8pm UTC (2024-03-27T21:00:00.0Z) with a period of 2 weeks (P2W) - schedules: '2024-03-27T20:00:00.0Z/P2W' + # Starting on 2024-03-27 at 9pm UTC (2024-03-27T21:00:00.0Z) with a period of 2 weeks (P2W) + schedules: '2024-03-27T21:00:00.0Z/P2W' createWithin: 'P1W' + meetingLink: 'https://zoom-lfx.platform.linuxfoundation.org/meeting/95258037175?password=07aad89d-ff43-45df-9b28-f437e167a0b9' issueTemplate: 'meeting.md' From 2f80a635281693dacceddd35788a5da64b610807 Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Thu, 20 Feb 2025 09:51:37 -0600 Subject: [PATCH 13/51] Fix: remove agenda from working session labels --- .github/workflows/meetings.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 1f9f626..1518849 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -31,7 +31,7 @@ jobs: issueTitle: '<%= date.toFormat("yyyy-MM-dd") %> Express Working Session' token: ${{ secrets.GITHUB_TOKEN }} orgs: expressjs,pillarjs,jshttp - agendaLabel: 'top priority, agenda' + agendaLabel: 'top priority' meetingLabels: 'meeting' # Converting the second time slot to a "working session" # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 From ba5642ec536e4a378673f8a9ce852a03fe8a4ef6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Mon, 3 Mar 2025 22:24:00 +0100 Subject: [PATCH 14/51] docs: add policy on using caret (^) or tilde (~) with dependencies (#290) Signed-off-by: Ulises Gascon Co-authored-by: Chris de Almeida Co-authored-by: Wes Todd --- ...policy-on-using-caret-with-dependencies.md | 82 +++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 docs/adr/002-policy-on-using-caret-with-dependencies.md diff --git a/docs/adr/002-policy-on-using-caret-with-dependencies.md b/docs/adr/002-policy-on-using-caret-with-dependencies.md new file mode 100644 index 0000000..70daef0 --- /dev/null +++ b/docs/adr/002-policy-on-using-caret-with-dependencies.md @@ -0,0 +1,82 @@ +# ADR 002: Policy on Using Caret (`^`) or tilde (`~`) with Dependencies in `package.json` + +## Status +Proposed + +## Submitters +- Ulises Gascón (@UlisesGascon) + +## Decision Owners +- Express TC (@expressjs/express-tc) + +## Context +Historically, the Express project has avoided using the caret (`^`) in the `package.json` files for its own dependencies. This proposal aims to review whether this practice should continue or if adjustments are needed. + +**Why do we need this decision?** +Clarifying the policy on using caret (`^`) helps to ensure consistency across the Express ecosystem, reduce unnecessary maintenance, and prevent unexpected dependency updates. It also addresses concerns about the balance between keeping dependencies up-to-date and avoiding regressions. + +**What problem does it solve or avoid?** +This decision aims to reduce the maintenance burden of frequently updating pinned dependencies. + +**Are there any existing issues/discussions/pull requests related to this?** +- [Discussion: Using caret (^) with our own dependencies #279](https://github.com/expressjs/discussions/issues/279) +- [expressjs/express#6017 (comment)](https://github.com/expressjs/express/issues/6017) + +## Decision +We will adopt a policy where the caret (`^`) symbol is used for dependencies all dependencies. + +**What will be done?** +- Update the `package.json` files to use `^` for all dependencies (both prod and dev). + +**Note on `^` vs. `~`:** +- `^` allows updates to the most recent minor or patch version, offering greater flexibility and reducing the need for frequent manual updates. For example, `^1.2.3` will accept updates to `1.3.0`, `1.4.0`, but not `2.0.0`. +- `~` is more conservative, only allowing updates to patch versions. For example, `~1.2.3` will accept updates to `1.2.4`, `1.2.5`, but not `1.3.0`. Some Node.js legacy versions only support this, like Node@0.8. + +**What will not be done?** +- We won't force to use `^` or `~` for any dependency if there is a reason to use a pinned version and it is properly documented. + +## Rationale + +**Alternatives Considered:** +- **Alternative:** Continue pinning all dependencies, including internal ones, to specific versions. +- **Reason for rejection:** This approach requires frequent updates and increases the maintenance burden, as each minor or patch update requires a new release. + +**Pros and Cons**: + +**Pros**: +- Reduces the number of PRs for updating our own dependencies. +- Allows for quicker adoption of minor and patch updates within the Express ecosystem. +- Users are still protected by lockfiles, mitigating the risk of regressions. + +**Cons**: +- There is still a risk of minor regressions from updates, even within internally managed dependencies. +- Requires discipline in maintaining lockfiles to ensure stability for end users. + +**Why is this decision the best option?** +This decision strikes a balance between reducing maintenance effort and managing risk. It allows Express to leverage the benefits of semver for our own dependencies while maintaining control over external libraries that could introduce breaking changes. + +## Consequences + +**Positive Impact**: +- Fewer manual updates required for internally managed dependencies. +- Users benefit from improvements and fixes in internal packages more quickly. + +**Negative Impact**: +- Potential risk of regressions if an internal dependency introduces a breaking change in a minor update. +- Users relying on strict version control may need to adjust their expectations when using our own dependencies. + +**Mitigations**: +- Strong test coverage and CI checks will help catch potential issues early. +- Clear communication in documentation and release notes to inform users of the updated dependency policy. +- Ensure that we are following strict semver when releasing our own libraries. + +## Implementation + +- **Phase 1**: Update `package.json` files across all packages to apply `^` for all dependencies which support greater than node@0.10.0. +- **Phase 2**: Review and adjust documentation to include the new policy on dependency versioning. + +## References +- [NPM semver documentation](https://docs.npmjs.com/cli/v6/using-npm/semver) + +## Changelog +- **[2024-10-22]**: @UlisesGascon - Initial draft of ADR for using caret (`^`) or tilde (`~`) with our own dependencies. From b6a317f1f5824581ca3b8818f0d9ae45d9ae090d Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Tue, 4 Mar 2025 09:26:19 -0500 Subject: [PATCH 15/51] feat: add triage meetings (#284) * add triage meeting workflow * chore: change date of meeting --- .github/ISSUE_TEMPLATE/meeting-triage.md | 56 ++++++++++++++++++++++++ .github/workflows/meetings.yml | 13 ++++++ 2 files changed, 69 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/meeting-triage.md diff --git a/.github/ISSUE_TEMPLATE/meeting-triage.md b/.github/ISSUE_TEMPLATE/meeting-triage.md new file mode 100644 index 0000000..546aa15 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/meeting-triage.md @@ -0,0 +1,56 @@ +## Date/Time + +| Timezone | Date/Time | +|----------|-----------| +<%= [ + 'America/Los_Angeles', + 'America/Denver', + 'America/Chicago', + 'America/New_York', + 'Europe/London', + 'Europe/Amsterdam', + 'Europe/Moscow', + 'Asia/Kolkata', + 'Asia/Shanghai', + 'Asia/Tokyo', + 'Australia/Sydney' +].map((zone) => { + return `| ${zone} | ${date.setZone(zone).toFormat('EEE dd-MMM-yyyy HH:mm (hh:mm a)')} |` +}).join('\n') %> + +Or in your local time: +* https://www.timeanddate.com/worldclock/?iso=<%= date.toFormat("yyyy-MM-dd'T'HH:mm:ss") %> + +## Links + +* Minutes Google Doc: + +## Agenda + +Extracted from **<%= agendaLabel %>** labelled issues and pull requests from **<%= owner %>/<%= repo %>** prior to the meeting. + +<%= agendaIssues.map((i) => { + return `* ${i.html_url}` +}).join('\n') %> + +## Invited + +This meeting is open for anyone who wants to attend. Reminder to follow our [Code of Conduct](https://github.com/expressjs/express/blob/master/Code-Of-Conduct.md). + +- Triage team: @expressjs/triagers + +### Observers/Guests + +## Joining the meeting + +* link for participants: https://zoom-lfx.platform.linuxfoundation.org/meeting/99366452429?password=13cb3704-9041-4556-a409-85e7384b53fd +* For those who just want to watch: https://www.youtube.com/@expressjs-official + +
+ +Please use the following emoji reactions in this post to indicate your +availability. + +- 👍 - Attending +- 👎 - Not attending +- 😕 - Not sure yet diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 1518849..0b2ac00 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -40,3 +40,16 @@ jobs: createWithin: 'P1W' meetingLink: 'https://zoom-lfx.platform.linuxfoundation.org/meeting/95258037175?password=07aad89d-ff43-45df-9b28-f437e167a0b9' issueTemplate: 'meeting.md' + - name: Triage Working Session + uses: 'pkgjs/meet@v0' + with: + issueTitle: '<%= date.toFormat("yyyy-MM-dd") %> Express Triage Session' + token: ${{ secrets.GITHUB_TOKEN }} + orgs: expressjs,pillarjs,jshttp + agendaLabel: 'triage-meeting' + meetingLabels: 'meeting' + # https://github.com/expressjs/discussions/issues/276#issuecomment-2399741373 + # Starting on 2025-01-27 at 8pm UTC (2025-01-27T20:00:00.0Z) with a period of 4 weeks (P4W) + schedules: '2025-01-27T20:00:00.0Z/P4W' + createWithin: 'P1W' + issueTemplate: 'meeting-triage.md' From cb91f5f2ceabe616fddaaa085e2278f5f1bf220d Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Thu, 17 Apr 2025 09:43:51 -0500 Subject: [PATCH 16/51] feat(adr): establish a performance working group (#306) * feat(rfc): establish a performance working group * Update docs/adr/performance-wg.md Co-authored-by: Sebastian Beltran * Update docs/adr/performance-wg.md * fix: some review edits * Update docs/adr/performance-wg.md --------- Co-authored-by: Sebastian Beltran --- docs/adr/performance-wg.md | 75 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 docs/adr/performance-wg.md diff --git a/docs/adr/performance-wg.md b/docs/adr/performance-wg.md new file mode 100644 index 0000000..8876b23 --- /dev/null +++ b/docs/adr/performance-wg.md @@ -0,0 +1,75 @@ +# ADR #306: Performance Working Group + +## Status + +Proposed + +## Submitters + +- @wesleytodd + +## Decision Owners + +- @expressjs/express-tc + +## Context + +Express has traditionally taken a very lax approach to performance. Historically this has meant poor outcomes with +and lack of visibility around how changes impact performance. The goal of this working +group is to centralize discussion so the whole ecosystem of packages can benefit from targeted performance work. The +scope of this WG would be all active packages in the `expressjs`, `pillarjs` and `jshttp` orgs with an initial focus on +the ones which are direct dependencies of `express` itself. + +**Why do we need a working group?** + +The current state is we have many open PRs, in flight initiatives, and planned future work. With a loose approach we +can easily have duplicated work, conflicting approaches, or focus on the wrong outcomes. By giving this WG scope over +this we can centralize the discussion and plans so that we unlock better and faster work in the individual packages. + +Additionally, there will be continued long term work to monitor and maintain the tooling. The WG structure gives a clear +place for users, contributors, and other interested parties to go so it is less difficult to find across the many org's +and repositories the project owns. + +## Decision + +Similar to the Security WG, we will setup a new repo (expressjs/perf-wg) and corresponding plan of action. The WG will +be delegated responsibility for driving concensus on initiatives within scope. This group will have three primary goals: + +1. Organize the effort. We want to make sure we are not rebuilding the same things or having the same disucssions in + many package repos at once. +2. Provide and maintain tooling for all the packages/repos to produce reliable performance metrics and benchmarks. + Examples include: workflows, infra and guidelines on types of benchmarks +3. Proritize and execute performance improvements across the packages. These do not need to be done *by* the members of + the WG, but it would be good if we could get reviews by the team we will setup to ensure folks with most experience + can help address performance issues across the project. + +We will need to take a few actions to get this started: + +1. Create a new `perf-wg` repo +2. Create teams: `@expressjs/perf-wg`, `@pillarjs/perf-wg`, `@jshttp/perf-wg` +3. Write charter/goals doc in the new repo +4. Schedule a recurring (monthly) meeting + +### Relation to STF + +Lastly, this kicko-off work is being funded by the STF program. It is a part of our larger work around security +improvements for the project. There are two parts of that program which fall under this WG's purview: + +1. Milestone 6: Monitor performance across Express and direct dependencies + - Owner: @wesleytodd + - Delivery Date: Dec 31, 2025 + - Estimated Budget: €25,200 +2. Milestone 9: Improve performance for Express and critical dependencies + - Owner: @wesleytodd & @blakeembrey + - Delivery Date: Jun 30, 2026 + - Estimated Budget: €46,200 + +This funding does not mean the work can only be done by the owners, it just means that we are responsible for organizing +and executing on the deliverables. This is our first attempt at doing a program like this, so feedback is welcome. + +## References + +- https://github.com/expressjs/express/pull/6129 +- https://github.com/expressjs/express/issues/5998 +- open-telemetry/opentelemetry-js-contrib#2437 +- openjs-foundation/infrastructure#5 From cd3452917459a16d91b60f58b781d868dcc23e5e Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Thu, 17 Apr 2025 10:07:45 -0500 Subject: [PATCH 17/51] feat(docs): move some documentations and charters (#353) * move some documentations and charters * docs: update captains and committers list for body-parser * feat: add governance docs --- docs/CHARTER.md | 92 +++++++++ docs/GOVERNANCE.md | 184 +++++++++++++++++ docs/contributing/captains_and_committers.md | 83 ++++++++ docs/contributing/readme-guide.md | 123 +++++++++++ docs/contributing/release-process.md | 202 +++++++++++++++++++ docs/contributing/triager-guide.md | 72 +++++++ 6 files changed, 756 insertions(+) create mode 100644 docs/CHARTER.md create mode 100644 docs/GOVERNANCE.md create mode 100644 docs/contributing/captains_and_committers.md create mode 100644 docs/contributing/readme-guide.md create mode 100644 docs/contributing/release-process.md create mode 100644 docs/contributing/triager-guide.md diff --git a/docs/CHARTER.md b/docs/CHARTER.md new file mode 100644 index 0000000..1f86bbd --- /dev/null +++ b/docs/CHARTER.md @@ -0,0 +1,92 @@ +# 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 \ No newline at end of file diff --git a/docs/GOVERNANCE.md b/docs/GOVERNANCE.md new file mode 100644 index 0000000..5dd4be7 --- /dev/null +++ b/docs/GOVERNANCE.md @@ -0,0 +1,184 @@ +# 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 + +The list can be found at [https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#active-projects-and-members](https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#active-projects-and-members) + +### Current Initiative Captains + +The list can be found at [https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#current-initiative-captains](https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#current-initiative-captains) + +## 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. +``` \ No newline at end of file diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md new file mode 100644 index 0000000..eebb041 --- /dev/null +++ b/docs/contributing/captains_and_committers.md @@ -0,0 +1,83 @@ +### Active Projects and members + +- [`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): + - Captains: @wesleytodd, @jonchurch, @ulisesGascon + - Committers: @Phillip9587 +- [`expressjs/codemod`](https://github.com/expressjs/codemod): @bjohansebas (npm: `@bsebas`), @kjugi (npm: `@filip.kudla`) +- [`expressjs/compression`](https://github.com/expressjs/compression): + - captains: @UlisesGascon + - committers: @bjohansebas +- [`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): + - captains: @wesleytodd, @ulisesGascon + - committers: @bjohansebas, @Phillip9587 +- [`expressjs/expressjs.com`](https://github.com/expressjs/expressjs.com): + - captains: @crandmck, @jonchurch, @bjohansebas + - committers: @carlosstenzel, @chrisdel101 +- [`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): + - Captains: @ulisesGascon + - Committers: @carpasse +- [`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): + - Captains: @ulisesGascon + - Committers: @bjohansebas +- [`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): + - captains: @wesleytodd, @ulisesGascon + - committers: @Phillip9587 +- [`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 \ No newline at end of file diff --git a/docs/contributing/readme-guide.md b/docs/contributing/readme-guide.md new file mode 100644 index 0000000..03edbd2 --- /dev/null +++ b/docs/contributing/readme-guide.md @@ -0,0 +1,123 @@ +# 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]` +- test coverage: `[![Test Coverage][coveralls-image]][coveralls-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. \ No newline at end of file diff --git a/docs/contributing/release-process.md b/docs/contributing/release-process.md new file mode 100644 index 0000000..32efc20 --- /dev/null +++ b/docs/contributing/release-process.md @@ -0,0 +1,202 @@ +# 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 `.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 `.x`. + +"Proposal branch" + +- A branch in git representing a proposed new release of Express. This can be a + minor or major release, named `.0` for a major release, + `.` 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 +$ git merge --ff-only +``` + + - see "Release branch" of "Branches" above. + - 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 +<..edit files..> +$ git add History.md package.json +$ git commit -m '' +``` + +### 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 +``` + +### 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 +$ git push origin +``` + +### 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 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. \ No newline at end of file diff --git a/docs/contributing/triager-guide.md b/docs/contributing/triager-guide.md new file mode 100644 index 0000000..65aff26 --- /dev/null +++ b/docs/contributing/triager-guide.md @@ -0,0 +1,72 @@ +# 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. \ No newline at end of file From 694cdf0326e40a1ea05ba95bc8ee9bd395cd7406 Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Fri, 18 Apr 2025 11:00:32 -0500 Subject: [PATCH 18/51] feat(ADR): LTS Strategy (#352) * feat(ADR): LTS Strategy * Update docs/adr/lts-strategy.md Co-authored-by: Zbyszek Tenerowicz * Update docs/adr/lts-strategy.md Co-authored-by: Zbyszek Tenerowicz * fix: suggestions * fix: updated dates from discussion https://github.com/expressjs/expressjs.com/pull/1859#discussion_r2023125795 * fix: review edits * fix: formatting * Update docs/adr/lts-strategy.md Co-authored-by: Chris de Almeida --------- Co-authored-by: Zbyszek Tenerowicz Co-authored-by: Chris de Almeida --- docs/adr/lts-strategy.md | 172 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 docs/adr/lts-strategy.md diff --git a/docs/adr/lts-strategy.md b/docs/adr/lts-strategy.md new file mode 100644 index 0000000..2525c74 --- /dev/null +++ b/docs/adr/lts-strategy.md @@ -0,0 +1,172 @@ +# ADR [Number]: LTS Strategy and Support Schedule + +## Status + +Proposed + +## Submitters + +- @wesleytodd + +## Decision Owners + +- @expressjs/express-tc + +## Context + +Conversation about our LTS strategy, support dates for our major release lines, and how we should message this content +has been spread out across multiple issues, repos, slack channels, and meetings. We have landed a few starter documents, +and generally have agreed on our goals/strategy but we have not officially documented and centralized that. This ADR is +both gathering all that context to one place as well as give concrete decisions and next steps. + +### Scope: + +This ADR applies to, and should cover, all repositories within the Express Projects three orgs (`jshttp`, `pillarjs`, +`expressjs`). While everything stems from support for the primary `express` package, due to the coupling of many of our +dependency and middleware packages, we must also address those packages as well. + +### ADR Goals: + +- Improve documentation on our support goals +- Document criteria and reasoning for when to release new majors +- Define life cycle for releases, terminology we will use, +- Improve documentation on how our LTS relates to Node.js version support +- Documentation on how our LTS relates to our direct dependencies and other Express project repos/packages +- Set clear next steps for documenting and publicising the LTS strategy +- Select dates for known release line support and EOL +- Create starter language and graphics for our future blog posts, website additions, and other necessary docs + +### ADR Non-Goals: + +- Create an end-user documentation resource (either for immediate use or future use) +- Commit to future release dates + +**Existing issues/discussions/pull requests related to this:** + +- Initial LTS strategy doc: https://github.com/expressjs/discussions/blob/master/docs/LTS-strategy.md +- Additional LTS doc proposal: https://github.com/expressjs/admin/pull/3 +- https://github.com/ctcpip/express-release +- Some other related discussions: + - https://github.com/expressjs/discussions/issues/196 + - https://github.com/expressjs/discussions/issues/172 + - https://github.com/expressjs/discussions/issues/67 +- TC Slack Discussion: https://openjs-foundation.slack.com/archives/C06KMCETHG9/p1724863852681889 + +### Package/Repository Types + +We maintain four primary types of packages/repos: + +1. `express`: The minimal http framework +2. `express` dependencies: Libraries which are used directly or transitively within `express` and also by others outside + of the project +3. Middleware: Libraries for use *with* `express` but not installed with it directly +4. Others: Tools, documentation, websites, resources, etc. + +While much of this proposal is targeted specifically at `express`, this terminology will be used to differentiate where +we are not only talking about `express`. + +## Decision + +The Express project will have a well defined Long Term Support (LTS) strategy and schedule based on the following +requirements: + +- `express` major versions will go through three supported phases: Current, Active, & Maintenance + - `CURRENT`: A new major version is designated as `CURRENT` upon release. It is available but not the `latest` version + on npm for a minimum of 3 months. + - `ACTIVE`: After the minimum 3 month period and the TC agrees it is stable and secure, the `ACTIVE` version is + tagged `latest` on npm for a minimum of 12 months. + - `MAINTENANCE`: When a new major version becomes `ACTIVE`, the previous major version enters `MAINTENANCE` for a minimum of 12 months. +- After the `MAINTENANCE` time has ended the major version is considered `EOL` and is unsupported. +- During the `ACTIVE` period, a new major version may be released but *not* until at least 12 months have passed + since the `CURRENT` version became `ACTIVE`. +- Users are required to follow the head/latest of each major release line for support with all packages (`express`, + dependencies, middleware, & tools/other) +- If we have no necessary breaking changes, we will not release a new major version. Applies to `express`, + dependencies, middleware, & tools/other. +- Dropping old Node.js versions *alone* is not enough of a breaking change to release a new major version. Applies to + `express`, dependencies, middleware, & tools/other. +- `express` version 4.x is considered a special case. It will receive a longer `MAINTENENCE` phase of 18 months or until + the TC agrees we are safe cutting support. +- `express` dependency packages will follow the same timeline and support dates for the `express` version which they are + included with. +- Middleware packages should follow the timeline and support dates for the `express` versions they are compatible, but + should make reasonable and informed decisions which can deviate if necessary. +- All other packages are suggested to define an appropriate strategy for support. + +### Node.js Version Support + +While we recognize that runtime support needs to be tightly aligned with our LTS policy, it is out of scope for this +ADR and will be addressed in a separate proposal. + +### Life Cycle Phases & Meaning + +#### CURRENT + +- New majors will go through a short period of hardening to ensure stability, security, and ecosystem libraries/resources + compatibility. +- We will strive to ensure no breaking changes are included, but reserve the right to make security or high priority + fixes of breaking nature within this period. +- `CURRENT` lines will receive all types of active work including: bug fixes, security patches, new features, and + deprecation notices. +- Users are recommended to use `CURRENT` lines and to upgrade as quickly as their risk profile allows + +#### ACTIVE + +- `ACTIVE` lines will receive all types of active work including: bug fixes, security patches, new features, and + deprecation notices. +- For users, `ACTIVE` lines are considered the most stable and well supported version at any given time. + +#### MAINTENANCE + +- `MAINTENANCE` lines will only receive security patches or high priority bug fixes. +- Users are highly encouraged to upgrade to a `CURRENT` or `ACTIVE` release. + +### Schedule + +For the existing release lines, we will set the following phase dates: + + +| Major | CURRENT | ACTIVE | MAINTENANCE | EOL | +| ----- | ------- | ------ | ----------- | --- | +| 4.x | | | 2025-04-01 | [1] no sooner than 2026-10-01 | +| 5.x | 2024-09-11 | 2025-03-31 | [2]TBD | [2]TBD | +| 6.x | [3]TBD | | | | + +1. v4 is a special case, and we may extend MAINTENENCE support. This date is called out to give users confidence we will + not end-of-life *earlier* than this date. +2. v5 MAINTENENCE and EOL dates are determined by when v6 is released. We will update them when v6 release dates are + committed to. +3. v6 work has not started yet. The earliers we could choose to release by this proposal is 2026-01-01. We will update + these dates when we commit to them. + +### Documentation + +The project will maintain two types of documentation for this: + +#### Project documentation for the maintainers: + +This includes this doc, but also detailed things about the process that are not necessary for anyone but us. This +documentation will live in one of two places: + +1. The `discussions` repo. If the content applies to more than one repo/package in any of the three orgs, is general in + nature, or otherwise has no logical other place to go it goes here. +2. The individual repo/package to which it applies. If an individual package has more detailed or different needs the + docs will live along with the repo as decided by the captains. + +#### User documentation: + +This will be produced for the website. While the source content of it may live in other places (for example a repo to +produce an image for the schedule), the users will be directed to the website to view the current updated version. This +will also co-locate with documentation about Node.js support and other related support content. + +#### Next steps: + +- Update the existing LTS doc with more details from this decision +- Update website pages with more details from this decision +- Close out discussions and other PRs related to this + +## Changelog + +Track changes or updates to this ADR over time. Include the date, author, and a brief description of each change. + +- **[2025-02-28]**: [@wesleytodd] - Initial draft From f487fde8cfb95be7503763d8dd2bf72d06e202c0 Mon Sep 17 00:00:00 2001 From: Chris de Almeida Date: Mon, 12 May 2025 16:08:13 -0500 Subject: [PATCH 19/51] =?UTF-8?q?=E2=9C=A8=20ADR:=20action=20pinning=20(#3?= =?UTF-8?q?66)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * ✨ ADR: action pinning * 📝 strengthen dependabot recommendation --- docs/adr/action-pinning.md | 61 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 docs/adr/action-pinning.md diff --git a/docs/adr/action-pinning.md b/docs/adr/action-pinning.md new file mode 100644 index 0000000..f1bc153 --- /dev/null +++ b/docs/adr/action-pinning.md @@ -0,0 +1,61 @@ +# ADR 1396308b-0814-47bd-b8fc-6b3965d31295: GitHub Actions - to pin or not to pin + +## Status + +Proposed + +## Submitters + +- @ctcpip + +## Decision Owners + +- @expressjs/express-tc + +## Context + +GitHub Actions support referencing actions via: + +- Semantic versions (e.g., `actions/setup-node@v4`) +- Specific commit hashes (e.g., `actions/setup-node@49933ea`) +- Branch references (e.g., `actions/setup-node@main`) + +Tools like [OpenSSF Scorecard](https://github.com/ossf/scorecard) recommend pinning to commit hashes to guarantee supply chain integrity and reduce the risk of malicious updates. However, GitHub's own documentation states: + +> "All options are a tradeoff between guaranteed supply chain integrity and auto-patching of vulnerabilities in dependencies." + +Therefore, there is no perfect solution; only pros and cons depending on which choice is made. + +A recent discussion raised valid concerns about the real-world security value of pinning, particularly: + +- **Pinning disables automatic updates**, including security patches, unless maintained manually. +- **Commit hashes are opaque**, harder to audit, and easy to misuse (e.g., referencing a malicious fork). +- **Most CI workflows in our repos don't access secrets**, minimizing risk even in the event of compromise. + +Additionally, human verification of pinned commits, especially across many repos, can be error-prone or inconsistent. + +## Decision + +We will **not require pinning GitHub Actions to commit hashes** across all repositories. + +Instead: + +- Use **semantic version tags** (e.g., `@v4`) by default. +- Do **not use `@main` or other floating branch refs**. +- Repositories should **enable Dependabot for GitHub Actions** and set `schedule/interval` to a reasonable value, such as `monthly`. +- For workflows that **access secrets, publish artifacts, or have privileged scopes**, repository maintainers **may** choose to pin to commit hashes **if justified**. +- Where pinning is used: + - A reviewer **must manually verify** the commit hash belongs to the correct source repository. + - The verification step **must be noted in the PR review** to ensure accountability. + +## Consequences + +- **Improved maintainability**: Semantic versions reduce the burden of keeping commit hashes up to date. +- **Timely security updates**: Using version tags with Dependabot allows faster adoption of upstream patches. +- **Acknowledged risk**: While this approach reduces supply chain guarantees, the practical risk profile of most of our workflows does not justify the burden of pinning. +- **Flexibility for maintainers**: Projects/workflows with higher sensitivity can still opt into pinning where warranted. + +## References + +[Keeping your GitHub Actions and workflows secure](https://securitylab.github.com/resources/github-actions-building-blocks/) +[Mitigating Attack Vectors in GitHub Workflows](https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows/) From 10940ec90ef92a61a5ee5301345e28a598147a88 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=8D=C3=B1igo=20Marqu=C3=ADnez=20Prado?= <25435858+inigomarquinez@users.noreply.github.com> Date: Fri, 16 May 2025 09:06:08 +0200 Subject: [PATCH 20/51] docs: add ADR policy for adoption of OSSF Scorecard (#298) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ulises Gascón --- ...-adoption-of-ossf-scorecard-for-express.md | 62 +++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md diff --git a/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md b/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md new file mode 100644 index 0000000..d9becec --- /dev/null +++ b/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md @@ -0,0 +1,62 @@ +# ADR 83381fbd-593e-49c6-9419-1fe569ac89aa: Adoption of OSSF Scorecard for Express + +## Status +Proposed + +## Submitters +- @ulisesgascon +- @carpasse +- @inigomarquinez + +## Decision Owners +- @expressjs/security-wg +- @expressjs/tc + +## Context +The Open Source Security Foundation (OSSF) Scorecards project generates an automated "security score" for open source projects. This score aids users in assessing the security posture, risk level, and trustworthiness of a project, providing a standardized measure for comparing projects and making informed decisions when adopting new open-source dependencies. The scorecards can also facilitate automated decision-making processes for organizations, as new dependencies can be flagged for further evaluation if they fall below a specified security score threshold. This approach reduces the risk of malicious dependencies infiltrating production systems—a risk highlighted by recent incidents involving malicious NPM packages. + +The Node.js organization has successfully implemented OSSF Scorecard monitoring, leading to notable security improvements across several repositories. Following this model, we propose adopting a similar approach for the Express framework. Tools like the OpenSSF Scorecard Monitor and Visualizer, along with established processes, make ongoing score management manageable and effective, providing straightforward ways to monitor and improve project security scores. + +## Decision +The Express project will adopt OSSF Scorecard reporting as part of its security assessment and improvement practices. + +### Actions +- Integrate OSSF Scorecards and establish monitoring through GitHub Actions with the OpenSSF Scorecard Monitor. +- Track actionable items highlighted by the Scorecard in individual PRs, which will detail specific security improvements. +- Engage contributors, including new collaborators, by involving them in the creation and review of Scorecard-related PRs. + +### Exclusions +- Some suggestions made by the Scorecard may not be implemented in the organization for various reasons. For example, we decided that [pinning dependencies is considered optional](https://github.com/expressjs/discussions/blob/master/docs/adr/action-pinning.md). It is important to reach consensus before making bulk changes across repositories. + +## Rationale +The decision to adopt OSSF Scorecards stems from its demonstrated impact in similar environments, such as the Node.js project, where it has proven valuable for continuous security improvement and community engagement. Key considerations include: + +- **Alternatives Considered:** + - **Manual Security Audits**: Resource-intensive and lacks the automated frequency and granularity provided by Scorecards. + +- **Pros and Cons**: + - **Pros**: Provides automated, actionable insights; strengthens security posture; enables community involvement in a structured way; widely recognized within open source communities. + - **Cons**: Initial setup and monitoring require dedicated resources; minor learning curve for contributors unfamiliar with the process. + +The OSSF Scorecard is a mature, well-supported solution that aligns with Express's commitment to security and community engagement, making it the most fitting choice. + +## Consequences +- **Positive Impact**: The OSSF Scorecard will contribute to Express's security posture by providing clear, actionable insights and facilitating ongoing improvement. It will also streamline the involvement of new collaborators, providing a welcoming entry point into Express contributions. +- **Negative Impact**: The Scorecard’s regular updates may require ongoing maintenance, and individual PR reviews could increase workload initially. Additionally, the Express organization has a large number of repositories, meaning each will require separate Scorecard implementation and upkeep until a centralized solution is found, increasing the management burden. +- **Mitigations**: Regular reviews in Security WG meetings, ongoing monitoring of scoring trends, and continued engagement with the triage team will help manage these challenges. We are also exploring the possibility of a centralized tool to streamline OSSF Scorecard implementation across all repositories, which could significantly reduce maintenance efforts. + +## Implementation + +- Already implemented across the three GitHub organizations related to the Express ecosystem: [expressjs](https://github.com/expressjs), [pillarjs](https://github.com/pillarjs), and [jshttp](https://github.com/jshttp). +- The security team will monitor changes in the Scorecard results and address issues as needed. The team will determine what can be fixed and prioritize accordingly. To streamline this process, an [automation is in place](https://github.com/expressjs/security-wg/blob/main/.github/workflows/ossf-scorecard-reporting.yml) that reports changes in the Scorecard scores. + +## References + +- [OSSF Scorecards documentation](https://securityscorecards.dev/) +- [OpenSSF Scorecards project announcement](https://openssf.org/blog/2020/11/06/security-scorecards-for-open-source-projects/) +- [PR to add support for OSSF scorecard reporting in Express](https://github.com/expressjs/express/pull/5431) +- [PR to add OSSF scorecard in Node.js](https://github.com/nodejs/security-wg/issues/851) +- [Scorecards API for results](https://api.securityscorecards.dev/#/results) + +## Changelog +- **[2024-10-30]**: @inigomarquinez - Drafted and proposed ADR for the adoption of OSSF Scorecard for Express. From 9a6260676880502580ae3c2e07c4e42eea09af98 Mon Sep 17 00:00:00 2001 From: Chris de Almeida Date: Mon, 19 May 2025 15:22:08 -0500 Subject: [PATCH 21/51] trivial fix to formatting --- docs/adr/action-pinning.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/adr/action-pinning.md b/docs/adr/action-pinning.md index f1bc153..8b3f35a 100644 --- a/docs/adr/action-pinning.md +++ b/docs/adr/action-pinning.md @@ -57,5 +57,5 @@ Instead: ## References -[Keeping your GitHub Actions and workflows secure](https://securitylab.github.com/resources/github-actions-building-blocks/) -[Mitigating Attack Vectors in GitHub Workflows](https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows/) +- [Keeping your GitHub Actions and workflows secure](https://securitylab.github.com/resources/github-actions-building-blocks/) +- [Mitigating Attack Vectors in GitHub Workflows](https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows/) From 9f08a4f64b8ecb234ad13b5cacf441959fda924d Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Wed, 30 Apr 2025 17:27:09 -0500 Subject: [PATCH 22/51] fix: ADR cleanup --- docs/adr/{adr-template.md => 000-adr-template.md} | 2 +- ...dencies.md => 290-using-caret-with-dependencies.md} | 7 +++++-- ...funding-guidelines.md => 299-funding-guidelines.md} | 10 ++-------- docs/adr/{performance-wg.md => 306-performance-wg.md} | 2 +- docs/adr/{lts-strategy.md => 352-lts-strategy.md} | 4 ++-- 5 files changed, 11 insertions(+), 14 deletions(-) rename docs/adr/{adr-template.md => 000-adr-template.md} (98%) rename docs/adr/{002-policy-on-using-caret-with-dependencies.md => 290-using-caret-with-dependencies.md} (97%) rename docs/adr/{funding-guidelines.md => 299-funding-guidelines.md} (92%) rename docs/adr/{performance-wg.md => 306-performance-wg.md} (99%) rename docs/adr/{lts-strategy.md => 352-lts-strategy.md} (99%) diff --git a/docs/adr/adr-template.md b/docs/adr/000-adr-template.md similarity index 98% rename from docs/adr/adr-template.md rename to docs/adr/000-adr-template.md index d06f6f9..da196bf 100644 --- a/docs/adr/adr-template.md +++ b/docs/adr/000-adr-template.md @@ -4,7 +4,7 @@ This is the base template that we use ```md -# ADR [Number]: [Title of Decision] +# ADR [PR Number]: [Title of Decision] ## Status diff --git a/docs/adr/002-policy-on-using-caret-with-dependencies.md b/docs/adr/290-using-caret-with-dependencies.md similarity index 97% rename from docs/adr/002-policy-on-using-caret-with-dependencies.md rename to docs/adr/290-using-caret-with-dependencies.md index 70daef0..821a7e6 100644 --- a/docs/adr/002-policy-on-using-caret-with-dependencies.md +++ b/docs/adr/290-using-caret-with-dependencies.md @@ -1,12 +1,15 @@ -# ADR 002: Policy on Using Caret (`^`) or tilde (`~`) with Dependencies in `package.json` +# ADR #290: Policy on Using Caret (`^`) or tilde (`~`) with Dependencies in `package.json` ## Status -Proposed + +Accepted ## Submitters + - Ulises Gascón (@UlisesGascon) ## Decision Owners + - Express TC (@expressjs/express-tc) ## Context diff --git a/docs/adr/funding-guidelines.md b/docs/adr/299-funding-guidelines.md similarity index 92% rename from docs/adr/funding-guidelines.md rename to docs/adr/299-funding-guidelines.md index 2c43854..96c1b89 100644 --- a/docs/adr/funding-guidelines.md +++ b/docs/adr/299-funding-guidelines.md @@ -1,14 +1,8 @@ ---- -name: Funding Use Guidelines -description: Guidelines for spending project funding -labels: ADR ---- - -# ADR [Number]: Funding Use Guidelines +# ADR #299: Funding Use Guidelines ## Status -Proposed +Accepted ## Submitters diff --git a/docs/adr/performance-wg.md b/docs/adr/306-performance-wg.md similarity index 99% rename from docs/adr/performance-wg.md rename to docs/adr/306-performance-wg.md index 8876b23..41f2509 100644 --- a/docs/adr/performance-wg.md +++ b/docs/adr/306-performance-wg.md @@ -2,7 +2,7 @@ ## Status -Proposed +Accepted ## Submitters diff --git a/docs/adr/lts-strategy.md b/docs/adr/352-lts-strategy.md similarity index 99% rename from docs/adr/lts-strategy.md rename to docs/adr/352-lts-strategy.md index 2525c74..5a971ee 100644 --- a/docs/adr/lts-strategy.md +++ b/docs/adr/352-lts-strategy.md @@ -1,8 +1,8 @@ -# ADR [Number]: LTS Strategy and Support Schedule +# ADR #352: LTS Strategy and Support Schedule ## Status -Proposed +Accepted ## Submitters From 87956b16c9d8cbe3a9f6cf5fb738f0698292e735 Mon Sep 17 00:00:00 2001 From: ctcpip Date: Mon, 19 May 2025 15:28:37 -0500 Subject: [PATCH 23/51] =?UTF-8?q?=F0=9F=93=9D=20further=20ADR=20clean=20up?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/adr/352-lts-strategy.md | 47 +++++++++---------- ...ction-pinning.md => 366-action-pinning.md} | 4 +- 2 files changed, 25 insertions(+), 26 deletions(-) rename docs/adr/{action-pinning.md => 366-action-pinning.md} (95%) diff --git a/docs/adr/352-lts-strategy.md b/docs/adr/352-lts-strategy.md index 5a971ee..b340f51 100644 --- a/docs/adr/352-lts-strategy.md +++ b/docs/adr/352-lts-strategy.md @@ -19,38 +19,38 @@ has been spread out across multiple issues, repos, slack channels, and meetings. and generally have agreed on our goals/strategy but we have not officially documented and centralized that. This ADR is both gathering all that context to one place as well as give concrete decisions and next steps. -### Scope: +### Scope This ADR applies to, and should cover, all repositories within the Express Projects three orgs (`jshttp`, `pillarjs`, `expressjs`). While everything stems from support for the primary `express` package, due to the coupling of many of our -dependency and middleware packages, we must also address those packages as well. +dependency and middleware packages, we must also address those packages as well. -### ADR Goals: +### ADR Goals - Improve documentation on our support goals - Document criteria and reasoning for when to release new majors -- Define life cycle for releases, terminology we will use, +- Define life cycle for releases and terminology we will use - Improve documentation on how our LTS relates to Node.js version support - Documentation on how our LTS relates to our direct dependencies and other Express project repos/packages -- Set clear next steps for documenting and publicising the LTS strategy +- Set clear next steps for documenting and publicizing the LTS strategy - Select dates for known release line support and EOL -- Create starter language and graphics for our future blog posts, website additions, and other necessary docs +- Create starter language and graphics for our future blog posts, website additions, and other necessary docs -### ADR Non-Goals: +### ADR Non-Goals - Create an end-user documentation resource (either for immediate use or future use) - Commit to future release dates **Existing issues/discussions/pull requests related to this:** -- Initial LTS strategy doc: https://github.com/expressjs/discussions/blob/master/docs/LTS-strategy.md -- Additional LTS doc proposal: https://github.com/expressjs/admin/pull/3 -- https://github.com/ctcpip/express-release +- Initial LTS strategy doc: +- Additional LTS doc proposal: +- - Some other related discussions: - - https://github.com/expressjs/discussions/issues/196 - - https://github.com/expressjs/discussions/issues/172 - - https://github.com/expressjs/discussions/issues/67 -- TC Slack Discussion: https://openjs-foundation.slack.com/archives/C06KMCETHG9/p1724863852681889 + - + - + - +- TC Slack Discussion: ### Package/Repository Types @@ -85,7 +85,7 @@ requirements: dependencies, middleware, & tools/other. - Dropping old Node.js versions *alone* is not enough of a breaking change to release a new major version. Applies to `express`, dependencies, middleware, & tools/other. -- `express` version 4.x is considered a special case. It will receive a longer `MAINTENENCE` phase of 18 months or until +- `express` version 4.x is considered a special case. It will receive a longer `MAINTENANCE` phase of 18 months or until the TC agrees we are safe cutting support. - `express` dependency packages will follow the same timeline and support dates for the `express` version which they are included with. @@ -125,25 +125,24 @@ ADR and will be addressed in a separate proposal. For the existing release lines, we will set the following phase dates: - | Major | CURRENT | ACTIVE | MAINTENANCE | EOL | | ----- | ------- | ------ | ----------- | --- | | 4.x | | | 2025-04-01 | [1] no sooner than 2026-10-01 | | 5.x | 2024-09-11 | 2025-03-31 | [2]TBD | [2]TBD | | 6.x | [3]TBD | | | | -1. v4 is a special case, and we may extend MAINTENENCE support. This date is called out to give users confidence we will +1. v4 is a special case, and we may extend MAINTENANCE support. This date is called out to give users confidence we will not end-of-life *earlier* than this date. -2. v5 MAINTENENCE and EOL dates are determined by when v6 is released. We will update them when v6 release dates are - committed to. -3. v6 work has not started yet. The earliers we could choose to release by this proposal is 2026-01-01. We will update +2. v5 MAINTENANCE and EOL dates are determined by when v6 is released. We will update them when v6 release dates are + committed to. +3. v6 work has not started yet. The earliest we could choose to release by this proposal is 2026-01-01. We will update these dates when we commit to them. ### Documentation The project will maintain two types of documentation for this: -#### Project documentation for the maintainers: +#### Project documentation for the maintainers This includes this doc, but also detailed things about the process that are not necessary for anyone but us. This documentation will live in one of two places: @@ -153,13 +152,13 @@ documentation will live in one of two places: 2. The individual repo/package to which it applies. If an individual package has more detailed or different needs the docs will live along with the repo as decided by the captains. -#### User documentation: +#### User documentation This will be produced for the website. While the source content of it may live in other places (for example a repo to produce an image for the schedule), the users will be directed to the website to view the current updated version. This -will also co-locate with documentation about Node.js support and other related support content. +will also co-locate with documentation about Node.js support and other related support content. -#### Next steps: +#### Next steps - Update the existing LTS doc with more details from this decision - Update website pages with more details from this decision diff --git a/docs/adr/action-pinning.md b/docs/adr/366-action-pinning.md similarity index 95% rename from docs/adr/action-pinning.md rename to docs/adr/366-action-pinning.md index 8b3f35a..bb0c1cb 100644 --- a/docs/adr/action-pinning.md +++ b/docs/adr/366-action-pinning.md @@ -1,8 +1,8 @@ -# ADR 1396308b-0814-47bd-b8fc-6b3965d31295: GitHub Actions - to pin or not to pin +# ADR 366: GitHub Actions - to pin or not to pin ## Status -Proposed +Accepted ## Submitters From a48015077c5fc677ec2a70f4119d28b10a0b7b8b Mon Sep 17 00:00:00 2001 From: Chris de Almeida Date: Tue, 20 May 2025 00:34:41 -0500 Subject: [PATCH 24/51] =?UTF-8?q?=E2=9C=A8=20lint=20markdown=20and=20add?= =?UTF-8?q?=20CI=20(#382)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .github/workflows/lintyMcLintface.yml | 15 ++ .gitignore | 136 ++++++++++++++++++ .markdownlint-cli2.jsonc | 9 ++ .markdownlint.yml | 11 ++ .npmrc | 1 + docs/CHARTER.md | 4 +- docs/GOVERNANCE.md | 17 +-- docs/LTS-strategy.md | 2 +- docs/adr/290-using-caret-with-dependencies.md | 14 ++ docs/adr/306-performance-wg.md | 22 +-- docs/adr/352-lts-strategy.md | 10 +- ...-adoption-of-ossf-scorecard-for-express.md | 10 ++ docs/contributing/captains_and_committers.md | 26 ++-- docs/contributing/readme-guide.md | 13 +- docs/contributing/release-process.md | 33 ++--- docs/contributing/triager-guide.md | 38 ++--- package.json | 12 ++ 17 files changed, 292 insertions(+), 81 deletions(-) create mode 100644 .github/workflows/lintyMcLintface.yml create mode 100644 .gitignore create mode 100644 .markdownlint-cli2.jsonc create mode 100644 .markdownlint.yml create mode 100644 .npmrc create mode 100644 package.json diff --git a/.github/workflows/lintyMcLintface.yml b/.github/workflows/lintyMcLintface.yml new file mode 100644 index 0000000..ad1281f --- /dev/null +++ b/.github/workflows/lintyMcLintface.yml @@ -0,0 +1,15 @@ +name: 'Lint Markdown' + +on: [pull_request, push] + +permissions: + contents: read + +jobs: + lint: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - uses: actions/setup-node@v4 + - run: npm i + - run: npm test diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..1170717 --- /dev/null +++ b/.gitignore @@ -0,0 +1,136 @@ +# Logs +logs +*.log +npm-debug.log* +yarn-debug.log* +yarn-error.log* +lerna-debug.log* +.pnpm-debug.log* + +# Diagnostic reports (https://nodejs.org/api/report.html) +report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json + +# Runtime data +pids +*.pid +*.seed +*.pid.lock + +# Directory for instrumented libs generated by jscoverage/JSCover +lib-cov + +# Coverage directory used by tools like istanbul +coverage +*.lcov + +# nyc test coverage +.nyc_output + +# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files) +.grunt + +# Bower dependency directory (https://bower.io/) +bower_components + +# node-waf configuration +.lock-wscript + +# Compiled binary addons (https://nodejs.org/api/addons.html) +build/Release + +# Dependency directories +node_modules/ +jspm_packages/ + +# Snowpack dependency directory (https://snowpack.dev/) +web_modules/ + +# TypeScript cache +*.tsbuildinfo + +# Optional npm cache directory +.npm + +# Optional eslint cache +.eslintcache + +# Optional stylelint cache +.stylelintcache + +# Microbundle cache +.rpt2_cache/ +.rts2_cache_cjs/ +.rts2_cache_es/ +.rts2_cache_umd/ + +# Optional REPL history +.node_repl_history + +# Output of 'npm pack' +*.tgz + +# Yarn Integrity file +.yarn-integrity + +# dotenv environment variable files +.env +.env.development.local +.env.test.local +.env.production.local +.env.local + +# parcel-bundler cache (https://parceljs.org/) +.cache +.parcel-cache + +# Next.js build output +.next +out + +# Nuxt.js build / generate output +.nuxt +dist + +# Gatsby files +.cache/ +# Comment in the public line in if your project uses Gatsby and not Next.js +# https://nextjs.org/blog/next-9-1#public-directory-support +# public + +# vuepress build output +.vuepress/dist + +# vuepress v2.x temp and cache directory +.temp +.cache + +# vitepress build output +**/.vitepress/dist + +# vitepress cache directory +**/.vitepress/cache + +# Docusaurus cache and generated files +.docusaurus + +# Serverless directories +.serverless/ + +# FuseBox cache +.fusebox/ + +# DynamoDB Local files +.dynamodb/ + +# TernJS port file +.tern-port + +# Stores VSCode versions used for testing VSCode extensions +.vscode-test + +# yarn v2 +.yarn/cache +.yarn/unplugged +.yarn/build-state.yml +.yarn/install-state.gz +.pnp.* diff --git a/.markdownlint-cli2.jsonc b/.markdownlint-cli2.jsonc new file mode 100644 index 0000000..c36d90f --- /dev/null +++ b/.markdownlint-cli2.jsonc @@ -0,0 +1,9 @@ +{ + "globs": [ + "**/*.md" + ], + "ignores": [ + ".github/**", + "node_modules/**" + ] +} \ No newline at end of file diff --git a/.markdownlint.yml b/.markdownlint.yml new file mode 100644 index 0000000..dfb2e6c --- /dev/null +++ b/.markdownlint.yml @@ -0,0 +1,11 @@ +# for reference, see https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml + +# Default state for all rules +default: true + +# MD013/line-length - Line length +MD013: false + +# MD033/no-inline-html - Inline HTML +MD033: + allowed_elements: ['kbd', 'sup'] diff --git a/.npmrc b/.npmrc new file mode 100644 index 0000000..43c97e7 --- /dev/null +++ b/.npmrc @@ -0,0 +1 @@ +package-lock=false diff --git a/docs/CHARTER.md b/docs/CHARTER.md index 1f86bbd..6836300 100644 --- a/docs/CHARTER.md +++ b/docs/CHARTER.md @@ -30,7 +30,7 @@ Express is made of many modules spread between three GitHub Orgs: Section Intentionally Left Blank -## Section 2: Relationship with OpenJS Foundation CPC. +## 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 @@ -89,4 +89,4 @@ Section Intentionally Left Blank ## Section 5: Definitions -Section Intentionally Left Blank \ No newline at end of file +Section Intentionally Left Blank diff --git a/docs/GOVERNANCE.md b/docs/GOVERNANCE.md index 5dd4be7..819f76d 100644 --- a/docs/GOVERNANCE.md +++ b/docs/GOVERNANCE.md @@ -135,16 +135,17 @@ project for at least 6 months as a committer prior to the request. They should h 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 +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. + +* 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 +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 @@ -181,4 +182,4 @@ By making a contribution to this project, I certify that: 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. -``` \ No newline at end of file +``` diff --git a/docs/LTS-strategy.md b/docs/LTS-strategy.md index da89f48..12d2fac 100644 --- a/docs/LTS-strategy.md +++ b/docs/LTS-strategy.md @@ -39,4 +39,4 @@ ### Release calendar -* There is a regular cadence of semver major releases (details TBD). However, if no breaking changes were introduced between the last semver major and the scheduled date of the release of the new one, the new semver major release is skipped. \ No newline at end of file +* There is a regular cadence of semver major releases (details TBD). However, if no breaking changes were introduced between the last semver major and the scheduled date of the release of the new one, the new semver major release is skipped. diff --git a/docs/adr/290-using-caret-with-dependencies.md b/docs/adr/290-using-caret-with-dependencies.md index 821a7e6..06286f2 100644 --- a/docs/adr/290-using-caret-with-dependencies.md +++ b/docs/adr/290-using-caret-with-dependencies.md @@ -13,6 +13,7 @@ Accepted - Express TC (@expressjs/express-tc) ## Context + Historically, the Express project has avoided using the caret (`^`) in the `package.json` files for its own dependencies. This proposal aims to review whether this practice should continue or if adjustments are needed. **Why do we need this decision?** @@ -22,36 +23,44 @@ Clarifying the policy on using caret (`^`) helps to ensure consistency across th This decision aims to reduce the maintenance burden of frequently updating pinned dependencies. **Are there any existing issues/discussions/pull requests related to this?** + - [Discussion: Using caret (^) with our own dependencies #279](https://github.com/expressjs/discussions/issues/279) - [expressjs/express#6017 (comment)](https://github.com/expressjs/express/issues/6017) ## Decision + We will adopt a policy where the caret (`^`) symbol is used for dependencies all dependencies. **What will be done?** + - Update the `package.json` files to use `^` for all dependencies (both prod and dev). **Note on `^` vs. `~`:** + - `^` allows updates to the most recent minor or patch version, offering greater flexibility and reducing the need for frequent manual updates. For example, `^1.2.3` will accept updates to `1.3.0`, `1.4.0`, but not `2.0.0`. - `~` is more conservative, only allowing updates to patch versions. For example, `~1.2.3` will accept updates to `1.2.4`, `1.2.5`, but not `1.3.0`. Some Node.js legacy versions only support this, like Node@0.8. **What will not be done?** + - We won't force to use `^` or `~` for any dependency if there is a reason to use a pinned version and it is properly documented. ## Rationale **Alternatives Considered:** + - **Alternative:** Continue pinning all dependencies, including internal ones, to specific versions. - **Reason for rejection:** This approach requires frequent updates and increases the maintenance burden, as each minor or patch update requires a new release. **Pros and Cons**: **Pros**: + - Reduces the number of PRs for updating our own dependencies. - Allows for quicker adoption of minor and patch updates within the Express ecosystem. - Users are still protected by lockfiles, mitigating the risk of regressions. **Cons**: + - There is still a risk of minor regressions from updates, even within internally managed dependencies. - Requires discipline in maintaining lockfiles to ensure stability for end users. @@ -61,14 +70,17 @@ This decision strikes a balance between reducing maintenance effort and managing ## Consequences **Positive Impact**: + - Fewer manual updates required for internally managed dependencies. - Users benefit from improvements and fixes in internal packages more quickly. **Negative Impact**: + - Potential risk of regressions if an internal dependency introduces a breaking change in a minor update. - Users relying on strict version control may need to adjust their expectations when using our own dependencies. **Mitigations**: + - Strong test coverage and CI checks will help catch potential issues early. - Clear communication in documentation and release notes to inform users of the updated dependency policy. - Ensure that we are following strict semver when releasing our own libraries. @@ -79,7 +91,9 @@ This decision strikes a balance between reducing maintenance effort and managing - **Phase 2**: Review and adjust documentation to include the new policy on dependency versioning. ## References + - [NPM semver documentation](https://docs.npmjs.com/cli/v6/using-npm/semver) ## Changelog + - **[2024-10-22]**: @UlisesGascon - Initial draft of ADR for using caret (`^`) or tilde (`~`) with our own dependencies. diff --git a/docs/adr/306-performance-wg.md b/docs/adr/306-performance-wg.md index 41f2509..a6081b8 100644 --- a/docs/adr/306-performance-wg.md +++ b/docs/adr/306-performance-wg.md @@ -18,7 +18,7 @@ Express has traditionally taken a very lax approach to performance. Historically and lack of visibility around how changes impact performance. The goal of this working group is to centralize discussion so the whole ecosystem of packages can benefit from targeted performance work. The scope of this WG would be all active packages in the `expressjs`, `pillarjs` and `jshttp` orgs with an initial focus on -the ones which are direct dependencies of `express` itself. +the ones which are direct dependencies of `express` itself. **Why do we need a working group?** @@ -52,24 +52,24 @@ We will need to take a few actions to get this started: ### Relation to STF -Lastly, this kicko-off work is being funded by the STF program. It is a part of our larger work around security +Lastly, this kick-off work is being funded by the STF program. It is a part of our larger work around security improvements for the project. There are two parts of that program which fall under this WG's purview: 1. Milestone 6: Monitor performance across Express and direct dependencies - - Owner: @wesleytodd - - Delivery Date: Dec 31, 2025 - - Estimated Budget: €25,200 -2. Milestone 9: Improve performance for Express and critical dependencies - - Owner: @wesleytodd & @blakeembrey - - Delivery Date: Jun 30, 2026 - - Estimated Budget: €46,200 + - Owner: @wesleytodd + - Delivery Date: Dec 31, 2025 + - Estimated Budget: €25,200 +1. Milestone 9: Improve performance for Express and critical dependencies + - Owner: @wesleytodd & @blakeembrey + - Delivery Date: Jun 30, 2026 + - Estimated Budget: €46,200 This funding does not mean the work can only be done by the owners, it just means that we are responsible for organizing and executing on the deliverables. This is our first attempt at doing a program like this, so feedback is welcome. ## References -- https://github.com/expressjs/express/pull/6129 -- https://github.com/expressjs/express/issues/5998 +- +- - open-telemetry/opentelemetry-js-contrib#2437 - openjs-foundation/infrastructure#5 diff --git a/docs/adr/352-lts-strategy.md b/docs/adr/352-lts-strategy.md index b340f51..7a447e3 100644 --- a/docs/adr/352-lts-strategy.md +++ b/docs/adr/352-lts-strategy.md @@ -125,11 +125,11 @@ ADR and will be addressed in a separate proposal. For the existing release lines, we will set the following phase dates: -| Major | CURRENT | ACTIVE | MAINTENANCE | EOL | -| ----- | ------- | ------ | ----------- | --- | -| 4.x | | | 2025-04-01 | [1] no sooner than 2026-10-01 | -| 5.x | 2024-09-11 | 2025-03-31 | [2]TBD | [2]TBD | -| 6.x | [3]TBD | | | | +| Major | CURRENT | ACTIVE | MAINTENANCE | EOL | +| ----- | ------------------ | ---------- | ------------------ | ---------------------------------------- | +| 4.x | | | 2025-04-01 | no sooner than 2026-10-01 [1] | +| 5.x | 2024-09-11 | 2025-03-31 | TBD [2] | TBD [2] | +| 6.x | TBD [3] | | | | 1. v4 is a special case, and we may extend MAINTENANCE support. This date is called out to give users confidence we will not end-of-life *earlier* than this date. diff --git a/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md b/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md index d9becec..33d87e8 100644 --- a/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md +++ b/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md @@ -1,34 +1,42 @@ # ADR 83381fbd-593e-49c6-9419-1fe569ac89aa: Adoption of OSSF Scorecard for Express ## Status + Proposed ## Submitters + - @ulisesgascon - @carpasse - @inigomarquinez ## Decision Owners + - @expressjs/security-wg - @expressjs/tc ## Context + The Open Source Security Foundation (OSSF) Scorecards project generates an automated "security score" for open source projects. This score aids users in assessing the security posture, risk level, and trustworthiness of a project, providing a standardized measure for comparing projects and making informed decisions when adopting new open-source dependencies. The scorecards can also facilitate automated decision-making processes for organizations, as new dependencies can be flagged for further evaluation if they fall below a specified security score threshold. This approach reduces the risk of malicious dependencies infiltrating production systems—a risk highlighted by recent incidents involving malicious NPM packages. The Node.js organization has successfully implemented OSSF Scorecard monitoring, leading to notable security improvements across several repositories. Following this model, we propose adopting a similar approach for the Express framework. Tools like the OpenSSF Scorecard Monitor and Visualizer, along with established processes, make ongoing score management manageable and effective, providing straightforward ways to monitor and improve project security scores. ## Decision + The Express project will adopt OSSF Scorecard reporting as part of its security assessment and improvement practices. ### Actions + - Integrate OSSF Scorecards and establish monitoring through GitHub Actions with the OpenSSF Scorecard Monitor. - Track actionable items highlighted by the Scorecard in individual PRs, which will detail specific security improvements. - Engage contributors, including new collaborators, by involving them in the creation and review of Scorecard-related PRs. ### Exclusions + - Some suggestions made by the Scorecard may not be implemented in the organization for various reasons. For example, we decided that [pinning dependencies is considered optional](https://github.com/expressjs/discussions/blob/master/docs/adr/action-pinning.md). It is important to reach consensus before making bulk changes across repositories. ## Rationale + The decision to adopt OSSF Scorecards stems from its demonstrated impact in similar environments, such as the Node.js project, where it has proven valuable for continuous security improvement and community engagement. Key considerations include: - **Alternatives Considered:** @@ -41,6 +49,7 @@ The decision to adopt OSSF Scorecards stems from its demonstrated impact in simi The OSSF Scorecard is a mature, well-supported solution that aligns with Express's commitment to security and community engagement, making it the most fitting choice. ## Consequences + - **Positive Impact**: The OSSF Scorecard will contribute to Express's security posture by providing clear, actionable insights and facilitating ongoing improvement. It will also streamline the involvement of new collaborators, providing a welcoming entry point into Express contributions. - **Negative Impact**: The Scorecard’s regular updates may require ongoing maintenance, and individual PR reviews could increase workload initially. Additionally, the Express organization has a large number of repositories, meaning each will require separate Scorecard implementation and upkeep until a centralized solution is found, increasing the management burden. - **Mitigations**: Regular reviews in Security WG meetings, ongoing monitoring of scoring trends, and continued engagement with the triage team will help manage these challenges. We are also exploring the possibility of a centralized tool to streamline OSSF Scorecard implementation across all repositories, which could significantly reduce maintenance efforts. @@ -59,4 +68,5 @@ The OSSF Scorecard is a mature, well-supported solution that aligns with Express - [Scorecards API for results](https://api.securityscorecards.dev/#/results) ## Changelog + - **[2024-10-30]**: @inigomarquinez - Drafted and proposed ADR for the adoption of OSSF Scorecard for Express. diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index eebb041..1daad72 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -1,14 +1,14 @@ -### Active Projects and members +# Active projects and members - [`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): +- [`expressjs/body-parser`](https://github.com/expressjs/body-parser): - Captains: @wesleytodd, @jonchurch, @ulisesGascon - Committers: @Phillip9587 - [`expressjs/codemod`](https://github.com/expressjs/codemod): @bjohansebas (npm: `@bsebas`), @kjugi (npm: `@filip.kudla`) - [`expressjs/compression`](https://github.com/expressjs/compression): - - captains: @UlisesGascon - - committers: @bjohansebas + - captains: @UlisesGascon + - committers: @bjohansebas - [`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 @@ -17,11 +17,11 @@ - [`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): - - captains: @wesleytodd, @ulisesGascon - - committers: @bjohansebas, @Phillip9587 + - captains: @wesleytodd, @ulisesGascon + - committers: @bjohansebas, @Phillip9587 - [`expressjs/expressjs.com`](https://github.com/expressjs/expressjs.com): - - captains: @crandmck, @jonchurch, @bjohansebas - - committers: @carlosstenzel, @chrisdel101 + - captains: @crandmck, @jonchurch, @bjohansebas + - committers: @carlosstenzel, @chrisdel101 - [`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 @@ -33,7 +33,7 @@ - [`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): +- [`expressjs/session`](https://github.com/expressjs/session): - Captains: @ulisesGascon - Committers: @bjohansebas - [`expressjs/statusboard`](https://github.com/expressjs/statusboard): @wesleytodd @@ -66,8 +66,8 @@ - [`pillarjs/csrf`](https://github.com/pillarjs/csrf): @ulisesGascon - [`pillarjs/encodeurl`](https://github.com/pillarjs/encodeurl): @blakeembrey - [`pillarjs/finalhandler`](https://github.com/pillarjs/finalhandler): - - captains: @wesleytodd, @ulisesGascon - - committers: @Phillip9587 + - captains: @wesleytodd, @ulisesGascon + - committers: @Phillip9587 - [`pillarjs/hbs`](https://github.com/pillarjs/hbs): @ulisesGascon - [`pillarjs/multiparty`](https://github.com/pillarjs/multiparty): @blakeembrey - [`pillarjs/parseurl`](https://github.com/pillarjs/parseurl): @blakeembrey @@ -78,6 +78,6 @@ - [`pillarjs/send`](https://github.com/pillarjs/send): @blakeembrey - [`pillarjs/understanding-csrf`](https://github.com/pillarjs/understanding-csrf): @ulisesGascon -### Current Initiative Captains +## Current Initiative Captains -- Triage team [ref](https://github.com/expressjs/discussions/issues/227): @UlisesGascon \ No newline at end of file +- Triage team [ref](https://github.com/expressjs/discussions/issues/227): @UlisesGascon diff --git a/docs/contributing/readme-guide.md b/docs/contributing/readme-guide.md index 03edbd2..6e3d637 100644 --- a/docs/contributing/readme-guide.md +++ b/docs/contributing/readme-guide.md @@ -6,7 +6,7 @@ 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. + into . - Encourage community contributions and participation. Use the [README template](https://github.com/expressjs/express/wiki/README-template) @@ -19,6 +19,7 @@ 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]` - test coverage: `[![Test Coverage][coveralls-image]][coveralls-url]` @@ -44,7 +45,7 @@ use it and how. Don't just repeat what's in the summary. Required. This section is typically just: ```sh -$ npm install module-name +npm install module-name ``` But include any other steps or requirements. @@ -68,11 +69,11 @@ Provide complete API documentation. Formatting conventions: Each function is listed in a 3rd-level heading (`###`), like this: -``` -### Function_name(arg, options [, optional_arg] ... ) +```js +### functionName(arg, options [, optional_arg] ... ) ``` -**Options objects** +### 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 @@ -120,4 +121,4 @@ contributed. 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. \ No newline at end of file +to it instead. diff --git a/docs/contributing/release-process.md b/docs/contributing/release-process.md index 32efc20..2063533 100644 --- a/docs/contributing/release-process.md +++ b/docs/contributing/release-process.md @@ -3,7 +3,7 @@ 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. +as npm packages hosted on . ## Who can make releases? @@ -31,7 +31,7 @@ Before publishing, the following preconditions should be met: 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 version number (according to semantic versioning - ) - The proposed changes should be complete. There are two main release flows: patch and non-patch. @@ -121,13 +121,14 @@ is ready when all proposed code, tests and documentation updates are complete In the patch flow: skip this step. In the non-patch flow: + ```sh -$ git checkout -$ git merge --ff-only +git checkout +git merge --ff-only ``` - - see "Release branch" of "Branches" above. - - see "Proposal branch" of "Non-patch flow" above. +`` - see "Release branch" of "Branches" above. +`` - see "Proposal branch" of "Non-patch flow" above. > [!NOTE] > You may need to rebase the proposal branch to allow a fast-forward @@ -167,17 +168,17 @@ Create a lightweight tag (rather than an annotated tag) named after the new release version (eg: `4.13.3`). ```sh -$ git tag +git tag ``` ### 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 -$ git push origin +git push origin +git push origin ``` ### Step 6. Publish to npmjs.com @@ -186,17 +187,17 @@ 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 publish +npm login +npm publish ``` > [!NOTE] -> The version number to publish will be picked up automatically from +> 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: +The documentation website 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. \ No newline at end of file +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. diff --git a/docs/contributing/triager-guide.md b/docs/contributing/triager-guide.md index 65aff26..051f873 100644 --- a/docs/contributing/triager-guide.md +++ b/docs/contributing/triager-guide.md @@ -47,26 +47,26 @@ ask questions if required. No question is a bad question! 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 +* 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. \ No newline at end of file +## 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 ) 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. diff --git a/package.json b/package.json new file mode 100644 index 0000000..636e5ad --- /dev/null +++ b/package.json @@ -0,0 +1,12 @@ +{ + "name": "discussions", + "private": true, + "scripts": { + "lint": "markdownlint-cli2", + "lint:fix": "markdownlint-cli2 --fix", + "test": "npm run lint" + }, + "devDependencies": { + "markdownlint-cli2": "^0.18.1" + } +} From 546404087542e863ee0af2eb8eec7c231fada861 Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Fri, 6 Jun 2025 05:12:14 -0500 Subject: [PATCH 25/51] feat: remove triage meeting (#389) Co-authored-by: Wes Todd --- .github/ISSUE_TEMPLATE/meeting-triage.md | 56 ------------------------ .github/ISSUE_TEMPLATE/meeting.md | 24 ++++++---- .github/workflows/meetings.yml | 13 ------ 3 files changed, 15 insertions(+), 78 deletions(-) delete mode 100644 .github/ISSUE_TEMPLATE/meeting-triage.md diff --git a/.github/ISSUE_TEMPLATE/meeting-triage.md b/.github/ISSUE_TEMPLATE/meeting-triage.md deleted file mode 100644 index 546aa15..0000000 --- a/.github/ISSUE_TEMPLATE/meeting-triage.md +++ /dev/null @@ -1,56 +0,0 @@ -## Date/Time - -| Timezone | Date/Time | -|----------|-----------| -<%= [ - 'America/Los_Angeles', - 'America/Denver', - 'America/Chicago', - 'America/New_York', - 'Europe/London', - 'Europe/Amsterdam', - 'Europe/Moscow', - 'Asia/Kolkata', - 'Asia/Shanghai', - 'Asia/Tokyo', - 'Australia/Sydney' -].map((zone) => { - return `| ${zone} | ${date.setZone(zone).toFormat('EEE dd-MMM-yyyy HH:mm (hh:mm a)')} |` -}).join('\n') %> - -Or in your local time: -* https://www.timeanddate.com/worldclock/?iso=<%= date.toFormat("yyyy-MM-dd'T'HH:mm:ss") %> - -## Links - -* Minutes Google Doc: - -## Agenda - -Extracted from **<%= agendaLabel %>** labelled issues and pull requests from **<%= owner %>/<%= repo %>** prior to the meeting. - -<%= agendaIssues.map((i) => { - return `* ${i.html_url}` -}).join('\n') %> - -## Invited - -This meeting is open for anyone who wants to attend. Reminder to follow our [Code of Conduct](https://github.com/expressjs/express/blob/master/Code-Of-Conduct.md). - -- Triage team: @expressjs/triagers - -### Observers/Guests - -## Joining the meeting - -* link for participants: https://zoom-lfx.platform.linuxfoundation.org/meeting/99366452429?password=13cb3704-9041-4556-a409-85e7384b53fd -* For those who just want to watch: https://www.youtube.com/@expressjs-official - -
- -Please use the following emoji reactions in this post to indicate your -availability. - -- 👍 - Attending -- 👎 - Not attending -- 😕 - Not sure yet diff --git a/.github/ISSUE_TEMPLATE/meeting.md b/.github/ISSUE_TEMPLATE/meeting.md index f9843c7..1d5f1fa 100644 --- a/.github/ISSUE_TEMPLATE/meeting.md +++ b/.github/ISSUE_TEMPLATE/meeting.md @@ -31,17 +31,23 @@ Extracted from **<%= agendaLabel %>** labelled issues and pull requests from **< ## Invited -This meeting is open for anyone who wants to attend. Reminder to follow our [Code of Conduct](https://github.com/expressjs/express/blob/master/Code-Of-Conduct.md). +- @expressjs/express-tc +- @expressjs/triagers +- @expressjs/security-wg -@expressjs/express-tc -@expressjs/triagers -@expressjs/security-wg +### Observers/Guests -## Links +This meeting is open for anyone who wants to attend. Reminder to follow our [Code of Conduct](https://github.com/expressjs/.github/blob/master/CODE_OF_CONDUCT.md). -* Minutes: - -### Joining the meeting +## Joining the meeting * link for participants: <%= meetingLink %> -* For those who just want to watch: https://www.youtube.com/@expressjs-official + +--- + +Please use the following emoji reactions in this post to indicate your +availability. + +- 👍 - Attending +- 👎 - Not attending +- 😕 - Not sure yet diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 0b2ac00..1518849 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -40,16 +40,3 @@ jobs: createWithin: 'P1W' meetingLink: 'https://zoom-lfx.platform.linuxfoundation.org/meeting/95258037175?password=07aad89d-ff43-45df-9b28-f437e167a0b9' issueTemplate: 'meeting.md' - - name: Triage Working Session - uses: 'pkgjs/meet@v0' - with: - issueTitle: '<%= date.toFormat("yyyy-MM-dd") %> Express Triage Session' - token: ${{ secrets.GITHUB_TOKEN }} - orgs: expressjs,pillarjs,jshttp - agendaLabel: 'triage-meeting' - meetingLabels: 'meeting' - # https://github.com/expressjs/discussions/issues/276#issuecomment-2399741373 - # Starting on 2025-01-27 at 8pm UTC (2025-01-27T20:00:00.0Z) with a period of 4 weeks (P4W) - schedules: '2025-01-27T20:00:00.0Z/P4W' - createWithin: 'P1W' - issueTemplate: 'meeting-triage.md' From 4276d3e831fcbfe88e3e8c099e39140bef8229d6 Mon Sep 17 00:00:00 2001 From: Jon Church Date: Thu, 19 Jun 2025 22:30:27 -0400 Subject: [PATCH 26/51] add write perms to meeting action post default token perm change (#397) --- .github/workflows/meetings.yml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 1518849..e05eea8 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -6,6 +6,11 @@ on: - master schedule: - cron: '0 0 * * *' + +permissions: + issues: write + contents: read + jobs: meeting: runs-on: ubuntu-latest From bf0e895d261613479b5b6fc9712a750cd3f6ff13 Mon Sep 17 00:00:00 2001 From: Jon Church Date: Sun, 22 Jun 2025 15:00:13 -0400 Subject: [PATCH 27/51] meetings: remove PR and push triggers, add workflow_dispatch (#398) * remove PR and push triggers, add workflow_dispatch * run on pr when pr is against meeting template or workflow --- .github/workflows/meetings.yml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index e05eea8..3449638 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -1,9 +1,10 @@ name: Schedule Meetings on: + workflow_dispatch: pull_request: - push: - branches: - - master + paths: + - '.github/workflows/meetings.yml' + - '.github/ISSUE_TEMPLATE/meeting.md' schedule: - cron: '0 0 * * *' From 31d2ad2796bafbd81b62180d35cb55e155e40aad Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Mon, 23 Jun 2025 15:41:49 -0500 Subject: [PATCH 28/51] feat(adr): add TypeScript Working Group ADR (#369) * feat(adr): add TypeScript Working Group ADR Signed-off-by: Sebastian Beltran * Update docs/adr/typescript-wg.md Co-authored-by: Jon Church * Update docs/adr/typescript-wg.md Co-authored-by: Jon Church * Update docs/adr/typescript-wg.md Co-authored-by: Jon Church * Update docs/adr/typescript-wg.md Co-authored-by: Wes Todd * Update docs/adr/typescript-wg.md Co-authored-by: Wes Todd --------- Signed-off-by: Sebastian Beltran Co-authored-by: Jon Church Co-authored-by: Wes Todd --- docs/adr/typescript-wg.md | 72 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 docs/adr/typescript-wg.md diff --git a/docs/adr/typescript-wg.md b/docs/adr/typescript-wg.md new file mode 100644 index 0000000..e25463b --- /dev/null +++ b/docs/adr/typescript-wg.md @@ -0,0 +1,72 @@ +# ADR #005: TypeScript Working Group + +## Status + +Proposed + +## Submitters + +- @bjohansebas + +## Decision Owners + +- @expressjs/express-tc + +## Context + +TypeScript is now widely adopted and has a large, active community. Many developers use it alongside packages maintained by the Express project. As such, there's a growing need to enhance TypeScript support — both by maintaining accurate type definitions and by addressing existing and future issues related to typings. + +- **Why do we need this decision?** + +As the Express project continues to evolve, we want to improve our engagement with the community. Having a dedicated group focused on TypeScript-related matters will enhance our support, especially since not all maintainers are familiar with TypeScript. An active working group will help manage and resolve type-related issues effectively. + +- **What problem does it solve or avoid?** + +This proposal aims to establish a dedicated team responsible for maintaining TypeScript types, whether in DefinitelyTyped or directly within the repositories. It will also help triage and resolve the numerous issues reported daily related to type definitions. + +- **Are there any existing issues/discussions/pull requests related to this?**: + + - https://github.com/expressjs/discussions/issues/192 + - https://github.com/expressjs/express/issues/2818 + +## Decision + +Similar to the Security WG and Performance WG, we will set up a new repository (expressjs/typescript-wg) along with a corresponding action plan. This working group will be empowered to build consensus and make decisions within its scope. Its core responsibilities will include: + +- Ensure `express` package types are semantically correct, current with the implementation, and provide a high-quality developer experience +- Making decisions on TypeScript support within Express-maintained repositories +- Maintaining up-to-date TypeScript type definitions +- Enhancing documentation for TypeScript usage across Express packages +- Support testing type accuracy while in development and CI +- Ensure that types shared across Express Project packages are updated in sync to prevent build errors across the ecosystem + +### Initial Goal + +The TypeScript Working Group’s initial goal is to ensure that the `express` package has **high-quality, semantically correct, and up-to-date type definitions that accurately reflect its public API.** + +As part of this effort, the working group will also evaluate whether and how to support types in other Express-maintained packages. Decisions around publishing first party types vs. DefinitelyTyped maintenance, release cycle alignment, and tooling support will be developed collaboratively and documented as part of the group's ongoing charter. +We will need to take a few actions to get this started: + +1. Create a new `typescript-wg` repo +2. Create teams: `@expressjs/typescript-wg`, `@pillarjs/typescript-wg`, `@jshttp/typescript-wg` +3. Write charter/goals doc in the new repo + +## Rationale + +Since Express has become active again and the new version, Express v5, has been released, several issues related to typings have emerged. There have also been discussions about actively integrating type definitions within the repositories. + +Most packages under the Express umbrella are not written in TypeScript, and not all maintainers are interested in taking on type maintenance responsibilities. A small number (such as `path-to-regexp`) maintain their own types, but this is the exception rather than the norm. + +The proposed working group provides a focused avenue for contributors who are interested in TypeScript to collaboratively improve, maintain, and guide the strategy for type definitions across Express projects, starting with the core `express` package. + +## References + +- https://github.com/expressjs/discussions/issues/192 +- https://github.com/expressjs/express/issues/2818 + +## Changelog + +Track changes or updates to this ADR over time. Include the date, author, and a brief description of each change. + +- **[2025-05-28]**: [@bjohansebas] - Initial draft + From 97d3ca6650fb25eff9ab12ef0c8dbf506d440b6e Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Thu, 10 Jul 2025 11:08:23 -0500 Subject: [PATCH 29/51] fix(docs): fixed broken link --- docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md b/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md index 33d87e8..538b204 100644 --- a/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md +++ b/docs/adr/adr-xxx-adoption-of-ossf-scorecard-for-express.md @@ -33,7 +33,7 @@ The Express project will adopt OSSF Scorecard reporting as part of its security ### Exclusions -- Some suggestions made by the Scorecard may not be implemented in the organization for various reasons. For example, we decided that [pinning dependencies is considered optional](https://github.com/expressjs/discussions/blob/master/docs/adr/action-pinning.md). It is important to reach consensus before making bulk changes across repositories. +- Some suggestions made by the Scorecard may not be implemented in the organization for various reasons. For example, we decided that [pinning dependencies is considered optional](https://github.com/expressjs/discussions/blob/master/docs/adr/366-action-pinning.md). It is important to reach consensus before making bulk changes across repositories. ## Rationale From b712556164fa62edecdcef7df5aa7fef40d71485 Mon Sep 17 00:00:00 2001 From: Jean Burellier Date: Mon, 7 Jul 2025 21:31:00 +0200 Subject: [PATCH 30/51] fix: markdown linter issues --- docs/adr/typescript-wg.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/adr/typescript-wg.md b/docs/adr/typescript-wg.md index e25463b..3b867d5 100644 --- a/docs/adr/typescript-wg.md +++ b/docs/adr/typescript-wg.md @@ -26,8 +26,8 @@ This proposal aims to establish a dedicated team responsible for maintaining Typ - **Are there any existing issues/discussions/pull requests related to this?**: - - https://github.com/expressjs/discussions/issues/192 - - https://github.com/expressjs/express/issues/2818 + - + - ## Decision @@ -61,12 +61,11 @@ The proposed working group provides a focused avenue for contributors who are in ## References -- https://github.com/expressjs/discussions/issues/192 -- https://github.com/expressjs/express/issues/2818 +- +- ## Changelog Track changes or updates to this ADR over time. Include the date, author, and a brief description of each change. - **[2025-05-28]**: [@bjohansebas] - Initial draft - From e1595a594964a3615efc98a8b3e441cde8674704 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Tue, 22 Jul 2025 18:15:12 +0200 Subject: [PATCH 31/51] feat: nominate @Phillip9587 as committer to jshttp/on-finished (#372) --- docs/contributing/captains_and_committers.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index 1daad72..1594c68 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -55,7 +55,9 @@ - [`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-finished`](https://github.com/jshttp/on-finished): + - Captains: @wesleytodd, @ulisesGascon + - Committers: @Phillip9587 - [`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 From 51397daa18961e499e2faa06b8eeb562eb71bfbf Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Wed, 30 Jul 2025 14:00:21 -0700 Subject: [PATCH 32/51] fix: TC to meet 2 hours earlier (#408) --- .github/workflows/meetings.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 3449638..e255869 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -26,7 +26,7 @@ jobs: meetingLabels: 'meeting' # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 # Starting on 2024-03-18 at 9pm UTC (2024-03-18T21:00:00.0Z) with a period of 2 weeks (P2W) - schedules: '2024-03-18T21:00:00.0Z/P2W' + schedules: '2024-03-18T19:00:00.0Z/P2W' createWithin: 'P1W' meetingLink: 'https://zoom-lfx.platform.linuxfoundation.org/meeting/95266714809?password=f37cff1b-cb3a-4a21-9425-210e4714c72e' issueTemplate: 'meeting.md' From fc096c8285cf515a9437c38d56384d8aed27ea19 Mon Sep 17 00:00:00 2001 From: ctcpip Date: Wed, 6 Aug 2025 13:33:09 -0500 Subject: [PATCH 33/51] =?UTF-8?q?=F0=9F=9A=91=EF=B8=8F=20fix=20meeting=20t?= =?UTF-8?q?imes,=20update=20to=20meet=20v1,=20normalize=20template?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .github/ISSUE_TEMPLATE/meeting.md | 31 +++++++++++++++++++++++-------- .github/workflows/meetings.yml | 19 ++++++++----------- 2 files changed, 31 insertions(+), 19 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/meeting.md b/.github/ISSUE_TEMPLATE/meeting.md index 1d5f1fa..5334a16 100644 --- a/.github/ISSUE_TEMPLATE/meeting.md +++ b/.github/ISSUE_TEMPLATE/meeting.md @@ -1,8 +1,4 @@ -## Date/Time - -| Timezone | Date/Time | -|----------|-----------| -<%= [ +<% const timezones = [ 'America/Los_Angeles', 'America/Denver', 'America/Chicago', @@ -14,12 +10,31 @@ 'Asia/Shanghai', 'Asia/Tokyo', 'Australia/Sydney' -].map((zone) => { - return `| ${zone} | ${date.setZone(zone).toFormat('EEE dd-MMM-yyyy HH:mm (hh:mm a)')} |` +]; %> + +## Date/Time + +| Timezone | Date/Time | +|----------|-----------| +<%= timezones.map((zone) => { + const zonedDate = date.toZonedDateTimeISO(zone) + const formatter = new Intl.DateTimeFormat('en-US', { + weekday: 'short', + month: 'short', + day: '2-digit', + year: 'numeric', + hour: '2-digit', + minute: '2-digit', + hour12: true, + timeZone: zone + }) + const formattedDate = formatter.format(new Date(zonedDate.epochMilliseconds)) + return `| ${zone} | ${formattedDate} |` }).join('\n') %> Or in your local time: -* https://www.timeanddate.com/worldclock/?iso=<%= date.toFormat("yyyy-MM-dd'T'HH:mm:ss") %> + +* https://www.timeanddate.com/worldclock/?iso=<%= date.toZonedDateTimeISO('UTC').toPlainDateTime().toString() %> ## Agenda diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index e255869..13be25d 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -17,32 +17,29 @@ jobs: runs-on: ubuntu-latest steps: - name: Technical Committee - uses: 'pkgjs/meet@v0' + uses: 'pkgjs/meet@v1' with: - issueTitle: '<%= date.toFormat("yyyy-MM-dd") %> Express TC Meeting' + issueTitle: '<%= date.toZonedDateTimeISO("UTC").toPlainDate().toString() %> Express TC Meeting' token: ${{ secrets.GITHUB_TOKEN }} orgs: expressjs,pillarjs,jshttp agendaLabel: 'tc agenda' meetingLabels: 'meeting' - # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 - # Starting on 2024-03-18 at 9pm UTC (2024-03-18T21:00:00.0Z) with a period of 2 weeks (P2W) - schedules: '2024-03-18T19:00:00.0Z/P2W' + # Monday 1 PM America/Chicago with a period of 2 weeks (P2W) + schedules: '2025-08-04T13:00:00.0[America/Chicago]/P2W' createWithin: 'P1W' meetingLink: 'https://zoom-lfx.platform.linuxfoundation.org/meeting/95266714809?password=f37cff1b-cb3a-4a21-9425-210e4714c72e' issueTemplate: 'meeting.md' - name: Working Session - uses: 'pkgjs/meet@v0' + uses: 'pkgjs/meet@v1' with: - issueTitle: '<%= date.toFormat("yyyy-MM-dd") %> Express Working Session' + issueTitle: '<%= date.toZonedDateTimeISO("UTC").toPlainDate().toString() %> Express Working Session' token: ${{ secrets.GITHUB_TOKEN }} orgs: expressjs,pillarjs,jshttp agendaLabel: 'top priority' meetingLabels: 'meeting' - # Converting the second time slot to a "working session" - # https://github.com/expressjs/discussions/issues/195#issuecomment-1973732769 - # Starting on 2024-03-27 at 9pm UTC (2024-03-27T21:00:00.0Z) with a period of 2 weeks (P2W) - schedules: '2024-03-27T21:00:00.0Z/P2W' + # Wednesday 1 PM America/Chicago with a period of 2 weeks (P2W) + schedules: '2025-08-13T13:00:00.0[America/Chicago]/P2W' createWithin: 'P1W' meetingLink: 'https://zoom-lfx.platform.linuxfoundation.org/meeting/95258037175?password=07aad89d-ff43-45df-9b28-f437e167a0b9' issueTemplate: 'meeting.md' From 6a474ee717624d11227ccf992c879b7331744855 Mon Sep 17 00:00:00 2001 From: ctcpip Date: Thu, 7 Aug 2025 12:57:05 -0500 Subject: [PATCH 34/51] =?UTF-8?q?=F0=9F=90=9B=20fix=20time=20converter=20l?= =?UTF-8?q?ink?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .github/ISSUE_TEMPLATE/meeting.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/meeting.md b/.github/ISSUE_TEMPLATE/meeting.md index 5334a16..7ad4ad1 100644 --- a/.github/ISSUE_TEMPLATE/meeting.md +++ b/.github/ISSUE_TEMPLATE/meeting.md @@ -34,7 +34,7 @@ Or in your local time: -* https://www.timeanddate.com/worldclock/?iso=<%= date.toZonedDateTimeISO('UTC').toPlainDateTime().toString() %> +* https://www.timeanddate.com/worldclock/fixedtime.html?msg=<%= encodeURIComponent(title) %>&iso=<%= date.toZonedDateTimeISO('UTC').toPlainDateTime().toString().slice(0, 16).replace(/[-:]/g, '') %>&p1=1440&ah=1 ## Agenda From 8915b7df11da8b4cde913a97fab5c9b73524cdc6 Mon Sep 17 00:00:00 2001 From: Chris de Almeida Date: Wed, 27 Aug 2025 08:32:28 -0500 Subject: [PATCH 35/51] =?UTF-8?q?=F0=9F=95=B0=EF=B8=8F=20fix=20working=20s?= =?UTF-8?q?ession=20meeting=20time?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit as agreed at the 2025-08-18 express meeting, this meeting time should return to the previous time of 15:00 America/Chicago --- .github/workflows/meetings.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/meetings.yml b/.github/workflows/meetings.yml index 13be25d..319450c 100644 --- a/.github/workflows/meetings.yml +++ b/.github/workflows/meetings.yml @@ -38,8 +38,8 @@ jobs: orgs: expressjs,pillarjs,jshttp agendaLabel: 'top priority' meetingLabels: 'meeting' - # Wednesday 1 PM America/Chicago with a period of 2 weeks (P2W) - schedules: '2025-08-13T13:00:00.0[America/Chicago]/P2W' + # Wednesday 3 PM America/Chicago with a period of 2 weeks (P2W) + schedules: '2025-08-13T15:00:00.0[America/Chicago]/P2W' createWithin: 'P1W' meetingLink: 'https://zoom-lfx.platform.linuxfoundation.org/meeting/95258037175?password=07aad89d-ff43-45df-9b28-f437e167a0b9' issueTemplate: 'meeting.md' From eea0981db873e20399e577da9adaa23684d45242 Mon Sep 17 00:00:00 2001 From: Chris de Almeida Date: Wed, 27 Aug 2025 09:19:17 -0500 Subject: [PATCH 36/51] =?UTF-8?q?=F0=9F=95=B0=EF=B8=8F=20add=20timezones?= =?UTF-8?q?=20to=20meeting=20template?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .github/ISSUE_TEMPLATE/meeting.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/meeting.md b/.github/ISSUE_TEMPLATE/meeting.md index 7ad4ad1..527876c 100644 --- a/.github/ISSUE_TEMPLATE/meeting.md +++ b/.github/ISSUE_TEMPLATE/meeting.md @@ -2,9 +2,13 @@ 'America/Los_Angeles', 'America/Denver', 'America/Chicago', + 'America/Bogota', 'America/New_York', + 'UTC', 'Europe/London', - 'Europe/Amsterdam', + 'Europe/Madrid', + 'Europe/Paris', + 'Europe/Warsaw', 'Europe/Moscow', 'Asia/Kolkata', 'Asia/Shanghai', From b4a6c38d0012bb4d6f1e1c0a0921b92098c433cc Mon Sep 17 00:00:00 2001 From: shubham oulkar <91728992+ShubhamOulkar@users.noreply.github.com> Date: Mon, 15 Sep 2025 23:37:46 +0530 Subject: [PATCH 37/51] feat: Add @shubhamOulkar as committer to expressjs/expressjs.com (#393) https://github.com/expressjs/expressjs.com/issues/1897 --- docs/contributing/captains_and_committers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index 1594c68..e1f6b0e 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -21,7 +21,7 @@ - committers: @bjohansebas, @Phillip9587 - [`expressjs/expressjs.com`](https://github.com/expressjs/expressjs.com): - captains: @crandmck, @jonchurch, @bjohansebas - - committers: @carlosstenzel, @chrisdel101 + - committers: @carlosstenzel, @chrisdel101, @ShubhamOulkar - [`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 From af47a44357f136b9b8ed46a324e00a30bdbe9f10 Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Mon, 15 Sep 2025 13:48:55 -0500 Subject: [PATCH 38/51] fix(docs): perf-wg, security-wg, docs-wg, remove wes from body-parser (#360) --- docs/contributing/captains_and_committers.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index e1f6b0e..68ae400 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -3,7 +3,7 @@ - [`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): - - Captains: @wesleytodd, @jonchurch, @ulisesGascon + - Captains: @jonchurch, @ulisesGascon - Committers: @Phillip9587 - [`expressjs/codemod`](https://github.com/expressjs/codemod): @bjohansebas (npm: `@bsebas`), @kjugi (npm: `@filip.kudla`) - [`expressjs/compression`](https://github.com/expressjs/compression): @@ -82,4 +82,6 @@ ## Current Initiative Captains -- Triage team [ref](https://github.com/expressjs/discussions/issues/227): @UlisesGascon +- [Triage team](https://github.com/expressjs/discussions/issues/227): @UlisesGascon +- [Security WG](https://github.com/expressjs/security-wg): @UlisesGascon +- [Perf WG](https://github.com/expressjs/perf-wg): @wesleytodd From e52abe359eef43f88a0c5f0f040d611212bbe734 Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Mon, 29 Sep 2025 13:10:56 -0500 Subject: [PATCH 39/51] docs: iconv-lite captains (#421) * docs: iconv-lite captains * Update docs/contributing/captains_and_committers.md * Update docs/contributing/captains_and_committers.md --- docs/contributing/captains_and_committers.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index 68ae400..2a862bb 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -72,6 +72,9 @@ - committers: @Phillip9587 - [`pillarjs/hbs`](https://github.com/pillarjs/hbs): @ulisesGascon - [`pillarjs/multiparty`](https://github.com/pillarjs/multiparty): @blakeembrey +- [`pillarjs/iconv-lite`](https://github.com/pillarjs/iconv-lite): + - Captains: @ashtuchkin, @bjohansebas (npm: `@bsebas`) + - Committers: @Phillip9587 - [`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 From e832cf762fdc62328704275459ab1a77370bc8b2 Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Mon, 29 Sep 2025 13:18:42 -0500 Subject: [PATCH 40/51] docs: clarify release authorization and permissions in release process (#387) * docs: clarify release authorization and permissions in release process Signed-off-by: Sebastian Beltran * docs: enhance clarity and detail in release process documentation Signed-off-by: Sebastian Beltran * Revert "docs: enhance clarity and detail in release process documentation" This reverts commit 891cdf7104c0e80e6a5efcaf19fc82ed689e167e. * docs: simplify the changes Signed-off-by: Sebastian Beltran * formmat Signed-off-by: Sebastian Beltran --------- Signed-off-by: Sebastian Beltran --- docs/contributing/release-process.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/contributing/release-process.md b/docs/contributing/release-process.md index 2063533..87dd20b 100644 --- a/docs/contributing/release-process.md +++ b/docs/contributing/release-process.md @@ -2,25 +2,25 @@ 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 . +Committee (TC) to create, promote and sign official release builds for any +package governed by Express. ## Who can make releases? -Release authorization is given by the Express TC. Once authorized, an individual -must have the following access permissions: +According to project governance, only package Captains or members of the Technical +Committee (TC) are permitted to make releases. Captains have the freedom to make releases +for their own package whenever necessary, while TC members may make releases for any package +as needed. ### 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). +The person making the release must be either the package captain or a member of the TC in +order to have sufficient permissions to do the work. ### 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 +package on npmjs.com so they are able to publish the release (see Step 6). ## How to publish a release From b604ca77012a9a4f7ba0ee8ccf91e389a5a42e61 Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Mon, 29 Sep 2025 13:21:22 -0500 Subject: [PATCH 41/51] fix: add inactivity policy for any roles (#378) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * feat(docs): add inactivity policy for any roles Signed-off-by: Sebastian Beltran * Update docs/GOVERNANCE.md Co-authored-by: Ulises Gascón * Update docs/GOVERNANCE.md Co-authored-by: Sebastian Beltran * Update docs/GOVERNANCE.md Co-authored-by: Wes Todd * Update docs/GOVERNANCE.md Co-authored-by: Jon Church * fix lint issues Signed-off-by: Sebastian Beltran * reference to working groups members Signed-off-by: Sebastian Beltran * Update docs/GOVERNANCE.md Co-authored-by: Wes Todd --------- Signed-off-by: Sebastian Beltran Co-authored-by: Ulises Gascón Co-authored-by: Jon Church Co-authored-by: Wes Todd --- docs/GOVERNANCE.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/GOVERNANCE.md b/docs/GOVERNANCE.md index 819f76d..99781c4 100644 --- a/docs/GOVERNANCE.md +++ b/docs/GOVERNANCE.md @@ -156,6 +156,26 @@ The list can be found at [https://github.com/expressjs/discussions/blob/HEAD/doc The list can be found at [https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#current-initiative-captains](https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#current-initiative-captains) +## Inactivity and Emeritus Policy for Any Role + +To support the health and continuity of the project, all individuals holding a role within the community (such as Triager, Committer, WG member, Project Captain, or TC member) are encouraged to maintain active participation. + +Inactivity is defined as the absence of meaningful involvement in the project—such as contributions, code reviews, triage, meeting attendance, or discussion participation—for a continuous period of 6 months. + +### Exceptions + +Anyone may request a temporary leave from active participation due to personal or professional reasons. In such cases, the individual should inform the relevant team or the Technical Committee (TC). During this time, the inactivity policy is paused, and the individual will not be flagged as inactive. + +### Inactivity Process + +* If someone is deemed inactive, the individual may be transitioned to an emeritus role that reflects their past contributions. A best effort will be made to inform them that this has occurred. They may request to be reinstated when they are ready to be active again. +* The emeritus status helps preserve a clear record of contributors who have meaningfully shaped the project over time. + +### Accountability + +* The Technical Committee (TC) and the respective captains of each package/team are responsible for assessing activity levels and enacting this policy fairly and transparently, in coordination with other relevant teams. +* In case of disagreement, the situation can be discussed and resolved by consensus within the TC or appropriate team. + ## Developer's Certificate of Origin 1.1 ```text From 5665cb85dde749ba1901145d5e65b2bbb4264261 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Tue, 30 Sep 2025 15:50:35 +0200 Subject: [PATCH 42/51] docs: isolate account details (#435) Co-authored-by: Chris de Almeida --- docs/contributing/captains_and_committers.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index 2a862bb..12467c9 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -5,7 +5,7 @@ - [`expressjs/body-parser`](https://github.com/expressjs/body-parser): - Captains: @jonchurch, @ulisesGascon - Committers: @Phillip9587 -- [`expressjs/codemod`](https://github.com/expressjs/codemod): @bjohansebas (npm: `@bsebas`), @kjugi (npm: `@filip.kudla`) +- [`expressjs/codemod`](https://github.com/expressjs/codemod): @bjohansebas, @kjugi - [`expressjs/compression`](https://github.com/expressjs/compression): - captains: @UlisesGascon - committers: @bjohansebas @@ -73,7 +73,7 @@ - [`pillarjs/hbs`](https://github.com/pillarjs/hbs): @ulisesGascon - [`pillarjs/multiparty`](https://github.com/pillarjs/multiparty): @blakeembrey - [`pillarjs/iconv-lite`](https://github.com/pillarjs/iconv-lite): - - Captains: @ashtuchkin, @bjohansebas (npm: `@bsebas`) + - Captains: @ashtuchkin, @bjohansebas - Committers: @Phillip9587 - [`pillarjs/parseurl`](https://github.com/pillarjs/parseurl): @blakeembrey - [`pillarjs/path-to-regexp`](https://github.com/pillarjs/path-to-regexp): @blakeembrey @@ -88,3 +88,17 @@ - [Triage team](https://github.com/expressjs/discussions/issues/227): @UlisesGascon - [Security WG](https://github.com/expressjs/security-wg): @UlisesGascon - [Perf WG](https://github.com/expressjs/perf-wg): @wesleytodd + +## Accounts details + +- @ashtuchkin (npm: [~ashtuchkin](https://www.npmjs.com/~ashtuchkin)) +- @bjohansebas (npm: [~bsebas](https://www.npmjs.com/~bsebas)) +- @blakeembrey (npm: [~blakeembrey](https://www.npmjs.com/~blakeembrey)) +- @crandmck (npm: [~crandmck](https://www.npmjs.com/~crandmck)) +- @ctcpip (npm: [~ctcpip](https://www.npmjs.com/~ctcpip)) +- @jonchurch (npm: [~jonchurch](https://www.npmjs.com/~jonchurch)) +- @kjugi (npm: [~filip.kudla](https://www.npmjs.com/~filip.kudla)) +- @LinusU (npm: [~linusu](https://www.npmjs.com/~linusu)) +- @seplu (npm: [~sheplu](https://www.npmjs.com/~sheplu)) +- @ulisesGascon (npm: [~ulisesgascon](https://www.npmjs.com/~ulisesgascon)) +- @wesleytodd (npm: [~wesleytodd](https://www.npmjs.com/~wesleytodd)) From 419042458bc350e1bb1e858b9283e2c393e1e7db Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Mon, 27 Oct 2025 17:27:59 +0100 Subject: [PATCH 43/51] docs: reflect cleanup initiative changes (#379) Related expressjs/discussions#134 removes 3 deprecated repos from the list (flash, connect-multiparty, express-paginate) and adds a new line denoting Ulises as captain of the initiative to deprecate repos --- docs/contributing/captains_and_committers.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index 12467c9..604d9bf 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -9,20 +9,17 @@ - [`expressjs/compression`](https://github.com/expressjs/compression): - captains: @UlisesGascon - committers: @bjohansebas -- [`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): - captains: @wesleytodd, @ulisesGascon - committers: @bjohansebas, @Phillip9587 - [`expressjs/expressjs.com`](https://github.com/expressjs/expressjs.com): - captains: @crandmck, @jonchurch, @bjohansebas - committers: @carlosstenzel, @chrisdel101, @ShubhamOulkar -- [`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 @@ -88,6 +85,7 @@ - [Triage team](https://github.com/expressjs/discussions/issues/227): @UlisesGascon - [Security WG](https://github.com/expressjs/security-wg): @UlisesGascon - [Perf WG](https://github.com/expressjs/perf-wg): @wesleytodd +- Archived repos and deprecated packages: @UlisesGascon ## Accounts details From 6a6b2b3410a846e0a6f03fccfee174809b450147 Mon Sep 17 00:00:00 2001 From: Wes Todd Date: Wed, 12 Nov 2025 03:28:01 -0600 Subject: [PATCH 44/51] fix(docs): Add @bjohansebas as Triage Team captain (#448) --- docs/contributing/captains_and_committers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index 604d9bf..0d2df96 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -82,7 +82,7 @@ ## Current Initiative Captains -- [Triage team](https://github.com/expressjs/discussions/issues/227): @UlisesGascon +- [Triage team](https://github.com/expressjs/discussions/issues/227): @UlisesGascon, @bjohansebas - [Security WG](https://github.com/expressjs/security-wg): @UlisesGascon - [Perf WG](https://github.com/expressjs/perf-wg): @wesleytodd - Archived repos and deprecated packages: @UlisesGascon From 752baf207bf15aa847d612282427252ef6330d1b Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Mon, 8 Dec 2025 14:11:45 -0500 Subject: [PATCH 45/51] docs: add Typescript captains members (#446) --- docs/contributing/captains_and_committers.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index 0d2df96..d53f3e8 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -85,6 +85,7 @@ - [Triage team](https://github.com/expressjs/discussions/issues/227): @UlisesGascon, @bjohansebas - [Security WG](https://github.com/expressjs/security-wg): @UlisesGascon - [Perf WG](https://github.com/expressjs/perf-wg): @wesleytodd +- [Typescript WG](https://github.com/expressjs/typescript-wg): @jonchurch, @bjohansebas - Archived repos and deprecated packages: @UlisesGascon ## Accounts details From 28a5533227616267f1b6388afe0ef409b65ae1ca Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Tue, 10 Feb 2026 07:22:58 -0500 Subject: [PATCH 46/51] docs: add @AugustinMauroy as commiter on codemod (#469) --- docs/contributing/captains_and_committers.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index d53f3e8..188f3a1 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -5,7 +5,9 @@ - [`expressjs/body-parser`](https://github.com/expressjs/body-parser): - Captains: @jonchurch, @ulisesGascon - Committers: @Phillip9587 -- [`expressjs/codemod`](https://github.com/expressjs/codemod): @bjohansebas, @kjugi +- [`expressjs/codemod`](https://github.com/expressjs/codemod): + - captains: @bjohansebas, @kjugi + - committers: @AugustinMauroy - [`expressjs/compression`](https://github.com/expressjs/compression): - captains: @UlisesGascon - committers: @bjohansebas From b55cc044ec052712f1862b970521b46f6320c015 Mon Sep 17 00:00:00 2001 From: Jean Burellier Date: Wed, 3 Dec 2025 20:48:44 +0100 Subject: [PATCH 47/51] chore: add difference between ADR and RFC --- README.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/README.md b/README.md index d904f66..1bf99e2 100644 --- a/README.md +++ b/README.md @@ -15,3 +15,17 @@ of nature. Current meeting schedule: Wednesdays 23:30 UTC Recordings of past meetings are available on the [Express Youtube Channel](https://www.youtube.com/channel/UCYjxjAeH6TRik9Iwy5nXw7g/videos). + +### RFC vs ADR — The Real Difference + +An **RFC** is a *collaboration tool*: its purpose is to surface a problem, +explore solutions, gather feedback, and drive alignment. +It is iterative, often long-form, and meant for broad input. +An RFC does **not** imply a decision — it is a decision-making *process*. + +An **ADR** is a *recording tool*: its purpose is to capture a decision +that has already been made, including context, trade-offs, and consequences. +It is concise, stable, and part of the architectural history of a system. +An ADR does **not** create alignment — it preserves it. + +In essence: **RFC = how we decide**, **ADR = what we decided and why**. From 815f1105be67da7370b437279d6aaa8663f6e22e Mon Sep 17 00:00:00 2001 From: Jean Burellier Date: Mon, 2 Mar 2026 19:50:55 +0100 Subject: [PATCH 48/51] chore: create template for RFC (#442) --- docs/rfc/0000-template.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 docs/rfc/0000-template.md diff --git a/docs/rfc/0000-template.md b/docs/rfc/0000-template.md new file mode 100644 index 0000000..7daabe5 --- /dev/null +++ b/docs/rfc/0000-template.md @@ -0,0 +1,35 @@ +# {{TITLE: a human-readable title for this RFC!}} + +## Summary + +{{A concise, one-paragraph description of the change.}} + +## Motivation + +{{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} + +## Detailed Explanation + +{{Describe the expected changes in detail, }} + +## Rationale and Alternatives + +{{Discuss 2-3 different alternative solutions that were considered. This is required, even if it seems like a stretch. Then explain why this is the best choice out of available ones.}} + +## Implementation + +{{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} + +{{THIS SECTION IS REQUIRED FOR RATIFICATION -- you can skip it if you don't know the technical details when first submitting the proposal, but it must be there before it's accepted}} + +## Prior Art + +{{This section is optional if there are no actual prior examples in other tools}} + +{{Discuss existing examples of this change in other tools, and how they've addressed various concerns discussed above, and what the effect of those decisions has been}} + +## Unresolved Questions and Bikeshedding + +{{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} + +{{THIS SECTION SHOULD BE REMOVED BEFORE RATIFICATION}} From 61129016c312aad2cae769e6774c356e4ed7cbca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Filip=20Kud=C5=82a?= <11212541+kjugi@users.noreply.github.com> Date: Wed, 1 Apr 2026 17:35:05 +0200 Subject: [PATCH 49/51] ADR: CommonJS and ESM decision (#323) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Create isomorphism-support init doc * update extension for file * Add Link to issue * Add another issue to the list * Update isomorphism-support.md * Update isomorphism-support.md * Update docs/adr/isomorphism-support.md Co-authored-by: Ulises Gascón * Update docs/adr/isomorphism-support.md Co-authored-by: Ulises Gascón * Update docs/adr/isomorphism-support.md Co-authored-by: Ulises Gascón * Update docs/adr/isomorphism-support.md Co-authored-by: Ulises Gascón * Apply suggestions from code review Co-authored-by: Ulises Gascón * Update isomorphism-support.md * Update docs/adr/isomorphism-support.md Co-authored-by: Chris de Almeida * Rename isomorphism-support.md to esm-support.md * Update esm-support.md * Apply suggestion from @wesleytodd Co-authored-by: Wes Todd * ✨ update ESM ADR for accuracy --------- Co-authored-by: Ulises Gascón Co-authored-by: Chris de Almeida Co-authored-by: Wes Todd --- docs/adr/323-esm-support.md | 92 +++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 docs/adr/323-esm-support.md diff --git a/docs/adr/323-esm-support.md b/docs/adr/323-esm-support.md new file mode 100644 index 0000000..6c7c53f --- /dev/null +++ b/docs/adr/323-esm-support.md @@ -0,0 +1,92 @@ +# ADR: ESM exports + +## Status + +Accepted + +## Submitters + +- @kjugi +- @wesleytodd +- @ctcpip + +## Decision Owners + +- @expressjs/express-tc + +## Context + +The document's objective is to gather all notable comments and thoughts in one place and track potential changes in this topic. We have noticed that it is repeated frequently in many issues from the community and we need to take action. + +We have acknowledged the need and discussion around it touched on multiple scenarios. Including: + +- rethinking the process and exposing both options (ESM and CommonJS) for all libraries +- expose both options (ESM and CommonJS) for selected libraries +- maintaining status quo as the main target is on the server + +**Why do we need this decision?** +We aimed to consolidate the Technical Committee's (TC) opinion on this topic. It is important to emphasize that Express is an HTTP framework specifically designed for Node.js. Additionally, some of our libraries are being utilized by the community in other environments. + +**What problem does it solve or avoid?** +Ambiguity and uncertainty for the community, alongside clear guidance for repository maintainers and contributors. + +**Are there any existing issues/discussions/pull requests related to this?** + +- +- +- +- + +## Decision + +Holistically, as a project/team, we will not make a dedicated effort to export our libraries in the ESM format. + +This applies to all [expressjs](https://github.com/expressjs), [pillarjs](https://github.com/pillarjs), or [jshttp](https://github.com/jshttp) packages. + +**However, repo captains, as the primary maintainers of packages, retain autonomy and discretion of whether or not they choose to support ESM exports directly.** + +### What will be done? + +Future issues and PRs regarding ESM exports may be closed with a link to this document. + +## Rationale + +During the [working session](https://github.com/expressjs/discussions/issues/320), we had an in-depth discussion about this topic. + +This decision is motivated by the lack of resources to maintain such an effort in the long term. It is also worth noting that Express was specifically designed to run with Node.js. + +At present, our libraries function seamlessly in Node.js, supporting both CommonJS and ESM. Transitioning to support additional scenarios, such as direct ESM exports, would require significant changes to our CI systems and additional maintenance overhead. + +While the JavaScript ecosystem has increasingly moved toward ESM due to its compatibility with browsers, enhanced tree-shaking capabilities (coming from bundler tools), and support for dynamic imports, there are still complexities and challenges associated with ESM. + +Adopting ESM for our libraries would require a significant investment of time and resources to ensure proper implementation and long-term maintenance. While it is not impossible to achieve, it represents a considerable effort. Moreover, the majority of our users already utilize our libraries in their projects, relying on bundlers to handle the necessary transformations without issues. + +- **Alternatives Considered:** + - Add ESM export to our libraries. CommonJS format is accepted by bundlers. +- **Why is this decision the best option?** + - Time and energy can be shifted to other topics. + +## Consequences + +- **Positive Impact**: It does not require supporting another set of tools and major release. +- **Negative Impact**: + - No guarantee the packages work in browser environments. + - Potential community library fork (to make it ESM-friendly) might lack security updates over time + - OSS library authors that use our packages in ESM native libs might suffer from a lack of support +- **Mitigations**: Package maintainers may decide to expose both CJS and ESM + +## References + +Support for commonjs imports in ESM code is available in the node. Described in docs: + +- + +Support for ESM modules imports in commonjs is available in recent LTS Node.js versions. Docs: + +- + +## Changelog + +Track changes or updates to this ADR over time. Include the date, author, and a brief description of each change. + +- **[2025-01-15] - [2026-04-01]**: [@kjugi, @ctcpip, @wesleytodd] - initial doc From 175e88ae3be4c82e5f45d58fd7e27692ea3764a6 Mon Sep 17 00:00:00 2001 From: Sebastian Beltran Date: Sat, 16 May 2026 12:19:28 -0500 Subject: [PATCH 50/51] docs: update expressjs.com members and add emeritus section (#460) * docs: update expressjs.com members and add emeritus section * Update docs/contributing/captains_and_committers.md * Update docs/contributing/captains_and_committers.md --- docs/contributing/captains_and_committers.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/docs/contributing/captains_and_committers.md b/docs/contributing/captains_and_committers.md index 188f3a1..45739f2 100644 --- a/docs/contributing/captains_and_committers.md +++ b/docs/contributing/captains_and_committers.md @@ -21,7 +21,7 @@ - committers: @bjohansebas, @Phillip9587 - [`expressjs/expressjs.com`](https://github.com/expressjs/expressjs.com): - captains: @crandmck, @jonchurch, @bjohansebas - - committers: @carlosstenzel, @chrisdel101, @ShubhamOulkar + - committers: @carlosstenzel @ShubhamOulkar - [`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 @@ -103,3 +103,9 @@ - @seplu (npm: [~sheplu](https://www.npmjs.com/~sheplu)) - @ulisesGascon (npm: [~ulisesgascon](https://www.npmjs.com/~ulisesgascon)) - @wesleytodd (npm: [~wesleytodd](https://www.npmjs.com/~wesleytodd)) + +## Emeritus Members + +- [`expressjs/expressjs.com`](https://github.com/expressjs/expressjs.com): + - triage: @juliogarciape @inigomarquinez + - committers: @chrisdel101 From 06a30f6f2439714fe15ff76539a7dd89e688d57d Mon Sep 17 00:00:00 2001 From: Sai Asish Y Date: Sat, 16 May 2026 22:31:57 -0700 Subject: [PATCH 51/51] docs: update link for Triager Guide in GOVERNANCE.md (#489) --- docs/GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/GOVERNANCE.md b/docs/GOVERNANCE.md index 99781c4..538ac01 100644 --- a/docs/GOVERNANCE.md +++ b/docs/GOVERNANCE.md @@ -61,7 +61,7 @@ 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). +[the triage process document](contributing/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