2025-04-01, Version 23.11.0 (Current)

.github/SUPPORT.md

@@ -7,9 +7,10 @@ Node.js](https://github.com/nodejs/Release#release-schedule).
 When looking for support, please first search for your question in these venues:
 
 * [Node.js Website](https://nodejs.org/en/), especially the
-  [API docs](https://nodejs.org/api/)
-* [Node.js Help](https://github.com/nodejs/help)
+  [API docs](https://nodejs.org/api/) or the [Learn material](https://nodejs.org/en/learn)
+* [Node.js's GitHub Help repository](https://github.com/nodejs/help)
 * [Open or closed issues in the Node.js GitHub organization](https://github.com/issues?utf8=%E2%9C%93&q=sort%3Aupdated-desc+org%3Anodejs+is%3Aissue)
+* [Ask for support on Node.js's Discord server](https://nodejs.org/discord)
 
 If you didn't find an answer in the resources above, try these unofficial
 resources:
@@ -19,7 +20,7 @@ resources:
 * [Node.js Slack Community](https://node-js.slack.com/)
   * To register: [nodeslackers.com](https://www.nodeslackers.com/)
 
-GitHub issues are for tracking enhancements and bugs, not general support.
+**GitHub issues are for tracking enhancements and bugs, not general support.**
 
 The open source license grants you the freedom to use Node.js. It does not
 guarantee commitments of other people's time. Please be respectful and manage

.github/workflows/build-tarball.yml

@@ -50,9 +50,9 @@ jobs:
         with:
           python-version: ${{ env.PYTHON_VERSION }}
       - name: Set up sccache
-        uses: mozilla-actions/sccache-action@054db53350805f83040bf3e6e9b8cf5a139aa7c9  # v0.0.7
+        uses: Mozilla-Actions/sccache-action@65101d47ea8028ed0c98a1cdea8dd9182e9b5133  # v0.0.8
         with:
-          version: v0.9.1
+          version: v0.10.0
       - name: Environment Information
         run: npx envinfo
       - name: Make tarball
@@ -80,9 +80,9 @@ jobs:
         with:
           python-version: ${{ env.PYTHON_VERSION }}
       - name: Set up sccache
-        uses: mozilla-actions/sccache-action@054db53350805f83040bf3e6e9b8cf5a139aa7c9  # v0.0.7
+        uses: Mozilla-Actions/sccache-action@65101d47ea8028ed0c98a1cdea8dd9182e9b5133  # v0.0.8
         with:
-          version: v0.8.1
+          version: v0.10.0
       - name: Environment Information
         run: npx envinfo
       - name: Download tarball

.github/workflows/close-stalled.yml

@@ -32,7 +32,5 @@ jobs:
           only-labels: stalled
           # max requests it will send per run to the GitHub API before it deliberately exits to avoid hitting API rate limits
           operations-per-run: 500
-          # deactivates automatic removal of stalled label if issue gets any activity
-          remove-stale-when-updated: false
           # deactivates automatic stale labelling as we prefer to do that manually
           days-before-stale: -1

.github/workflows/coverage-linux-without-intl.yml

@@ -56,9 +56,9 @@ jobs:
         with:
           python-version: ${{ env.PYTHON_VERSION }}
       - name: Set up sccache
-        uses: mozilla-actions/sccache-action@054db53350805f83040bf3e6e9b8cf5a139aa7c9  # v0.0.7
+        uses: Mozilla-Actions/sccache-action@65101d47ea8028ed0c98a1cdea8dd9182e9b5133  # v0.0.8
         with:
-          version: v0.9.1
+          version: v0.10.0
       - name: Environment Information
         run: npx envinfo
       - name: Install gcovr

.github/workflows/coverage-linux.yml

@@ -56,9 +56,9 @@ jobs:
         with:
           python-version: ${{ env.PYTHON_VERSION }}
       - name: Set up sccache
-        uses: mozilla-actions/sccache-action@054db53350805f83040bf3e6e9b8cf5a139aa7c9  # v0.0.7
+        uses: Mozilla-Actions/sccache-action@65101d47ea8028ed0c98a1cdea8dd9182e9b5133  # v0.0.8
         with:
-          version: v0.9.1
+          version: v0.10.0
       - name: Environment Information
         run: npx envinfo
       - name: Install gcovr

.github/workflows/test-linux.yml

@@ -50,9 +50,9 @@ jobs:
         with:
           python-version: ${{ env.PYTHON_VERSION }}
       - name: Set up sccache
-        uses: mozilla-actions/sccache-action@054db53350805f83040bf3e6e9b8cf5a139aa7c9  # v0.0.7
+        uses: Mozilla-Actions/sccache-action@65101d47ea8028ed0c98a1cdea8dd9182e9b5133  # v0.0.8
         with:
-          version: v0.9.1
+          version: v0.10.0
       - name: Environment Information
         run: npx envinfo
       - name: Build

.github/workflows/test-macos.yml

@@ -58,9 +58,9 @@ jobs:
       - name: Set up Xcode ${{ env.XCODE_VERSION }}
         run: sudo xcode-select -s /Applications/Xcode_${{ env.XCODE_VERSION }}.app
       - name: Set up sccache
-        uses: mozilla-actions/sccache-action@054db53350805f83040bf3e6e9b8cf5a139aa7c9  # v0.0.7
+        uses: Mozilla-Actions/sccache-action@65101d47ea8028ed0c98a1cdea8dd9182e9b5133  # v0.0.8
         with:
-          version: v0.9.1
+          version: v0.10.0
       - name: Environment Information
         run: npx envinfo
       # The `npm ci` for this step fails a lot as part of the Test step. Run it

.github/workflows/update-openssl.yml

@@ -35,7 +35,7 @@ jobs:
           author: Node.js GitHub Bot <[email protected]>
           body: This is an automated update of OpenSSL to ${{ env.NEW_VERSION }}.
           branch: actions/tools-update-openssl  # Custom branch *just* for this Action.
-          commit-message: 'deps: upgrade openssl sources to quictls/openssl-${{ env.NEW_VERSION }}'
+          commit-message: 'deps: upgrade openssl sources to openssl-${{ env.NEW_VERSION }}'
           labels: dependencies, openssl
           title: 'deps: update OpenSSL to ${{ env.NEW_VERSION }}'
           path: deps/openssl

.github/workflows/update-wpt.yml

@@ -3,7 +3,7 @@ name: WPT update
 on:
   schedule:
     # Run once a week at 12:00 AM UTC on Sunday.
-    - cron: 0 0 * * *
+    - cron: 0 0 * * 0
   workflow_dispatch:
     inputs:
       subsystems:
@@ -70,7 +70,11 @@ jobs:
       - name: Open or update PR for the subsystem update
         uses: gr2m/create-or-update-pull-request-action@77596e3166f328b24613f7082ab30bf2d93079d5
         with:
-          branch: actions/update-wpt-${{ matrix.subsystem }}
+          # The create-or-update-pull-request-action matches the branch name by prefix,
+          # which is why we need to add the -wpt suffix. If we dont do that, we risk matching wrong PRs,
+          # like for example "url" mistakenly matching and updating the "urlpattern" PR
+          # as seen in https://github.com/nodejs/node/pull/57368
+          branch: actions/update-${{ matrix.subsystem }}-wpt
           author: Node.js GitHub Bot <[email protected]>
           title: 'test: update WPT for ${{ matrix.subsystem }} to ${{ env.short_version }}'
           commit-message: 'test: update WPT for ${{ matrix.subsystem }} to ${{ env.short_version }}'

CHANGELOG.md

@@ -39,7 +39,8 @@ release.
 </tr>
 <tr>
   <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V23.md#23.10.0">23.10.0</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V23.md#23.11.0">23.11.0</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V23.md#23.10.0">23.10.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V23.md#23.9.0">23.9.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V23.md#23.8.0">23.8.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V23.md#23.7.0">23.7.0</a><br/>

GOVERNANCE.md

@@ -144,10 +144,71 @@ Contributions can be:
 * Participation in other projects, teams, and working groups of the Node.js
   organization.
 
+Collaborators should be people volunteering to do unglamorous work because it's
+the right thing to do, they find the work itself satisfying, and they care about
+Node.js and its users. People should get collaborator status because they're
+doing work and are likely to continue doing work where having the abilities that
+come with collaborator status are helpful (abilities like starting CI jobs,
+reviewing and approving PRs, etc.). That will usually--but, very importantly, not
+always--be work involving committing to the `nodejs/node` repository. For an example
+of an exception, someone working primarily on the website might benefit from being
+able to start Jenkins CI jobs to test changes to documentation tooling. That,
+along with signals indicating commitment to Node.js, personal integrity, etc.,
+should be enough for a successful nomination.
+
+It is important to understand that potential collaborators may have vastly
+different areas and levels of expertise, interest, and skill. The Node.js
+project is large and complex, and it is not expected that every collaborator
+will have the same level of expertise in every area of the project. The
+complexity or "sophistication" of an individual’s contributions, or even their
+relative engineering "skill" level, are not primary factors in determining
+whether they should be a collaborator. The primary factors do include the quality
+of their contributions (do the contributions make sense, do they add value, do
+they follow documented guidelines, are they authentic and well-intentioned,
+etc.), their commitment to the project, can their judgement be trusted, and do
+they have the ability to work well with others.
+
+#### The Authenticity of Contributors
+
+The Node.js project does not require that contributors use their legal names or
+provide any personal information verifying their identity.
+
+It is not uncommon for malicious actors to attempt to gain commit access to
+open-source projects in order to inject malicious code or for other nefarious
+purposes. The Node.js project has a number of mechanisms in place to prevent
+this, but it is important to be vigilant. If you have concerns about the
+authenticity of a contributor, please raise them with the TSC. Anyone nominating
+a new collaborator should take reasonable steps to verify that the contributions
+of the nominee are authentic and made in good faith. This is not always easy,
+but it is important.
+
 ### Nominating a new Collaborator
 
-To nominate a new Collaborator, open an issue in the [nodejs/node][] repository.
-Provide a summary of the nominee's contributions. For example:
+To nominate a new Collaborator:
+
+1. **Optional but strongly recommended**: open a
+   [discussion in the nodejs/collaborators][] repository. Provide a summary of
+   the nominee's contributions (see below for an example).
+2. **Optional but strongly recommended**: After sufficient wait time (e.g. 72
+   hours), if the nomination proposal has received some support and no explicit
+   block, and any questions/concerns have been addressed, add a comment in the
+   private discussion stating you're planning on opening a public issue, e.g.
+   "I see a number of approvals and no block, I'll be opening a public
+   nomination issue if I don't hear any objections in the next 72 hours".
+3. **Optional but strongly recommended**: Privately contact the nominee to make
+   sure they're comfortable with the nomination.
+4. Open an issue in the [nodejs/node][] repository. Provide a summary of
+   the nominee's contributions (see below for an example). Mention
+   @nodejs/collaborators in the issue to notify other collaborators about
+   the nomination.
+
+The _Optional but strongly recommended_ steps are optional in the sense that
+skipping them would not invalidate the nomination, but it could put the nominee
+in a very awkward situation if a nomination they didn't ask for pops out of
+nowhere only to be rejected. Do not skip those steps unless you're absolutely
+certain the nominee is fine with the public scrutiny.
+
+Example of list of contributions:
 
 * Commits in the [nodejs/node][] repository.
   * Use the link `https://github.com/nodejs/node/commits?author=GITHUB_ID`
@@ -166,22 +227,65 @@ Provide a summary of the nominee's contributions. For example:
   organization
 * Other participation in the wider Node.js community
 
-Mention @nodejs/collaborators in the issue to notify other collaborators about
-the nomination.
-
-The nomination passes if no collaborators oppose it after one week. In the case
-of an objection, the TSC is responsible for working with the individuals
-involved and finding a resolution.
-
-There are steps a nominator can take in advance to make a nomination as
-frictionless as possible. To request feedback from other collaborators in
-private, use the [collaborators discussion page][]
-(which only collaborators may view). A nominator may also work with the
-nominee to improve their contribution profile.
-
-Collaborators might overlook someone with valuable contributions. In that case,
-the contributor may open an issue or contact a collaborator to request a
-nomination.
+The nomination passes if no collaborators oppose it (as described in the
+following section) after one week. In the case of an objection, the TSC is
+responsible for working with the individuals involved and finding a resolution.
+The TSC may, following typical TSC consensus seeking processes, choose to
+advance a nomination that has otherwise failed to reach a natural consensus or
+clear path forward even if there are outstanding objections. The TSC may also
+choose to prevent a nomination from advancing if the TSC determines that any
+objections have not been adequately addressed.
+
+#### How to review a collaborator nomination
+
+A collaborator nomination can be reviewed in the same way one would review a PR
+adding a feature:
+
+* If you see the nomination as something positive to the project, say so!
+* If you are neutral, or feel you don't know enough to have an informed opinion,
+  it's certainly OK to not interact with the nomination.
+* If you think the nomination was made too soon, or can be detrimental to the
+  project, share your concerns. See the section "How to oppose a collaborator
+  nomination" below.
+
+Our goal is to keep gate-keeping at a minimal, but it cannot be zero since being
+a collaborator requires trust (collaborators can start CI jobs, use their veto,
+push commits, etc.), so what's the minimal amount is subjective, and there will
+be cases where collaborators disagree on whether a nomination should move
+forward.
+
+Refrain from discussing or debating aspects of the nomination process
+itself directly within a nomination private discussion or public issue.
+Such discussions can derail and frustrate the nomination causing unnecessary
+friction. Move such discussions to a separate issue or discussion thread.
+
+##### How to oppose a collaborator nomination
+
+An important rule of thumb is that the nomination process is intended to be
+biased strongly towards implicit approval of the nomination. This means
+discussion and review around the proposal should be more geared towards "I have
+reasons to say no..." as opposed to "Give me reasons to say yes...".
+
+Given that there is no "Request for changes" feature in discussions and issues,
+try to be explicit when your comment is expressing a blocking concern.
+Similarly, once the blocking concern has been addressed, explicitly say so.
+
+Explicit opposition would typically be signaled as some form of clear
+and unambiguous comment like, "I don't believe this nomination should pass".
+Asking clarifying questions or expressing general concerns is not the same as
+explicit opposition; however, a best effort should be made to answer such
+questions or addressing those concerns before advancing the nomination.
+
+Opposition does not need to be public. Ideally, the comment showing opposition,
+and any discussion thereof, should be done in the private discussion _before_
+the public issue is opened. Opposition _should_ be paired with clear suggestions
+for positive, concrete, and unambiguous next steps that the nominee can take to
+overcome the objection and allow it to move forward. While such suggestions are
+technically optional, they are _strongly encouraged_ to prevent the nomination
+from stalling indefinitely or objections from being overridden by the TSC.
+
+Remember that all private discussions about a nomination will be visible to
+the nominee once they are onboarded.
 
 ### Onboarding
 
@@ -196,6 +300,6 @@ The TSC follows a [Consensus Seeking][] decision-making model per the
 
 [Consensus Seeking]: https://en.wikipedia.org/wiki/Consensus-seeking_decision-making
 [TSC Charter]: https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md
-[collaborators discussion page]: https://github.com/nodejs/collaborators/discussions/categories/collaborator-nominations
+[discussion in the nodejs/collaborators]: https://github.com/nodejs/collaborators/discussions/categories/collaborator-nominations
 [nodejs/help]: https://github.com/nodejs/help
 [nodejs/node]: https://github.com/nodejs/node

LICENSE

@@ -366,7 +366,7 @@ The externally maintained libraries used by Node.js are:
 
     COPYRIGHT AND PERMISSION NOTICE
 
-    Copyright © 2016-2024 Unicode, Inc.
+    Copyright © 2016-2025 Unicode, Inc.
 
     NOTICE TO USER: Carefully read the following legal agreement. BY
     DOWNLOADING, INSTALLING, COPYING OR OTHERWISE USING DATA FILES, AND/OR

README.md

@@ -403,8 +403,6 @@ For information about the governance of the Node.js project, see
   **Moshe Atlow** <<[email protected]>> (he/him)
 * [MrJithil](https://github.com/MrJithil) -
   **Jithil P Ponnan** <<[email protected]>> (he/him)
-* [ovflowd](https://github.com/ovflowd) -
-  **Claudio Wunder** <<[email protected]>> (he/they)
 * [panva](https://github.com/panva) -
   **Filip Skokan** <<[email protected]>> (he/him)
 * [pimterry](https://github.com/pimterry) -
@@ -629,6 +627,8 @@ For information about the governance of the Node.js project, see
   **Alexis Campailla** <<[email protected]>>
 * [othiym23](https://github.com/othiym23) -
   **Forrest L Norvell** <<[email protected]>> (they/them/themself)
+* [ovflowd](https://github.com/ovflowd) -
+  **Claudio Wunder** <<[email protected]>> (he/they)
 * [oyyd](https://github.com/oyyd) -
   **Ouyang Yadong** <<[email protected]>> (he/him)
 * [petkaantonov](https://github.com/petkaantonov) -
@@ -739,6 +739,8 @@ maintaining the Node.js project.
   **Chemi Atlow** <<[email protected]>> (he/him)
 * [Ayase-252](https://github.com/Ayase-252) -
   **Qingyu Deng** <<[email protected]>>
+* [bjohansebas](https://github.com/bjohansebas) -
+  **Sebastian Beltran** <<[email protected]>>
 * [bmuenzenmeyer](https://github.com/bmuenzenmeyer) -
   **Brian Muenzenmeyer** <<[email protected]>> (he/him)
 * [CanadaHonk](https://github.com/CanadaHonk) -
@@ -749,6 +751,8 @@ maintaining the Node.js project.
   **Feng Yu** <<[email protected]>> (he/him)
 * [gireeshpunathil](https://github.com/gireeshpunathil) -
   **Gireesh Punathil** <<[email protected]>> (he/him)
+* [gurgunday](https://github.com/gurgunday) -
+  **Gürgün Dayıoğlu** <<[email protected]>>
 * [iam-frankqiu](https://github.com/iam-frankqiu) -
   **Frank Qiu** <<[email protected]>> (he/him)
 * [KevinEady](https://github.com/KevinEady) -
@@ -757,8 +761,6 @@ maintaining the Node.js project.
   **Akhil Marsonya** <<[email protected]>> (he/him)
 * [meixg](https://github.com/meixg) -
   **Xuguang Mei** <<[email protected]>> (he/him)
-* [mertcanaltin](https://github.com/mertcanaltin) -
-  **Mert Can Altin** <<[email protected]>>
 * [preveen-stack](https://github.com/preveen-stack) -
   **Preveen Padmanabhan** <<[email protected]>> (he/him)
 * [RaisinTen](https://github.com/RaisinTen) -