content(blog/events): add trip report of 2026 London summit#8840
content(blog/events): add trip report of 2026 London summit#8840legendecas wants to merge 1 commit intonodejs:mainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryLow Risk Overview Reviewed by Cursor Bugbot for commit c50d485. Bugbot is set up for automated code reviews on this repo. Configure here. |
👋 Codeowner Review RequestThe following codeowners have been identified for the changed files: Team reviewers: @nodejs/nodejs-website Please review the changes when you have a chance. Thank you! 🙏 |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 04ad983. Configure here.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8840 +/- ##
=======================================
Coverage 73.87% 73.87%
=======================================
Files 105 105
Lines 8883 8883
Branches 326 326
=======================================
Hits 6562 6562
Misses 2320 2320
Partials 1 1 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Pull request overview
Adds a new events blog post documenting the 2026 London Node.js Collaboration Summit, expanding the site’s historical archive of summit trip reports.
Changes:
- Introduces a new markdown blog post with frontmatter (date/category/title/layout/author).
- Adds a structured recap of summit sessions plus a “Thanks” section and reference links.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ### Next 10 | ||
|
|
||
| In this session, [Jacob Smith][] started an on-site review of the questions that would be asked in the [Next-10 survey for 2026](https://github.com/nodejs/next-10/issues/369), including suggestions to existing questions, questions and options to add or remove, and recent AI discussions. | ||
|
|
||
| ### New Release Schedule |
There was a problem hiding this comment.
The post jumps directly to ### headings without a preceding ## section, which is inconsistent with other Collab Summit trip reports and results in an incorrect heading hierarchy (and potentially inconsistent styling/TOC). Consider promoting these session headings to ## (and reserving ### for sub-sections where needed).
|
|
||
| This is a reflection of the current Node.js volunteer-based maintenance and an effort to keep the Node.js project sustainable in the long run. When it comes to security vulnerabilities, managing security releases across four or five active release lines has become difficult to sustain in the current Node.js voluntary work model. By reducing the number of concurrent release lines, the project can focus on better supporting the releases people actually use. | ||
|
|
||
| What's important is what's not changed with the new release schedule: |
There was a problem hiding this comment.
| What's important is what's not changed with the new release schedule: | |
| What's important is what's not changed with the new release schedule: | |
I think we just need to add a new line here for linting/prettier to pass
joyeecheung
left a comment
joyeecheung
left a comment
There was a problem hiding this comment.
Leaving some points that I think we need to cover before this can be published. I'll see if I can re-listen to the recordings to fill them in on Monday.
| ### Node.js Security - State of the Ecosystem & What's Next | ||
|
|
||
| [Rafael Gonzaga][] shared that the security team has recently advanced the ecosystem through a refined threat model, improved permission models, and enhanced release automation, but these efforts are currently being overshadowed by a massive influx of AI-generated vulnerability reports. This industry-wide surge, driven largely by users seeking CVE attribution and financial bounties, has severely strained maintainer capacity with high-noise, duplicative submissions that often lack reproduction steps or misclassify standard bugs as severe security threats. Despite attempted mitigations like pausing bug bounties, raising HackerOne signal requirements, and clarifying guidelines, the overwhelming volume has significantly driven up resolution times. To combat this bottleneck, the team is exploring strategies such as securing early access for proactive testing, attempting to alter reporting agent behaviors, and adopting a public security flow to bypass embargoes and speed up CI testing. | ||
|
|
There was a problem hiding this comment.
IIRC Robin presented a significant part of this. There was also the introduction of the two new programs which we should cover in the trip report.
There was a problem hiding this comment.
I could not find any public reference on the program so I didn't mention it here.
There was a problem hiding this comment.
@rginn Should we talk about this in the trip report a bit to give the readers a heads up that this is in the talks, or should we just skip talking about them? Note that the recording is public, so those who watch it can still see what's proposed and discussed.
There was a problem hiding this comment.
Oh actually I realized that part is in a separate session, though the recording is public https://www.youtube.com/watch?v=Vr2nrYENzSg
|
|
||
| ### Userland migrations | ||
|
|
||
| [Jacob Smith][] and [Marco Ippolito][] presented increased usage of userland migrations. Codemods for Node.js 22 to 24 are almost complete. For Node.js 25.9.0, a codemod was published the same day as the deprecation was introduced. |
There was a problem hiding this comment.
marco ? I didn't watch the record but I saw picture and that was bruno
|
|
||
| ### Next 10 | ||
|
|
||
| In this session, [Jacob Smith][] started an on-site review of the questions that would be asked in the [Next-10 survey for 2026](https://github.com/nodejs/next-10/issues/369), including suggestions to existing questions, questions and options to add or remove, and recent AI discussions. |
There was a problem hiding this comment.
| In this session, [Jacob Smith][] started an on-site review of the questions that would be asked in the [Next-10 survey for 2026](https://github.com/nodejs/next-10/issues/369), including suggestions to existing questions, questions and options to add or remove, and recent AI discussions. | |
| In this session, [Jacob Smith][] reviewed results from the Collaborator Health survey and compared health numbers between 2025 and 2026, as well as some key highlights from the 2025 user survey (including new areas, which have generally different usage); he and [Marco Ippolito][] led an on-site review of the questions that would be asked in the [Next-10 survey for 2026](https://github.com/nodejs/next-10/issues/369), including suggestions to existing questions, questions and options to add or remove, and recent AI discussions. |
|
|
||
| [Jacob Smith][] led the session on exploring ways to lower the barrier to entry for developers who want to contribute to the Node.js core, ensuring the project remains accessible to new talent. | ||
|
|
||
| Triaging issues and reviewing pull requests takes a massive amount of maintainer bandwidth. At the session we discussed ideas to enforce code ownership to encourage collaborators to take over more review work. Since in the Node.js voluntary work model, this can come with difficulties, we also brainstormed ideas about decoupling collaboratorship from the commit bits and extending reviewership to working group/team members, in order to encourage non-collaborators to review and build trust. |
There was a problem hiding this comment.
| Triaging issues and reviewing pull requests takes a massive amount of maintainer bandwidth. At the session we discussed ideas to enforce code ownership to encourage collaborators to take over more review work. Since in the Node.js voluntary work model, this can come with difficulties, we also brainstormed ideas about decoupling collaboratorship from the commit bits and extending reviewership to working group/team members, in order to encourage non-collaborators to review and build trust. | |
| We reached consensus on a new model, applying "code owners" to Core subsystems via teams wherein team members can approve (and block) PRs to their subsystem; team members will now be collaborators (with the new, narrowed purview and lower barrier to entry). A new "Maintainer" tier of membership will also be created with organisation-wide authority (similar to the current "collaborator" role) with a moderately high barrier to entry. |
There was a problem hiding this comment.
Did we reach consensus on something so concrete? I think we need to be very careful about concluding consensus in the trip report. My impression is that we only collected a lot of feedback and the room gravitated towards something roughly in a direction and will continue iterating on this in GitHub, which can be said about everything that did not have a very explicit "do we have consensus in the room about this and this? no objections? then at least we have consensus in the room!" moment - and even if so any consensus in the room must be very explicitly described as being limited to the room, not the project, to prevent the reader from thinking we would make any decisions in a summit in the absence of a lot of contributors.
(Personally I remember I raised the point that core subsystems are the wrong way to group people and we discussed at length about fs as an example. We only very roughly agree that using GitHub teams is in the right direction but specifically how the teams should be formed is very much in the air. I don't recall we reached any consensus about a organization-wide maintainer status or discussed much about org-wide permissions)
There was a problem hiding this comment.
do we have consensus in the room about this and this? no objections? then at least we have consensus in the room!
This did happen. Crap—was it when you had to duck out coughing? 😨
My impression is that we only collected a lot of feedback and the room gravitated towards something roughly in a direction and will continue iterating on this in GitHub
There was definitely a lotta good feedback. From speaking to others afterwards, they also seemed to understand we had ultimately reached a fairly concrete consensus and path forward though.
Personally I remember I raised the point that core subsystems are the wrong way to group people and we discussed at length about fs as an example.
I recall the FS point (it was a good one), but my recollection was that that was resolved (specifically, James had the winning idea). If it's not, could you please let me know what part of the resolution was incomplete?
but specifically how the teams should be formed is very much in the air
Could you clarify this? I don't recall ambiguity on this in the end.
PS I wrote up a summary and tagged you on it. I think there would be a better place to have this discussion.
There was a problem hiding this comment.
Yeah I think that might've happened when I stepped out. I'll take a look at the summary when I have the cycles, thanks. For the trip report specifically I think we should avoid talking about concrete consensus if there's any doubt and just reflect what's been discussed.
There was a problem hiding this comment.
Okay 🙂 as you said, it would be limited to the room anyway, so not a full consensus—nothing landed yet.
| Triaging issues and reviewing pull requests takes a massive amount of maintainer bandwidth. At the session we discussed ideas to enforce code ownership to encourage collaborators to take over more review work. Since in the Node.js voluntary work model, this can come with difficulties, we also brainstormed ideas about decoupling collaboratorship from the commit bits and extending reviewership to working group/team members, in order to encourage non-collaborators to review and build trust. | |
| We reached broad-strokes of a plan forward via a new model, applying "code owners" to Core subsystems via teams wherein team members can approve (and block) PRs to their subsystem; team members would now be collaborators (with the new, narrowed purview and lower barrier to entry). A new "Maintainer" tier of membership would also be created with organisation-wide authority (similar to the current "collaborator" role) with a moderately high barrier to entry. |
|
|
||
| ### Userland migrations | ||
|
|
||
| [Jacob Smith][] and [Marco Ippolito][] presented increased usage of userland migrations. Codemods for Node.js 22 to 24 are almost complete. For Node.js 25.9.0, a codemod was published the same day as the deprecation was introduced. |
There was a problem hiding this comment.
| [Jacob Smith][] and [Marco Ippolito][] presented increased usage of userland migrations. Codemods for Node.js 22 to 24 are almost complete. For Node.js 25.9.0, a codemod was published the same day as the deprecation was introduced. | |
| [Jacob Smith][] and [Bruno Rodrigues][] presented increased usage of userland migrations. Migrations for Node.js 22.x to 24.x deprecations are almost complete. For Node.js 25.9.0, a codemod was published along side the deprecation introduced. |
| [Jacob Smith]: https://github.com/JakobJingleheimer | ||
| [Rafael Gonzaga]: https://github.com/RafaelGSS | ||
| [Chengzhong Wu]: https://github.com/legendecas | ||
| [Joyee Cheung]: https://github.com/joyeecheung | ||
| [Matteo Collina]: https://github.com/mcollina | ||
| [Stephen Belanger]: https://github.com/Qard | ||
| [James Snell]: https://github.com/jasnell | ||
| [Santiago Gimeno]: https://github.com/santigimeno | ||
| [Bryan English]: https://github.com/bengl | ||
| [Marco Ippolito]: https://github.com/marco-ippolito | ||
| [Bloomberg]: https://www.bloomberg.com/company/values/tech-at-bloomberg/ |
There was a problem hiding this comment.
Alphabetise for grokkability and add Bruno Rodrigues
| [Jacob Smith]: https://github.com/JakobJingleheimer | |
| [Rafael Gonzaga]: https://github.com/RafaelGSS | |
| [Chengzhong Wu]: https://github.com/legendecas | |
| [Joyee Cheung]: https://github.com/joyeecheung | |
| [Matteo Collina]: https://github.com/mcollina | |
| [Stephen Belanger]: https://github.com/Qard | |
| [James Snell]: https://github.com/jasnell | |
| [Santiago Gimeno]: https://github.com/santigimeno | |
| [Bryan English]: https://github.com/bengl | |
| [Marco Ippolito]: https://github.com/marco-ippolito | |
| [Bloomberg]: https://www.bloomberg.com/company/values/tech-at-bloomberg/ | |
| [Bloomberg]: https://www.bloomberg.com/company/values/tech-at-bloomberg/ | |
| [Bruno Rodrigues]: https://github.com/brunocroh | |
| [Bryan English]: https://github.com/bengl | |
| [Chengzhong Wu]: https://github.com/legendecas | |
| [Jacob Smith]: https://github.com/JakobJingleheimer | |
| [James Snell]: https://github.com/jasnell | |
| [Joyee Cheung]: https://github.com/joyeecheung | |
| [Marco Ippolito]: https://github.com/marco-ippolito | |
| [Matteo Collina]: https://github.com/mcollina | |
| [Rafael Gonzaga]: https://github.com/RafaelGSS | |
| [Santiago Gimeno]: https://github.com/santigimeno | |
| [Stephen Belanger]: https://github.com/Qard |
|
|
||
| [Matteo Collina][] presented the proposal for a Node.js built-in Virtual File System. By taking concepts previously explored in userland libraries (like `@platformatic/vfs`) and standardizing them into a core `node:vfs` module, Node.js can intercept standard filesystem calls and route them through a virtualized, memory-based layer. Developers can define specific data sources in memory (providers) and "mount" them so the runtime treats them exactly like local directories. The proposal also provides the ability to layer virtual filesystems on top of one another, or place a virtual layer directly over the physical disk to safely mock or override files. | ||
|
|
||
| Userland VFS implementations require massive monkey-patching; moving it to core provides deep integration and supports more use cases like SEA. |
There was a problem hiding this comment.
I think this covered most points discussed:
| Userland VFS implementations require massive monkey-patching; moving it to core provides deep integration and supports more use cases like SEA. | |
| In this session, Matteo walked the audience through the motivation of this feature: making file system virtualization easier for single-executable applications and testing, and replaces existing brittle practices that achieve this through user-land monkey-patching. Following a brief overview of the implementation architecture and the design choices, we collected more feedback on the PR, including stack trace visibility, observability, security, worker thread propagation, the ability to toggle it in specific paths, and support in native code. We'll continue iterating on this PR in GitHub. |
|
|
||
| ### Node.js Security - State of the Ecosystem & What's Next | ||
|
|
||
| [Rafael Gonzaga][] shared that the security team has recently advanced the ecosystem through a refined threat model, improved permission models, and enhanced release automation, but these efforts are currently being overshadowed by a massive influx of AI-generated vulnerability reports. This industry-wide surge, driven largely by users seeking CVE attribution and financial bounties, has severely strained maintainer capacity with high-noise, duplicative submissions that often lack reproduction steps or misclassify standard bugs as severe security threats. Despite attempted mitigations like pausing bug bounties, raising HackerOne signal requirements, and clarifying guidelines, the overwhelming volume has significantly driven up resolution times. To combat this bottleneck, the team is exploring strategies such as securing early access for proactive testing, attempting to alter reporting agent behaviors, and adopting a public security flow to bypass embargoes and speed up CI testing. |
There was a problem hiding this comment.
Looks like we overlooked the VEX effort.
| [Rafael Gonzaga][] shared that the security team has recently advanced the ecosystem through a refined threat model, improved permission models, and enhanced release automation, but these efforts are currently being overshadowed by a massive influx of AI-generated vulnerability reports. This industry-wide surge, driven largely by users seeking CVE attribution and financial bounties, has severely strained maintainer capacity with high-noise, duplicative submissions that often lack reproduction steps or misclassify standard bugs as severe security threats. Despite attempted mitigations like pausing bug bounties, raising HackerOne signal requirements, and clarifying guidelines, the overwhelming volume has significantly driven up resolution times. To combat this bottleneck, the team is exploring strategies such as securing early access for proactive testing, attempting to alter reporting agent behaviors, and adopting a public security flow to bypass embargoes and speed up CI testing. | |
| [Rafael Gonzaga][] shared that the security team has recently advanced the ecosystem through a refined threat model, improved permission models, and enhanced release automation, and the new VEX (Vulnerability Exploitability eXchange) files that the security team is working on to reduce false positives for security scanners. | |
| These efforts are currently being overshadowed by a massive influx of AI-generated vulnerability reports. This industry-wide surge, driven largely by users seeking CVE attribution and financial bounties, has severely strained maintainer capacity with high-noise, duplicative submissions that often lack reproduction steps or misclassify standard bugs as severe security threats. Despite attempted mitigations like pausing bug bounties, raising HackerOne signal requirements, and clarifying guidelines, the overwhelming volume has significantly driven up resolution times. To combat this bottleneck, the team is exploring strategies such as securing early access for proactive testing, attempting to alter reporting agent behaviors, and adopting a public security flow to bypass embargoes and speed up CI testing. |
| ### Node.js Security - State of the Ecosystem & What's Next | ||
|
|
||
| [Rafael Gonzaga][] shared that the security team has recently advanced the ecosystem through a refined threat model, improved permission models, and enhanced release automation, but these efforts are currently being overshadowed by a massive influx of AI-generated vulnerability reports. This industry-wide surge, driven largely by users seeking CVE attribution and financial bounties, has severely strained maintainer capacity with high-noise, duplicative submissions that often lack reproduction steps or misclassify standard bugs as severe security threats. Despite attempted mitigations like pausing bug bounties, raising HackerOne signal requirements, and clarifying guidelines, the overwhelming volume has significantly driven up resolution times. To combat this bottleneck, the team is exploring strategies such as securing early access for proactive testing, attempting to alter reporting agent behaviors, and adopting a public security flow to bypass embargoes and speed up CI testing. | ||
|
|
There was a problem hiding this comment.
| In the session we revisited a thought-provoking proposal of making the security triage and bugfix process completely public to prevent a false sense of security in the age of AI, and to get rid of the CI embargo that has made testing inefficient. We discussed a few middle ground solutions, including keeping extending the visibility to more members in the organization, handling vulnerabilities of different severity with different visibility settings, and creating better documentations to drive AI agents away from generating false positive reports. |
|
|
||
| [Santiago Gimeno][] shared that after more than a decade on version 1, there is a renewed push to launch libuv [v2](https://github.com/libuv/libuv/issues/4622), which introduces necessary breaking changes to clean up the codebase, remove legacy APIs, and improve cross-platform consistency—capabilities already being leveraged by [Julia](https://julialang.org/). | ||
|
|
||
| As migrating to libuv v2 can break the ABI, we discussed ideas on how to mitigate it, for example by leveraging [Node-API](https://nodejs.org/api/n-api.html), and the nuances in this approach e.g. [`napi_get_uv_event_loop`](https://nodejs.org/api/n-api.html#napi-get-uv-event-loop) can still be impacted by libuv ABI changes, though its use is limited and its ABI stability is warned in the documentation. |
There was a problem hiding this comment.
| As migrating to libuv v2 can break the ABI, we discussed ideas on how to mitigate it, for example by leveraging [Node-API](https://nodejs.org/api/n-api.html), and the nuances in this approach e.g. [`napi_get_uv_event_loop`](https://nodejs.org/api/n-api.html#napi-get-uv-event-loop) can still be impacted by libuv ABI changes, though its use is limited and its ABI stability is warned in the documentation. | |
| As migrating to libuv v2 can break the ABI, we discussed ideas on how to mitigate it, for example by leveraging [Node-API](https://nodejs.org/api/n-api.html), and the nuances in this approach e.g. [`napi_get_uv_event_loop`](https://nodejs.org/api/n-api.html#napi-get-uv-event-loop) can still be impacted by libuv ABI changes, though its use is limited and its ABI stability is warned in the documentation. We also discussed getting help to maintain v1 with security patches for a limited timespan, how to bring back `io_uring`, and which Node.js can start to ship libuv v2 (a very tentative timeline could be in 27). |
|
Since the recordings are out it may be useful to add links to them for each session, though it sounds like chores that may be better handled by an AI :) |
Description
Validation
Related Issues
Check List
pnpm formatto ensure the code follows the style guide.pnpm testto check if all tests are passing.pnpm buildto check if the website builds without errors.