Discussion ideas

• X - James - official position on WinterCG
• James - Sockets
• Asks from project to OpenJSFoundation
• Bryan - might be interesting to have official of what it means to be Node.js compatible
• Paolo - follow on after sockets might be similar for HTTP
• X James - Webstreams implementation, had followed spec initially, which you have to do if it is going to * JavaScript, but that it not required when going to native code
  • Would be great to get onto list of technical priorities
  • Rafael - talking to Yagiz, he plans to do that with Danielle, there are issues with perf in complying to spec completely
  • James not sure if re-writing all in C++ makes sense versus part.
  • Paolo, moving to more or less C++. James is that we have to figure out.
    Rafael - discuss the vision of the project with respect to SemVer majors
  • Workers compatibility flags and dates
  • Alexander - Python from future, works pretty well.
  • Rafael - would affect release approach
• Michael - Experimental and vulnerabilities
• Bryan can share some info on Version usage

Release schedule

jasnell: current release plan was devised long time ago, need a revamp
mhdawson: sometimes people ask for even longer support span
bengl shows version data collected
jasnell: not surprising given the interview results we got when devising the support plan
jasnell: are we overestimating the risk of breaking the ecosystem - they are just not going to upgrade if they are broken
pablo: maybe we should be aggressive in odd releases (?)
rafaelgss shows https://github.com/RafaelGSS/nodejs-stats/tree/main/downloads
mhdawson: some people do use current as stable
qard: customers I've talked to, some just jump e.g. 6 versions which are that different from each other
bengl: we don't specify odd releases as supported so the data is skewed towards even realeases
pablo: in my experience the odd number relases are almost useless
jasnell: maybe they should be preview/release candidates
tobias: if we break major we should revert asap (e.g. ipv4 family select, breaking people for months)
pablo: we need data and feedback about repro for the breakage though
matteo: if we break once a year we'd be encouraging authors to ship things behind flags
qard: we already have experimental status, we should use that and flags more to bake things before making them stable
alex(?): at Bloomberg we never use the LTS(?), I think we and companies like us would be very happy to participate in a program to test breakage
jasnell: maybe we can use the canary tag for the current release and update every weak. Once the current is mature after maybe a few months we promote it to stable - once a year. And then several years of support. a lot of questions we need to answer for that but that's an alternative
rafaelgss: how do we guarantee that people are going to use that
jasnell: security releases
matteo: that would not work for security releases
pablo: there would not be any overlapping stable releases
jasnell: if we land a security fix on the tip of tree, whoever need to get the fix on a stable need to account for all the breakages landed in between, we would need to figure out the earliest patch on main that introduced the security vulnerabilty and do the fix on top of that
rafaelgss: there could be rebase conflicts
pablo: we'll just do multiple fixes for multiple channels
targos: how would it work for library authors
jasnell: we need to figure out
targos: we may need to have some kind of version number for every stable release
jasnell: this would actually allow us to follow semver properly
pablo: codemods or linting rules to aid migration
jasnell: we need a better way for deprecations, e.g. IDE integration
joyee: out of band deprecation warnings with IDE/linters help users get deprecations without upgrades esp. if they jump versions
Michael: Like the earlier idea of linter rules to flag deprecations
pablo: I think we should set a date for the deprecations for IDEs to communicate
jasnell: something like what the definitely typed does, annotate the deprecated things
alex: we can have something like npm audit for dependencies

…compatibility discussions…

matteo: we are ignoring elephant in the room. reality is vast majority of npm touches internal properties or monkey patches stuff e.g. express
jasnell: we have a warning about this for long enough. we should just let it go
alex: maybe we should do this gruadually
pablo: talked to someone before. they asked if you can give me some official document about express not being supported any more so that I can tell my boss to ask for resources to migrate
qard: a lot of companies have a slow developemnt cycle
pablo: how much do we care about these companies
jean: many of the non-tech companies. Think COBOL and banks
igor: aren't they already on old versions anyway
tobias: some are not holding us back e.g. buffer constructor. some do, like internal properties of streams. often we ask people about their use cases to provide public alternatives
alex: it would be very valuable to have gradual changes
mhdawson: I think there's a line in breakage - if we cross it people are just not going use it any more
joyee: in many cases we are just afraid of breaking unknown amount of npm modules. combined with a canary scheme we can encourage library authors to test it in the CI, break more liberally in canary, collect data and evaluate breakage, and revert if necessary, and find and invent appropriate alternatives
pablo: or we just create new modules instead of touching old modules
marco: how about just land breaking changes on odd releases
jasnell: the intent was already that odd versions are for library authors
?: how about deprecating by putting things behind flags
jasnell: cut in april, as preview for libary authors, promote in October

• Action item
  • Need group that will make proposal for changes
  • Rafael volunteered and will pull in releasers before sharing the proposal

Webstreams implemention

• James
  • not written with perf in mind, quite slow
  • Some memory issues due to spec
  • When data comes from something internal we could have a more efficient
    implementation. It requires having two models, the one for JavaScript which
    is necessary when data comes from JavaScript and a second model that handles
    sources which are internal.
  • Don't have time to implement, but would be good to do.
  • Would be nice to have it be a mini strategic initiative
• Rafael, what would this affect
  • James this should not affect any externally visible behaviour
• James
  • There are some complexities such as the order of the reads
  • So some timing nuances that we would have to handle carefully
  • Promises is another area that might add some complications
  • In worker d, 1 interface, under that have two implementations under that
    which implement the common interface (JavaScript and Native)
  • More complicated on pipe, when you pipe from one implementation to the other
  • JavaScript implementation could likely also be optimized, but would need to
    be done carefully as it could affect the observable behaviour
  • One of the benefits is that piping between two native implementations could
    optimize and avoid going to JavaScript at all.
