- Recording: https://www.youtube.com/watch?v=zJMGRA9F0ck
- GitHub Issue: #1446
- Antoine du Hamel @aduh95 (voting member)
- Yagiz Nizipli @anonrig (voting member)
- Benjamin Gruenbaum @benjamingr (voting member)
- Ruben Bridgewater @BridgeAR (voting member)
- Geoffrey Booth @GeoffreyBooth (voting member)
- Gireesh Punathil @gireeshpunathil (voting member)
- Joyee Cheung @joyeecheung (voting member)
- Chengzhong Wu @legendecas (voting member)
- Matteo Collina @mcollina (voting member)
- Michael Dawson @mhdawson (voting member)
- Darshan Sen @RaisinTen (voting member)
- Richard Lau @richardlau (voting member)
- Robert Nagy @ronag (voting member)
- Ruy Adorno @ruyadorno (voting member)
- Michaël Zasso @targos (voting member)
- Tobias Nießen @tniessen (voting member)
- Rich Trott @Trott (voting member)
- Matteo -> discount code for collaborators for NodeConf.eu, ping Matteo if you want the code
*Extracted from tsc-agenda labeled issues and pull requests from the nodejs org prior to the meeting.
-
Board - Matteo
- no updates
- Travel fund is out of $, trying to figure out estimate of how much more we’d like to ask for next year.
-
CPC - Rich
- nothing to add this week.
- The env var NODE_V8_COVERAGE intermittently causes the test runner to hang #49344
- If using test coverage, just hangs, combination of multiple bugs
- Matteo added to agenda for visibility, proposed that we delay LTS
- If using project with ESM, no other way to get code coverage
- Geoffrey, lots of projects don’t use code coverage, so smaller subset of people may be affected
- Antoine, we already call the release stable
- Richard, Antoine makes good point, but want to point out that it is the call
of the Release WG whether to delay.
- people makes plans around the dates so a change can cause significant fallout
- Joyee, is it clear that this would need SemVer major change to fix, otherwise don’t see reason to delay LTS, from my look I don’t think it will .
- Matteo, problem is people will start updating while it’s LTS, original Node.js broke quite a few packages on CITGM
- Michael, suggestion is that we keep LTS switch unless we know it’s bounded, and signal that it is a priority for the project to fix in the release announcement.
- Matteo as long as it’s clear, Matteo would be good with that approach.
- Joyee, messaging stable, current, -> once its out it’s already stable, LTS means we will backport fixes, but no guarantee that bug free.
- Richard, agree with Joyee’s statement, much of it is around risk management, and increasing the level of process that is in place to reduce likelihood of new issues. Agree that we could coverage through messaging as a known issue.
- Joyee, one thing that might help in the release announcement, figure out good version that you could downgrade to?
- Tobias, Is this a problem in 20.0.0 as well due to the V8 version or has someone bisected it to a later commit?
- Matteo, bisecting is hard since its a flaky issue, currently trying to reproduce and bisect.
- Richard, other way if we can reproduce on the proposal for the V8 update?
- Joyee, does this only reproduce with test runner
- Matteo reproduces with NODE_V8_COVERAGE, not related to test runner in core
- Could make NODE_V8_COVERAGE experimental again?
- Robert the change in undici, replace finalization registry with no-op, could we do that in Node.js until we have a better solution?
- Matteo - Finalization registry is not the only trigger. Can reproduce without out, but it does reduce the frquency.
- reasonable option
- Joyee - question of can we make it no-op, no because there are packages that rely on it. For example Jest has leak detector
- Matteo - Finalization registry is not the only trigger. Can reproduce without out, but it does reduce the frquency.
- Michael -> if we don’t have a good bounded timeline, consensus to document in release notes/release announcement.
- When to make
--default-type=module
the Node.js default #1445- Lots of discussion, does not seem to be going towards consensus
- Key question is do we want to make this the default at some point?
- Michael, maybe the question is if anybody objects to it regardless of adoption?
- Matteo, believe it’s inevitable
- Michael, maybe the question is if anybody objects to it regardless of adoption?
- Michael possible messaging “Flag has been added to help with adoption, with possibility that it might be made the default at some point”
- Joyee, don’t think sending a message to push people to upgrade in a short timeframe helps more than it hurts. People value that that they don’t get broken by Node.js
- Geoffrey
- don’t like the repeat that we are “breaking” people
- Joyee, it’s not one change per project as there can be many things that need to be changed
- Ruben, the small changes can easily roll up to a huge amount of work, we should not force people into that.
- Antoine, more likely that we get consensus that it will not be flipped in 22, so we should not include it in the release notes, as it does not reflect reality. Would be good to focus on what will more likely be the case.
- Joyee, still soon to say anything about the flag since it’s experimental, still not sure if its the only way we will speed up adoption, maybe we make it less breaking. Ie we don’t necessarily have to break CommonJS to support ESM by default.
- Geoffrey, have some ideas, but ideas have been proposed/rejected over time, but possibly times have changed.
-
Collaborator Changes - More Privacy #834
- Benjamin, gave overview, asks for TSC members to review/comment. If no objections by next week will PR in changes to the governance
-
Have a mascot #828
- Matteo -> any concerns with asking the OpenJS foundation to organize the process to select a mascot. Process is moving forward, waiting on OpenJS staff.
-
Create
nodejs/socket
repository for Node.js implementation of Cloudflare's Socket API #826
- Primordials - first meeting right after this TSC meeting, will follow up next time
- V8: update to 11.8 (nodejs/node#49639) almost ready, blocked on two issues:
- One test failure, SmartOS-specific. SmartOS team was notified and looked into it but no resolution yet.
- coverage-windows job on GitHub actions cannot finish because of disk space issues. No proposed solution yet.
- Node.js Project Calendar: https://nodejs.org/calendar
Click +GoogleCalendar
at the bottom right to add to your own Google calendar.