# Node.js Collaboration Summit, Day 1

- Agenda: https://docs.google.com/spreadsheets/d/1-4hm3OQ4HGfvOdFR-5pm9fHz6O2k-wbqpK-41fcS1Yw/edit#gid=0
- Agenda: https://docs.google.com/spreadsheets/d/1-4hmffddff3OQ4HGfvOdFR-5pm9fHz6O2k-wbqpK-41fcS1Yw/edit#gid=0
- g- Webinar link:
https://zoom.us/webinar/register/WN_l1ywqf1jTaO-ZSVnoXchGg
- Everyone who wishes to speak should join the webinar as a panelist and raise their hand via the Zoom queue. People in the room will get a physical hand-held microphone to speak.
- Ask @joyeecheung to get an invite to add you as a panelist. Or join as a regular attendee and make some noise in the [#collab-summit-london-2024 Slack channel](https://openjs-foundation.slack.com/archives/C06S8MG9DU6) to get promoted.
- More info: https://github.com/openjs-foundation/summit/issues/387

### 9:30-10:30 Node.js Web Server Framework Session

- Issue: https://github.com/openjs-foundation/summit/issues/402
- Facilitator: @sheplu

@sheplu gives an introduction of the session.

- Marco: we have ... but no counterparts for the HTTP server. We have 3 HTTP stacks (1, 2, Quic)
- Marco: started iterating on the next gen HTTP stack: https://github.com/nodejs/http-next
- If you are interested in HTTP please join the Web server framework WG
- The current TCP socket API is very low level and difficult to debug etc.
- Trying to rewrite the class. Implementing more in JS to remove complexity from the C++ layer. Also llhttp has become a bit difficult to debug now.
- Matteo: despite all being called HTTP, the 3 stacks are drastically different. The issue is that we have no abstraction on top of all of them. I think that needs to be worked on.
- Matteo: Socket is not the right abstraction. The underlying implementation should be sheilded, the monkey-patching has been difficult for us. We needs a different abstraction than the Socket.
- Matteo: 1 and 2 are built on top of the concept of the socket. There are no concept of socket in h3.
- Matteo: Quic's streamed-based. There are fake streams that do buffering even if it's not needed. We should allow a flow that returns a value/promise, instead of taking a callback. It should also help perf.
- Marco: Perf is important and we should avoid the back and forth
- Marco: ship it as an addon
- Wes: we could have both lower-level API for perf and higher level API, like what Undici offers
- Paolo: We can start from the high-level API and then work on the lower-level implementations that branch into different stacks
- Paolo: for the most performant case we can start with something without streams but with a compatibility layer for streams
- Marco: I think we made a mistake in the past to expose the very low level APIs. We should just expose something that can be plugged into the Web Streams
- Wes: is there use case where users takes a HTTP1 request but they can't use the HTTP3 features
- Paolo: AFAICS we should not expose anything protocol-specific in the high level API.
- Paolo: most of the times users should not worry about which protocol the request is coming in with
- Paolo: going to show the latest version of milo
- Paolo: it's built on top of a buffer that can be accessed by both C++ and JS. The current implementation does a lot of back and forth between C++ and JS.
- Matteo: don't forget about async hooks
- Paolo: llhttp keeps invoking a callback
- Stephen (in the chat): I also wrote a prototype of FetchEvent awhile back. Happy to revive that as a high-level API on top of something more optimal for the lower-level part. It currently layers over the existing IncomingMessage and ServerResponse types. (PR: https://github.com/nodejs/node/pull/49405)
- Paolo: what's nice about this setup is that the JS layer only reads integers
- Paolo: planning to bring it to core as an experimental layer as what we did with llhttp years ago
- Paolo: planning to remove the C++ http parser completely
- Marco: going to show a prototype (started showing a demo)
- Marco: server.listen callback returns a Response object
- Paolo: milo doesn't know anything about the buffer.
- Wes: The new thing looks great. What do you think the next step is. The right API doc? Tests?
- Paolo: we should start with the APIs. And we can split the work.
- Matteo: difficult to reproduce with ??. Building with WASM is very difficult. Too much dependencies.
- Matteo: it's likely faster than the C++ back and forth we have in core
- Matteo: we can save the overhead from the async hooks integration
- Matteo: using Uint8Array should be faster. It's just a feeling with no numbers yet
- Paolo: WASM version uses SIMD everywhere
- Matteo: One suggestion: I would not take a listen callback. Either take it in the constructor or as a setter.
- Matteo: If possible, add request injection
- Matteo: for fastify that's one of the best idea we have. Express does it with monkey patching. It should be a built-in feature. We need it for testing.
- Paolo: (didn't capture that)
- Qard: Could take the handler function when constructing and then allow listen to be called mulitple times to let the same hanlder bind to multiple ports and protocols.
- Wes: How would that work with different protocols? Do we have some code with that?
- Paolo:

---

**10:30-10:45 Coffee break**

---

### 10:45-11:15 Future of HTTP Client

- Issue: https://github.com/openjs-foundation/summit/issues/393
- Facilitator: @ronag @mcollina

- Matteo: We shipped `fetch` in Node.js, stable since 2023. Part of the decision that was made was to split it from `node:http`/`node:https`, which is close to "unmaintainable", because any change could potentially break Express. At some point, fixing bugs would create more breakage, so it's just not worth it.
- Matteo: Undici API keep low-level and high-level APIs separated to avoid repeating `node:http` situation.
- Matteo: Undici has a more extensive test suite than node core
- Matteo: What do we want to do?
- Matteo: in order to configure fetch, I need to patch undici. there is a global dispatcher that is a symbol property of globalThis. People need to customize it in very convoluted ways.
- Matteo: Anyone aware of the proxy problem?
- Jacob: which one?
- Matteo: Normally people use an env var. Previously npm team implemented the `HTTP_PROXY` env variable for npm to pick it up with an agent.
- Matteo: Undici is implementing the env var for the undici.
- Matteo: question: should we expose the proxy env var support to the users?
- Matteo: there's no standard. Libraries implement it in their own ways.
- Matteo: Showing slides for undici.
- Matteo: we have a built-in mocker.
- Matteo: question: should we expose the set global dispatcher function to users from Node.js
- Jacob:
- Wes: Is Undici leaking the APIs stright into Node.js? Why don't we ship all the APIs?
- Robert: I am a bit against it because then we can't change things. Semver is difficult to manage. Issues with composibility. I have a side project call next-undici. Exposing Req/Res/Pipeline is okay. Others less so. We should only expose the useful parts.
- Matteo: seconding Robert. There's no clear cut answer.
- Matteo: users keep asking for ways to change settings, that's why we invented the global dispatcher.
- Wes: is the difficulty of changing things the only concern about exposing everything
- Robert: AFAI am concerned, yes. The ecosystem depends on how http works historically.
- Paolo: Consider that in the future the Web Server Framework might also choose to implement a client and this makes the situation more complex. Anyway we could mark as experimental. Whatever `experimental` means nowadays. Finally, we could expose a public API that is consider `stable` (in a loose way), then have a semi-public API and then a fully private API.
- Marco: can we expose `node:undici` behind the flag to expose low level stuff. And gradually moving the http stuff to that module.
- Matteo: impossible, if you break `http.request` you break half of npm
- Matteo: we are thinking about deprecating `http.request`
- Robert: maybe removing the documentation
- Raz: If we deprecate http.request then semver major of undici needs to be coupled with our semver major. Why not just expose it if we already will have that problem
- Robert: we are trying to minimize the breakage. Currently experimenting with hooks
- Darcy: is it possible to make it compatible with other runtimes if we are trying to make it a long-term thing?
- Matteo: Deno currently does not support connecting to a UNIX socket. So currently you need to just use undici on Deno. I'm impressed with the flexibility with their API.
- Matteo: why do we need to expose a dispatcher API that sits beneath fetch
- Dan: how does undici in Deno work on top of this?
- Matteo: they implement the node API. It just works on top of that layer.
- Qard: I could see this being valuable in other environments. The browser has ServiceWorker which does something similar. Could we make a more universal standard for this?
- Robert: it would be difficult to get it to a point that supports that. At the moment we are focusing on fetch and trying to get it out soon. There's still the option of leaving it outside to make the semver independent from node
- Darcy: That's a very good point, not all Node.js apps need a HTTP client.
- Jacob: feels like we should something else, otherwise users a keep going to use the deprecated one.
- Wes: we need to have some kind of layer for libraries to make things work in both the browser and on node.
- Ruben: don't think removing doc is actually possible. But we can strongly recommend using the new API first.
- Paolo: Maybe we can ship it as `@nodejs/undici`, this signals that it's something officially supported, but it's decoupled with our semver.
- Wes: I think we are going to end up with the same problem no matter what and this may be confusing to the users. Maybe we need to bite the bullet and say that this is just what it takes for the user experience.
- Robert: Maybe a compromise can be that we ship something like 95% in core and for the 5% power use case we direct people to the package.
- Paolo: Bold sentence here. We can't always make our users happy. Sometimes we have to unplease them for the greater good. Moreover, we can't lose our mental health just to keep them happy.
- Ruben: How should we document this well?
- Jacob: We should have a Learn article about this
- Matteo: we have no doc on fetch, we just direct people to ~the standard~ MDN. We'll need help on the docs.
- Ruben: the doc are like 10 years old and difficult for beginners. Our docs is not the first hit in Google.
- Ruy: API docs can be intimidating to beginners
- Ruy: That API to customize fetch calls using `undici` shown by Matteo earlier should really be in our docs today
- Marco: it's important to start documenting the differences between undici and the standard
- Matteo: FinalizationRegistry is finally fixed in Node.js and we can use it now. Currently in the browser you can start a request but don't consume it or clean it up. Undici tries to use FR to clean it up when the request gets GC'ed.
- Robert: Another solution would be to have a core API that lets user-land modules manage memory, and then Undici would not need to be in core.
- Joyee: Has a session tomorrow on native memeory management which could be relavent for more reliable cleanup upon garbage collection
- Paolo: In the browsers anyway they probably do fetch-and-forget when unloading the page. Anyway most likely the browser are in a better situation as when the user changes the page they can just kill the entire JavaScript VM without properly cleaning up resources.
- Matteo: Should we expose the proxy env var parsing in 22?
- Ruben: who can decide?
- Matteo: doesn't need to be stable, just a question about whether we should do it.
- Ruy: do we want a rebranding of undici? People using that API 10 years from now might find the naming confusing.

### 11:15-12:15 Node.js Undici - planning for the next major

- Issue: https://github.com/openjs-foundation/summit/issues/391
- Facilitator: @ronag @mcollina

---

- Robert: love to have some help about how the API should look.
- Robert: started domonstrating the new API for dispatch
- Paolo: have you considered a class-oriented approach
- Matteo: the agent needs to know about the pool but these do not.
- Robert: there would be a lot of boilerplate.
- Darcy:
- Marco: do you plan to expose it to globalThis
- Robert: it's already exposed as a global symbol property. Just not documented very well. It's currently unable to customize it on a per-request basis.
- Paolo: maybe put the symbol property on the requests?
- Robert: it's possible. but can be a bit weird
- Paolo: if e.g. the user is trying to customize retry, it should be via a function
- Wes: can we just just bake it into the default agent?
- Matteo: in some cases (depending on flags) it already applies automatically. I'd say 50% of the people want it.
- Jean: do we have get global?
- Many: yes
- Paolo: can the configured dispatcher be changed? Oh I see that it can be composed on top of the existing dispatcher. Can we decompose?
- Ruben: Being able to decompose would be great, we should also have it for other APIs. Also most people don't read the doc and just read e.g. stack overflow. We need to document it better.
- Matteo: the set and get dispatcher thing is the API style we have for undici and fetch. The biggest demand is proxy agent support.

....

- Matteo: question: we have multiple version of the dispatcher API. How are we supposed to manage this?
- Matteo: trying to add it to the spec.

----

**12:15-13:45 Lunch break**

---

### 13:45-15:00 Node.js Tooling Group meeting

- Issue: https://github.com/openjs-foundation/summit/issues/390
- Facilitator: @ruyadorno

---

- Ruy: Intro to the Tooling Group & a bit of history on how it started
- File system recursive APIs, Argument Parser & source maps are some good examples of features that were discussed in this group
- Tobias: single-command http server like the one that python has. We should think about our subcommand strategy
- Matteo: I am one of the people objecting to this PR because I think if we are landing a static file server we should land something that conforms to the http standard and it should be performant. And TBH node.js is pretty slow at serving files today. We should provide something similar to the ? module of express.
- Robert: I had a send file API.
- Matteo: That was what I was saying, we need a lower level API that does all the MIME types etc. right.
- Robert: does libuv implement sendFile Linux API?
- Richard: no
- Tobias: we should mention in the doc that this command not for production, just for testing and for people who don't want to install something from npm to just do this
- Ruy: Just from the web dev experience point of view it's valuable to have a minimal, developer-oriented, not production ready, not-peformant API that's baked into the runtime that we can use
- Qard: send file does exist in libuv
- Jacob: during web developemt a lot of the times the browser really need you to serve this file from a server (instead of file:://?) and I think this would help a lot of people
- Yagiz: is there a champion to pursue this
- Ruy pointed to Antoine
- Yagiz starts an intro of the `node run` v.s. `node --run` debate
- PR of implementing `node run`: https://github.com/nodejs/node/pull/52190
- Tried a PR to reserve the `node run` but there are blocks: https://github.com/nodejs/node/pull/52267
- Yagiz: I think --run is bad for UX
- Rafael: I don't think we'll be able to find a good solution until we release 22
- Yagiz: reserve any extension-less positional argument as a subcommand, also compatible with ESM resolution
- Tobias: it would break `run/index.js` or `test/index.js` for the case of a `node test` sub-command
- Richard: we should go through a deprecation cycle
- Matteo: I would be better to ship it as `node --run` because it's backportable, especially 20, there will be shorter adoption cycle. In parallel we can deprecate `node run` on 22.
- Yagiz: I am okay with a deprecation cycle if folks think it would work better
- Ruben: I don't believe that we should just break people. Is there a downside on keeping both?
- Darcy: previously there were concerns about not documenting this very well
- Joyee: reading the Deno doc recently and noticed that we don't have a page for tutorial of command line interface. We should have a TL;DR page for begineers, instead of only having an alphabetically sorted page. Not volunterring just putting the idea out there.
- Wes: We can just document that `node run` doesn't do all the package manager does. And make it explicit that it's intentional. I am now leaning more towards the flag than the subcommand. People do run `node test` which is `$cwd/test.js`. I think that's a pretty cool feature and adding subcommands would break that workflow. I think it's enough to justify a flag.
- Yagiz: the limitation is already documented in the PR. Geoffrey insisted and we added it.
- Ruy: what don't we support right now?
- Yagiz: I want to move it to C++ eventually so am not trying too hard in the current JS-based implementation. Like recursive bin directory support (?)
- Darcy: ?
- Wes:
- Yagiz: it's a slippery slope to document "what we don't support but npm supports" because whenever npm adds something we'd need to update our docs
- Ruy: Using `--run` also sets an expectation to users that this is a different implementation from `npm run`
- Micheal: we should just be explicit about a specific list of things we support and not going to support everything
- Luke: we (npm) can contribute to the documentation. It's been very difficult to document the entire surface. It would be helpful for the contributors to know if they don't need something they can use the built-in command.
- Ruy: any more concerns
- Wes: I think we need to think through about the consequences of having the whole .bin on your PATH
- Micheal: I think it's good to not have the package manager to run the scripts. Not sure if I am thinking about the same use case that you brought up
- Wes: I think anyone using npm start in producion is wrong. And `node [--]run` should be the right way to do it. We should figure out how to pave the way for people to do it right. I am thinking more about using it for developent time.
- Micheal: do we have a common understanding about what the target of this command is?
- Matteo: I have projects that say spawn 5 commands in one scripts and I think being able to save 1 sec (5\*200ms) would be quite valuable. We really need to document this though. Especially how we increase the V8 space limits. Also our doc by default tells people to do npm start. We should change that.
- Darcy: sounds like there's consensus here that npm should run faster. It would be cool if we can contribute back to the existing tool for it to be more performant.
- Luke: there is an interesting to be discussed about shared primitives. Things like walking through the directory tree to find package.json. It would be great if Node.js can provide performant primitives for this.
- Joyee: someone in the node run PR posted a HackerNews thread where someone analyzed why npm run is slow and AFAICT most of that is tied to how npm run works. Also someone from npm mentioned in the thread that npm needs to be able to install on top of itself so they can't do lazy loading. I think most of the slownees is application logic and not too much that Node.js can help with.
- Wes: It's only fast when the command itself is fast. If the command is already very slow then 200ms speedup is not very significant. And in real world people tend to run very slow commands.
- Wes: about `npm` not being able to bundle itself, maybe one possible thing is to avoid doing a global install of `npm`. I think that may be pretty promising to help them speed it up.
- Matteo: For me it can save me 1 sec so I think it's meaningful.
- Matteo: people should just not install `npm` globally because the permission is difficult. This includes our own installer.
- Ruy: there's one last comment from Tierney in the PR. What it's supposed to be? It should be a subset, different from npm. I think the scope is better defined now.
- Vinicius (from the chat): it's a bad idea to ship another binary to handle the subcommands? like we have npx or corepack?
- Tobias: I think that is just a terrible idea. Just do that as node2.
- Ruy: Conclusion, hopefully a lot of progress was made to the current `node --run` implementation ([ref](https://github.com/nodejs/node/pull/52190)). This group is a great place to collaborate on issues like this and hopefully we can get back on having regular calls in the future.

### 15:00-17:00 Node.js PMWG & Version Management Working Session

- Issue: https://github.com/openjs-foundation/summit/issues/400
- Facilitator: @wesleytodd @aduh95 @ruyadorno
- We'll have a 10-minute in-session break at 16:00

---

- Wes: Set goals for the human aspect of this conversation, start with a recap, current state of Corepack, then brainstorm the goals for the project in this space.
- Wes asked Darcy to give a recap of the binary management summit in early 2020.
- Darcy: Day long discussion lead by James Snell that concluded with the goal of continue exploring that domain.
- Antoine: I'll explain how corepack into node. Conversation started long ago when there was issue requesting other package managers to be added to node.
- Antoine: When Yarn released a new manager release the project need a way to define what version of the package manager to use to a given project. Mael the Yarn dev lead worked on that first implementation of Corepack.
- Antoine: The conversation of adding other package managers stalled and eventually landing Corepack was a compromise to satisfy Yarn.
- Wes: There's also a Collab Space in the OpenJS Foundation to explore `package.json` interoperability.
- Wes: Let's start a brainstorm session on what we can and should be solving in that binary management space.
- Matteo: Status quo is that there are real users using Corepack today. There are issues on projects recommending experimental features (Corepack in this case) as their preferred installation methods that we need to be aware and it's relevant to the discussion.
- Darcy: We need to define the personas, clearly Yarn and Pnpm have been relying on this so there's a clear need for this feature.
- Robert: What part of Corepack are people using? Pinning versions? Installing package managers? What features do we want or not want to break?
- Matteo: They're using the jumper binaries and pinning versions & then `pnpm start` to start their projects.
- Matteo: Recently `pnpm` shipped a feature that broken the usage of Corepack pinning (?)
- Wes: One of the top goals should be generic reproducible builds. Management of the node binary is absolutely part of that. Maybe python version & package managers version management.
- Luke: When `npm` fixes an issue today it takes 3-4 weeks for that fix to land in node. It would be nice to also fix that.
- Wes: How far we should be going in offering that kind of support?
- Darcy: What is the difference between the package manager and any other dependency? Pinning a package manager version is great but there are also side effects to that such as missing patch fixes that you get when your depedency is pinned to a semver range instead.
- Darcy: We need to keep in mind that we don't want to make it harder to manage our dependencies.
- Wes: Should helping `npm` ship faster fixes be part of the scope?
- Wes: There's no path in the current Corepack design to manage the version for the node binary. One of the goals for reproducible builds is managing that.
- Darcy: The current scope for Corepack is not well defined. You could theoretically add any other tooling, e.g: `eslint` to Corepack and have that be the way to distribute that package. The scope gets big when you don't define a criteria for what gets added.
- Darcy: Then there's also discussions around licensing such as is the case with `npm` at the moment.
- Ruben: I think it's part of the TSC's reponsibility to decide whether it's a feature that Node.js should have
- Micheal: What is the future for node, do we want to be responsible for that tool that ships your package managers and manages the versions of your binary. Having an agreement on that high-level first.
- Antoine: Corepack is not a good candidate for managing the node runtime since it's a JavaScript app that is run with the runtime.
- Darcy: `nvm` is the recommended way to manage node versions today.
- Wes: Does the version manager needs to support all the platforms? `nvm` does not do that today.
- Richard: They're not exactly recommendations but rather things that people contributed via PRs to the node website.
- Richard: The release team currently controls the assets for every newe promoted release but have no control over any version manager. Are we comfortable with recommending a solution to get that runtime that we ultimately don't control?
- Wes: This is a reason why we need to
- Wes: The goal is not to necessarily recommend `nvm` and rather solve the problem of managing different node versions, package manager versions for a given user project.
- Ruben: There's consensus in the room that we want reproducible builds.
- Ruben: Don't care about a specific tool but rather how to provide users a way to easily manage and access this things and it needs to come from node.
- Ruben: It's fine if we take baby steps improving Corepack.
- Michael: Explore a different model in which we rely on third parties to manage these tools and the node binary.
- Wes: Disagrees with that model since it has led to ecosystems in which there are very old and unsupported versions of node being distributed and used by end users.
- Michael: Not necessarily relying on the existing OS package managers but rather a different tool to manage node versions.
- Michael: The installers could have options to add other things at installation time.
- Wes: Then we would be responsible for shipping this tool?
- Michael: Yes.
- Wes: node doesn't update itself then. The goal is to have something outside the node binary that manages these artifacts.
- Ruben: If we want this tool to manage node it could also potentially be built into node.
- Darcy: It goes back into creating a package management ecosystem.
- Darcy: There are two different tools, one that distributes the node binary and other that manages the tools in a node-based project. What is the goal we're trying to solve? Defining that scope is also concerning.
- Matteo: We might have to also manage Python, seen numerous times builds are broken due to issues with the python binary version. The default version of Python on macos now doesn't work with node-gyp. Python is also a dependency from the point of view of reproducible builds.
- Luke: Different versions of node-gyp will change where it will look for the Python binary.
- Wes: Not sure we can ask users, specially newbies to define a Python version.
- Wes: Let's try to build consensus.
- Darcy: We still need to define the personas. Who is this tool for?
- Darcy: How do we cater to beginner developers to manage their environments for them.
- Richard: Developer experience is a lot different depending on the platform. MacOS works in a way, Windows is significantly different from that, etc. Depending on what platform you're on you get a different experience.
- Wes: Having a consistent cross-platform experience should also be a goal. Meeting users where they are.
- Wes: Recap:
- Goal: Reproducible builds are important, we should provide tooling for it
- Goal: Consistency across platforms in the user experience is important
- Goal: We can ship some level of tooling that the Node.js project owns (?)
- Antoine: Corepack is currently serving a different end user profile, e.g. when there are no native addons can already get reprudicible builds with the current Corepack because they don't have to care about Python or specific Node.js version.
- Darcy: Thinks that this don't necessarily needs to be a focus of the Node.js project that can focus on the runtimes need instead.
- Michael: Should focus on the bootstrap phase.
- Robert: Removing Corepack today will only break Yarn and pnpm users.
- Geoffrey: Don't want to do any further of political winner-picking like what happened with `npm` in the past.
- Wes: What if that is framed as a trade off? Improving user experience at the cost of picking winners. Picking winners is a good thing.
- Ruben: Agree that we pick winners all the time like deciding any dependency to the node runtime. It's not just npm.
- Geoffrey: From the exception of `v8` and `npm` most other dependencies are hidden API from users that we could potentially replace at any time.
- Richard: node exposes headers for v8, libuv, there are more API surface that might be exposed to end users that might seem internal only.
- Geoffrey: npm is currently the only tool that is not a direct dependency that we expose to the public.
- Geoffrey: We could use the downloads page in the website to recommend a potential alternative solution to the problem of managing the node binary & package managers versions.
- Wes: That is not a consensus.
- Stephen: We do depend on npm on a way such as installing our own internal dependencies. It's not a clear cut case. Developer experience is valuable.
- Ruben: Defining an opinionated user experience is important to the project.
- Michael: We need to figure out what is important for us to do.
- Michael: Everytime we bundle an extra tool we increase the surface area and incur on more maintenance in the future.
- Wes: Developer experience is #1 priority in the documented list of project priorities.
- Michael: Tradeoff, some places might need more opinionated solutions than others.
- Darcy: It becomes impossible to reproduce the same experiences in different platforms.
- Antoine: Users choses different tooling because they want a different experience.
- Wes: There's a way to have both an opinionated and an more flexible solution to these problems.
- Geoffrey: More of a design problem potentially solved via different set of instructions in the website for different user profiles / needs.
- Wes: That does not solves the problem at a end-user project level.
- Geoffrey: It could be documentation that instructs the user to use `nvm` to manage the node binary version, `corepack` to manage the package manager version.
- Wes: Disagrees that that is a good end user experience. I think curl -S something and then you have what you need in the project is a lot better.
- Antoine: If we end up with something that provides a worse DX as Corepack, it's fair to say we fail our goal.
- Geoffrey: coreback could be one of the options, guide users on how to set up these tools.
- Luke: Agrees that having one tool that manage these versions reduces the maintenance burden for npm.
- Wes: We haven't passed the goal-setting step yet.
- Wes: Proposed single download path for end users.
- Ruben: We have to look at it from the point of view of how we improve the experience for Yarn & pnpm users. If we improve the DX of 5% of the users, I would take it as a win.
- Michael: We all agree on user improvements, the tradeoff is whether we need to accept the cost of maintaining an entire toolchain to improve the user experience for that 5% of users.
- Wes: That tradeoff discussion depends on where the value is. Maybe not enough at the moment in Corepack to justify its maintenance costs at its current state.
- Wes: The Node.js project should not be concerned with picking winners and rather on the result to end users.
- Geoffrey: If we want to provide a solution to different package managers maybe different approchs can satisy that requirement such as `curl` a different package manager alternative at install time.
- Geoffrey: Happy to see progress on the `devEngines` proposal, maybe it's something that the node runtime itself could read from. Might be best of both worlds.
- Darcy: The node runtime itself could be distributed in the npm registry. The node binary version is a dependency of your project similar to your other package dependencies.
- Geoffrey:
- Ruben: Want to see agreement on making improvements to end users.
- Luke: Can we decide specifically what problems we are trying to solve for end users? For example devEngines spec will error for the wrong node/npm vrsion. Should a new tool do that or as a very specific example also pick the correct version when changing to a new directory?
- Wes: Can we agree to getting a group together to ship something that solves these problems? Concretely:
- Goal: The Node.js project will recommend an installation method that provides the `node` runtime via version management, and allows the user to choose what package manager, if any, is installed alongside `node`.
- Goal: As a user, I want to install Node.js with my choice of what package manager (if any) accompanies `node` upon installation.
- Goal: As a user, I want a way to install Node.js controlled via a version manager; with or without a package manager included, with or without the package manager controlled via a version manager.
- (Doesn't look like we have consensus, FTR)
- Wes: can we agree at least that we'll charter the pakcage manintanance group to continue discussing this?
- Antoine: should we at least set a deadline for the group to come to a conclusion? There is also the risk of this stalling forever.
- Geoffrey: there shouldn't be a deadline for consensus. If we don't have consens we just don't ship anything.
- Ruben: I feel like we'll always have someone who doesn't agree
- Wes: we should delgate this to the PMWG meeting next week. And put them into proposal docs. And PR that into node. My proposal for the next step would be to do it within the group.
- Ruben: do we have agreement about removing that scope from corepack?
- Wes: we are running out of time
- Geoffrey: can we agree about the goals at least
- Ruben: I don't think so(?)
- Wes: that's why I think we should move it into the group. We can bikeshed about the goals in the group. We'll have more time.
- Wes: at least we can agree that we are not ending the conversations?
- Wes: any better ideas?
- Robert: Assumes there is still people with energy to follow up with this initiative.
- Joyee: quick note that was what we did with ESM. It has upsides and downsides. Be aware of the downsides and try to avoid that.
- Wes: so we are taking it to PMWG? Do we agree?
- Darcy: Spent many years contributing to that WG already but probably will not follow up at this point in time.
- Robert: There are discomfort with just accepting whatever the WG comes up with.
- Wes: we can continue iterate on the goals in the pakcage maintainance working group
- Geoffrey: we need a goals proposal
- Wes: yes. Not pulled into node core though.
- Wes: First define a set of goals that everybody can agree with and then the WG can be tasked on executing on these goals.
- Wes: we can take the short term strategy discussion to the PMWG
- Geoffrey: at the mean time if the short term strategy gets stalled, corepack shouldn't be there forever, if it's not the eventual solution there's harm in letting it linger because more people will depend on it and we will break more people when we remove it
- Wes: We will deal with it in the next WG meeting and come back with a strategy within a few weeks
- Wes: does anyone have objections?
- (No in the room or in the call)
- Wes: Action Items:
- Define short term stategy
- Define goals doc that can get approval from the TSC.
- Geoffrey: if we can't get the goals doc done this can drag forever and corepack will continue get depended.
- Wes: We'll pause the corepack discussion until we get a goals doc. Agree?
- (looks like we have consensus?)