Skip to content

Commit 9c5a772

Browse files
committed
content(blog/events): add trip report of 2026 London summit
1 parent 97e28c5 commit 9c5a772

1 file changed

Lines changed: 109 additions & 0 deletions

File tree

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
---
2+
date: '2026-04-24T00:00:00.000Z'
3+
category: events
4+
title: 'Trip report: Node.js collaboration summit (2026 London)'
5+
layout: blog-post
6+
author: Chengzhong Wu, Joyee Cheung
7+
---
8+
9+
This April, the first [Node.js Collaboration Summit](https://nodejs.org/en/about/get-involved/collab-summit) of 2026 was hosted by [Bloomberg][] in London. In this edition, we welcomed over 40 in-person participants, and around a dozen more joined remotely.
10+
11+
Here is a recap of what happened at the summit.
12+
13+
### Next 10
14+
15+
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.
16+
17+
### New Release Schedule
18+
19+
Rafael Gonzaga announced a [new release schedule](https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule) going into effect starting with Node.js v27. TL;DR, starting with Node.js v27, the Node.js version numbers align with the calendar year of their initial Current release!
20+
21+
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.
22+
23+
What's important is what's not changed with the new release schedule:
24+
- **The Long-Term Support duration** remains similar (30 months).
25+
- **Migration windows** preserved. Overlap between LTS versions remains.
26+
- **Quality standards** unchanged. Same testing, same CITGM, same security process.
27+
- **Predictable schedule**. April releases, October LTS promotion.
28+
- **V8 adoption cycle**. Node.js latest releases will still include a version of V8 that's at most about 6 months old.
29+
30+
### New Streams API
31+
32+
[James Snell][] presented a new, more unified Streams API for the Web and Node.js. Historically, Node.js has relied on the highly optimized `node:stream`. In recent years, Node.js has also implemented WHATWG Web Streams to ensure cross-platform compatibility with browsers, Deno, Bun, and edge environments (like Cloudflare Workers). However, managing two different stream ecosystems has created friction for developers.
33+
34+
The Web Streams API has significant promise and allocation overhead. It was designed primarily for browsers, and when applied to high-throughput backend environments, the architectural cost becomes obvious.
35+
36+
The proposed New Streams API takes advantage of modern JavaScript Async Iteration, treats streams natively as async iterables, leaning heavily into `async/await` and `for await...of` loops, which is how modern developers naturally write code. Handling a filled data buffer has historically been a confusing black box. The new API also proposes forcing developers to explicitly choose a backpressure strategy when a buffer is full.
37+
38+
### Node.js Collaboratorship
39+
40+
[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.
41+
42+
Triaging issues and reviewing pull requests takes a massive amount of maintainer bandwidth. There were also discussions about enforcing code ownership to improve review cycles. However, in the Node.js voluntary work model, code ownership also comes with difficulties. We could also decouple collaborators from the commit bits, encourage non-collaborators to review, and build trust. This could be a lower-barrier pathway for people to contribute.
43+
44+
### OpenTelemetry
45+
46+
[Chengzhong Wu][] presented the CNCF OpenTelemetry project.
47+
The session was prompted by a pull request from [Bryan English][] to add Node.js built-in OpenTelemetry support. OpenTelemetry is one of the most active projects in the Cloud Native Computing Foundation, right after Kubernetes. OpenTelemetry has emerged as the de-facto standard in the world of observability with three pillars: traces, metrics, and logs. The project defines a vendor-neutral API for instrumentation and an SDK with a data processing pipeline. Apart from the OpenTelemetry API and SDK, there are also efforts to define Semantic Conventions (SemConv) and the native data format OpenTelemetry Protocol (OTLP) for sending telemetry data to backends. OpenTelemetry is an open governance project and consists of contributors from both vendors and users.
48+
49+
### Observability Infrastructure
50+
51+
[Stephen Belanger][] shared thoughts and work on improving Node.js observability infrastructure. The presentation covered `using` syntax support for `AsyncLocalStorage` and a new `diagnostic_channel` API `BoundedChannel`. Furthermore, Stephen presented ideas about new Node.js built-in modules for metrics and traces respectively, and the potential to add built-in support for the OpenTelemetry OTLP data protocol, improving OpenTelemetry serialization performance.
52+
53+
### Node.js use of AI contributions
54+
55+
This session, led by [Jacob Smith][], was kicked off by the gigantic VFS pull request (though over half of it consisted of integration tests), which openly indicated that an AI-assisted coding tool had been used to compose the PR.
56+
57+
While AI makes the cost of generating code practically zero, the cost of reviewing it remains strictly linear and bound by human limits. Thoroughly reviewing a 19,000-line PR requires weeks or even months of dedicated human effort. Pushing massive AI generations onto reviewers was described by some attendees as a "denial of service" on maintainer bandwidth.
58+
59+
An outright ban on AI could be infeasible for the Node.js project to implement. Mandating the disclosure of AI tools might inadvertently force contributors to publicize their disabilities or medical needs, which challenges project inclusiveness and raises legal and ethical concerns.
60+
61+
Rather than defaulting to an outright ban on AI, the consensus leaned toward adapting open-source governance for the modern era. Strategies discussed include enforcing a process that requires lightweight design documents, RFCs, and explicit maintainer buy-in before a large PR (regardless of whether it is human-authored or not), and requiring that the human contributor submitting the code assumes full responsibility for its quality, security, and integration.
62+
63+
### Userland migrations
64+
65+
[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.
66+
67+
### Stabilization of module customization hooks and vm.Modules
68+
69+
[Joyee Cheung][] facilitated a session to discuss the [stabilization of module loader hooks and the vm Module API](https://github.com/openjs-foundation/summit/issues/482).
70+
71+
As `module.register()` is set to be [doc-deprecated for 25 and below](https://github.com/nodejs/node/pull/62395) and [runtime-deprecated for 26 and above](https://github.com/nodejs/node/pull/62401) due to [maintenance issues](https://nodejs.org/docs/latest-v25.x/api/module.html#caveats-of-asynchronous-customization-hooks), we are looking into helping the ecosystem migrate to the `module.registerHooks()` API. Ideas include providing a [userland ponyfill](https://github.com/joyeecheung/module-register-ponyfill) that re-implements most of the `module.register()` functionality using `module.registerHooks()`, and having some [userland-migration](https://github.com/nodejs/userland-migrations) automation tools to help facilitate migration.
72+
73+
Joyee also presented [a new design for the vm Module APIs](https://github.com/nodejs/node/issues/62720) that have been experimental for 9 years in order to address known issues and finally bring it to stabilization. We collected feedback on how to integrate it with WebAssembly modules to ensure it's future-proof with ongoing ESM integration proposals in standardization bodies.
74+
75+
### Libuv v2
76+
77+
[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/).
78+
79+
To address the ABI compatibility concern in Node.js, [Node-API](https://nodejs.org/api/n-api.html) can be a way out. However, [`napi_get_uv_event_loop`](https://nodejs.org/api/n-api.html#napi-get-uv-event-loop) exposes the libuv loop and is vulnerable to libuv ABI changes. Fortunately, this is limited and the only API being impacted. The documentation also warns about this potential impact.
80+
81+
### Node.js Virtual File System
82+
83+
[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.
84+
85+
Userland VFS implementations require massive monkey-patching; moving it to core provides deep integration and supports more use cases like SEA.
86+
87+
### Node.js Security - State of the Ecosystem & What's Next
88+
89+
[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.
90+
91+
## Thanks
92+
93+
Thank you to all the attendees! Special appreciation goes to [Bloomberg][] for hosting the summit and creating a welcoming space for the Node.js community.
94+
95+
A big thanks as well to Thomas Chetwin ([@tchetwin](https://bsky.app/profile/tchetwin.bsky.social)), [Chengzhong Wu][], [Matteo Collina][], [Joyee Cheung][], and the OpenJS Foundation for organizing and making this event possible.
96+
97+
The Node.js Collaboration Summit recordings are now available at [YouTube](https://www.youtube.com/playlist?list=PLfMzBWSH11xZhA93H_9ulECtLVWtSm6zy).
98+
99+
[Jacob Smith]: https://github.com/JakobJingleheimer
100+
[Rafael Gonzaga]: https://github.com/RafaelGSS
101+
[Chengzhong Wu]: https://github.com/legendecas
102+
[Joyee Cheung]: https://github.com/joyeecheung
103+
[Matteo Collina]: https://github.com/mcollina
104+
[Stephen Belanger]: https://github.com/Qard
105+
[James Snell]: https://github.com/jasnell
106+
[Santiago Gimeno]: https://github.com/santigimeno
107+
[Bryan English]: https://github.com/bengl
108+
[Marco Ippolito]: https://github.com/marco-ippolito
109+
[Bloomberg]: https://www.bloomberg.com/company/values/tech-at-bloomberg/

0 commit comments

Comments
 (0)