-
Notifications
You must be signed in to change notification settings - Fork 134
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc: add minutes for meeting 11 Sep 2024 (#1617)
* doc: add minutes for meeting 11 Sep 2024 Signed-off-by: Michael Dawson <[email protected]>
- Loading branch information
Showing
1 changed file
with
137 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,137 @@ | ||
| # Node.js Technical Steering Committee (TSC) Meeting 2024-09-11 | ||
|
|
||
| ## Links | ||
|
|
||
| * **Recording**: <https://www.youtube.com/watch?v=mY4hUh5SHPM> | ||
| * **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1615> | ||
|
|
||
| ## Present | ||
|
|
||
| * Antoine du Hamel @aduh95 (voting member) | ||
| * Yagiz Nizipli @anonrig (voting member) | ||
| * Gireesh Punathil @gireeshpunathil (voting member) | ||
| * James Snell @jasnell (voting member) | ||
| * Joyee Cheung @joyeecheung (voting member) | ||
| * Marco Ippolito @marco-ippolito (voting member) | ||
| * Matteo Collina @mcollina (voting member) | ||
| * Michael Dawson @mhdawson (voting member) | ||
| * Richard Lau @richardlau (voting member) | ||
| * Ruy Adorno @ruyadorno (voting member) | ||
| * Paolo Insogna @ShogunPanda (voting member) | ||
| * Guy Bedford (Guest to discuss issue on agenda) | ||
|
|
||
| ## Agenda | ||
|
|
||
| ### Announcements | ||
|
|
||
| ### Reminders | ||
|
|
||
| * Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/reconizing-contributors.md#bi-monthly-contributor-spotlight) | ||
|
|
||
| ### CPC and Board Meeting Updates | ||
|
|
||
| *Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
| * No updates | ||
|
|
||
| ### nodejs/node | ||
|
|
||
| * module: support __cjsUnwrapDefault interop flag in require(esm) [#54563](https://github.com/nodejs/node/pull/54563) | ||
| * Guy - mostly name bikeshedding issue. | ||
| * With the introduction for require ESM, working on transpilation of CJS into ESM | ||
| * Given arbitrary module you don’t know what pattern to apply. | ||
| * The idea is that adding a marker that tells the original form (ex cjs) it | ||
| helps in figuring out which pattern to apply. | ||
| * __cjsUnwrapDefault is the proposal for CJS | ||
| * Question is should we call this cjsUnwrapDefault or model.exports | ||
| * Joyee’s suggestion export as model.exports string name | ||
| * Joyee, one question is that we don’t have agreement to add label to namespace as | ||
| that might be SemVer major, if we instead add API like isCJS that could be SemVer | ||
| minor. | ||
| * Guy, use of new API like isCJS, then does not work for bundlers | ||
| * Guy: Node.js loader adding a flag is something that other tools could also follow | ||
| * Need different discussion about polluting the namespace | ||
| * Guy: Split into 2 PRs one on import and one on require, one on import is tagged as | ||
| SemVer major, the one for commonJS is marked as SemVer minor. | ||
| * Antoine: can we clarify are we talking about models written in ESM syntax ? | ||
| * Joyee: commonJS that has model.exports, now you want to upgrade to ESM, you want | ||
| to do export.default, that does not translate well. The idea is we need some sort | ||
| of flag to do the unwrapping properly. Bikeshedding how the hint should be written | ||
| By the authors. Only useful in cases where you replace module.exports | ||
| * Antoine: we mean a marker in the model, not a CLI flag right? | ||
| * Guy: two sides, the require side would allow conversion of module to ESM while | ||
| maintaining more backwards compatibility. | ||
| * The other side is support import where | ||
| * Guy: valid use case for many projects to compile from CJS into ESM. Main goal | ||
| is the transpilation interopt use case. | ||
| * Joyee: for those uses cases the name should not matter, really we are bikeshedding | ||
| the name. | ||
| * Guy: seems like we are at the point where we are stuck on the bikeshedding. | ||
| * Joyee: would be in favor of having a vote | ||
| * Antoine: have we considered only checking if there is a default export, that would | ||
| avoid having to check a flag? | ||
| * James: don’t necessarily go to a vote, would be good to give people some time to | ||
| take a look at the issue first to see if we can reach consensus. Also don’t | ||
| believe that just using default export will work. | ||
| * Michael: would be good to have summary of the two choices in the issue to help | ||
| people jump in. | ||
| * Guy: seems good to give people some time to jump in. | ||
|
|
||
| * deps: V8: backport f320600cd1f4 (V18.x CVE-2024-4761) [#54597](https://github.com/nodejs/node/pull/54597) | ||
| * Matteo: added, believe we discussed last time. We agreed that we will not backport it | ||
| * agreed we should remove from the agenda | ||
|
|
||
| * Expose Undici's ProxyAgent and setGlobalDispatcher within Node [#43187](https://github.com/nodejs/node/issues/43187) | ||
| * We discussed last time, there was openness to including more of Undici but not all, remove | ||
| from agenda for now. | ||
|
|
||
| ### nodejs/TSC | ||
|
|
||
| * Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614) | ||
| * Antoine: CI is not at its best, very hard to get green CI | ||
| * flaky tests, either test issue or actual intermittent bugs | ||
| * macos machines were having disk space issues | ||
| * opened to discuss how we can do better | ||
| * Yagiz, in last week a few collaborators reached out to express frustration because it is nearly | ||
| impossible to land a PR. 5-6 related to flaky tests. | ||
| * main concern is that collaborators will get frustrated and stop collaborator | ||
| * Michael: main problem is that we don’t have people who will invest in fixing tests | ||
| * Yagiz: believe we have too many machines. Linux foundation was supposed to get | ||
| introduced to our infrastructure and improve | ||
| * Michael: issue is generally not machines, but tests being actually flaky | ||
| * Richard: its a combination of issues. MacOS machines have always been tight in space. | ||
| There have been no changes in the machines. Know issue that at least one test is writing into | ||
| tmp but eliminated that. If anybody know osx well and can help figure out where the extra | ||
| Space | ||
| * Richard: issue snowballs because people are running more builds (probably because of | ||
| flaky issues). Resume build comes from Jenkins plugin, when you resume it re-runs | ||
| everything that has not passed including jobs where there were flakes | ||
| * Richard: don’t think we have an issue detecting flakes, main issue what do we do with flakes | ||
| once we mark them as flakes. Fundamentally its a resourcing thing where people look at the | ||
| flakes. | ||
| * Matteo: | ||
| * took a look at some of the flakes, typically they are related to timing differences in I/O. http, | ||
| http, net. Makes it hard to investigate without logging on the machine as it passes locally | ||
| Easily. In some cases seems impossible to get the same test passing on both systems. 90% are windows tests flaky. | ||
| * Joyee: We really need some volunteers to look at the flakes, not sure how we can get enough volunteers. 50/50 for flaky | ||
| tests bug in test or bug in Node.js. Not necessarily test with infra, just occurs on some infra because it exposes | ||
| the problem. Need to investigate versus just marking as flaky as a memory issue with cause other tests to flake as well. | ||
| * Richard: If you need access to a machine you can open an issue in build repo to get access | ||
| to a machine to do investigation. | ||
| * Yagiz: had open flaky pull request PR which could not land because of other flaky tests. | ||
| open for more than 10 hours. Can we talk about how we can land those faster. | ||
| * Michael: we should agree on our approach as that will lead to agreement on how we should | ||
| address flaky tests. | ||
| * Joyee: for that specific pull request we should just add another entry to mark the additional | ||
| test that flaked and run again. | ||
| * Michael: suggestion is PR to collaborator guide to capture how we handle a specific case in | ||
| terms of landing even if flaky tests. | ||
|
|
||
| ## Strategic Initiatives | ||
| * Skipped as we ran out of time | ||
|
|
||
| ## Upcoming Meetings | ||
|
|
||
| * **Node.js Project Calendar**: <https://nodejs.org/calendar> | ||
|
|
||
| Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. |