• Rafael
  • from past investigation on Fetch

WinterCG

• plan is to make the minimum common API a stadard
• want to then have a compliance suite, to validate compliance
• Michael, good to have proposal for what the project should commit to
  • Project goal to implement all minimum APIs
  • Just lend the Node.js logo to support the effort
  • Or whatever?
• littledan: hope is when we go beyond minimum common API, we can be more ambitious and add new things and include Node.js in the govenance model. If Node.js is not in WinterCG, it would be weird to have this governance discussions.
• mhdawson: problem is no one can speak for the project, we operate on lazy consensus
• joyee: we can start by lazy consensus among collaborators in the core issue tracker about proposals
• jasnell: plan is, open an issue in the node.js issue tracker about adding logo to the website, see if any collaborator has objections, if no, do it, if yes, escalate to TSC
• littledan: OpenJS standards team for TC39 and before the pandemic, had some success with travel funds, did not really help with standards positions, need to solve the same thing for WinterCG
• mhdawson: we can have a team and a repo
• joyee: or a strategic initiative
• littledan: discussions (TC39) tend to be async online, via e.g. Matrix and Issues - individuals may be able to attend sync meetings via OpenJS membership or as invited experts
• littledan: even if no one from the TSC can speak for the project, still valuable to have opinions from TSC members to gauge how this is going to be perceived within Node.js
• marco: maybe start with a strategic initiative, and have a champion
• jasnell: put me down as a champion
• littledan: is scope WinterCG or standards in general
• jasnell: start with WinterCG
• mhdawson: let's talk to legendecas too, he's been pretty active in WinterCG
• littledan: Firefox has a repo called "standards positions" - might be useful for Node as a project to have something similar
• marco: would be interested to talk with OpenJS foundation
• littledan: we tried, it's a bit too high level, not expressing clear positions that are needed
• jasnell: for something brand new like socket, our intent is not to make it a standard but to incubate it in the WinterCG and get feedback, once that stablizes make that a standard, currently considering Ecma as such a standards body. For Node.js there's no obligation to implementation, just hope that Node.js can participate and give feedback
• littledan: we need to figure out what "WinterCG Compliant" means exactly, minimum common API, or …
• jasnell: will start an issue about the logo
• mhdawson: analogy, OpenJS brings projects together, top-level projects elect voting member. WinterCG could come to Node and ask if someone wants to elect someone to the voting position
• littledan: come to me if anyone is interested in such a role for TC39
• jasnell: TC39 has always considered the perspective of Node, we just haven't leant in with the consensus of the project
• joyee: when someone tries to speak on behalf of Node, they aren't currently opening an issue to see if the opinion reflects that of Node. That today would be a pre-req for such a position
• mhdawson: easy to show up as an individual and have an opinion, but showing up with consensus achieved ahead of time requires a lot of pre-work
• jasnell: standards-position repo makes a lot of sense, don't wait for TC39 to ask
• mhdawson: we need a process for how things will be added
• jasnell: i'll take the first stab at writing that process
• joyee: need to find a way to communicate this with the collaborator base to avoid surprises. Need a channel e.g. Slack to advertise things
• mhdawson: hence needing a written-down procedure, so that we can point to the procedure and ensure it is satisfactory
• jasnell: will open the logo (nodejs/node) and standards position repo (nodejs/admin) issues next week

node:net

jasnell: revamp net completely. net, tls, udp, big mess. similar to what we did to URL, leave the old stuff alone, start from the ground up and create a set of modern APIs, readablestream instead of node stream. It's been difficult to implement discovery in fetch.
jasnell: dont want to consider http 2, 3, … want one server, and parameterise it to enable/disable 2/3. Eliminate the complexity
mhdawson: How does it fit with undici model?
jasnell: rely on undici to provide http semantics on top
mhdawson: thought maybe we would bring undici APIs into Node
jasnell: conversation we need to have. We have fetch, a global connect. Lots of details and unanswered questions to figure out. If anybody thinks "leave what we have alone, it works" - I want to hear from you
mhdawson: think wqe agreed that we would have higher and lower level APIs - something we don't already have
marco: I thought we were missing a WG on http. Me and Paolo have always been interested in http but there was never a WG.
?: we had one called "webserver". We can bring this back
jasnell: want to kick that back off. We got busy, there was a pandemic, … QUIC has had a whole load of issues, don't want to make a public API for it (yet?) until it's done. HTTP/3 and QUIC, new http parser wont apply. Headers in HTTP/3 from QUIC will be different, undici will apply HTTP semantics on top. Not needing a parser
marco: right now undici is a client, how is it related?
jasnell: that's part of the discussion, reusing Request and Response on the server-side. We cannot keep evolving Node's APIs without doing this
paolo: we currently ship two https. When we ship Milo we may have two wasm versions
marco: we will de-duplicate. agree we need to do something, it's currently bad
jasnell: like readable stream this is going to be a huge effort. we need to get a team together dedicated to this - not the actual implementation work, but at least evaluate and create a plan
joyee: can we also avoid MakeCallback in the new stuff
jasnell: yeah maybe
jasnell: web streams not node streams
joyee: if we don't do old streams, MakeCallback would not be necessary
jasnell: plan to rebase and open another big PR for quick soon, targeting end of November, and take a few weeks off in December, and continue after that

Fin. applause