Node.js Technical Steering Committee (TSC) Meeting 2025-01-22

[mhdawson]

Time

UTC Wed 22-Jan-2025 16:00 (04:00 PM):

Timezone	Date/Time
US / Pacific	Wed 22-Jan-2025 08:00 (08:00 AM)
US / Mountain	Wed 22-Jan-2025 09:00 (09:00 AM)
US / Central	Wed 22-Jan-2025 10:00 (10:00 AM)
US / Eastern	Wed 22-Jan-2025 11:00 (11:00 AM)
EU / Western	Wed 22-Jan-2025 16:00 (04:00 PM)
EU / Central	Wed 22-Jan-2025 17:00 (05:00 PM)
EU / Eastern	Wed 22-Jan-2025 18:00 (06:00 PM)
Moscow	Wed 22-Jan-2025 19:00 (07:00 PM)
Chennai	Wed 22-Jan-2025 21:30 (09:30 PM)
Hangzhou	Thu 23-Jan-2025 00:00 (12:00 AM)
Tokyo	Thu 23-Jan-2025 01:00 (01:00 AM)
Sydney	Thu 23-Jan-2025 03:00 (03:00 AM)

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Technical%20Steering%20Committee%20(TSC)+Meeting+2025-01-22&iso=20250122T1600
• or https://www.wolframalpha.com/input/?i=04PM+UTC%2C+Jan+22%2C+2025+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1UzJTZxA64DbrJk9ktlEdHi8mL7fthKTTes6qnNmiofY/edit

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

• doc: change smartos support type to experimental #56220
• test: improve zlib tests #55716

nodejs/TSC

• Status of smartOS support and what future holds #1663
• Clarify the Charter so that contractors are explicity counted as affialiated #1650
• Let's talk about the CI situation #1614

Invited

• Antoine du Hamel @aduh95 (voting member)
• Yagiz Nizipli @anonrig (voting member)
• Benjamin Gruenbaum @benjamingr (voting member)
• Ruben Bridgewater @BridgeAR (voting member)
• Gireesh Punathil @gireeshpunathil (voting member)
• James Snell @jasnell (voting member)
• Joyee Cheung @joyeecheung (voting member)
• Chengzhong Wu @legendecas (voting member)
• Marco Ippolito @marco-ippolito (voting member)
• Matteo Collina @mcollina (voting member)
• Michael Dawson @mhdawson (voting member)
• Rafael Gonzaga @RafaelGSS (voting member)
• Richard Lau @richardlau (voting member)
• Robert Nagy @ronag (voting member)
• Ruy Adorno @ruyadorno (voting member)
• Paolo Insogna @ShogunPanda (voting member)
• Michaël Zasso @targos (voting member)
• Tobias Nießen @tniessen (voting member)
• Anatoli Papirovski @apapirovski (regular member)
• Beth Griggs @BethGriggs (regular member)
• Ben Noordhuis @bnoordhuis (regular member)
• Colin Ihrig @cjihrig (regular member)
• Geoffrey Booth @GeoffreyBooth (regular member)
• Moshe Atlow @MoLow (regular member)
• Shelley Vohr @codebytere (regular member)
• Rich Trott @Trott (regular member)
• Joe Sepi @joesepi (Guest - Node.js CPC rep)

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Zoom link: https://zoom.us/j/611357642
Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

---

Invitees

Please use the following emoji reactions in this post to indicate your
availability.

• 👍 - Attending
• 👎 - Not attending
• 😕 - Not sure yet

[mhdawson]

Going to add #1678 for awareness as well

[mcollina]

I think the plan for this meeting is to invite the folks at @nodejs/platform-smartos to discuss.
Can everyone interested join this?

[jasnell]

Can we please be sure to discuss nodejs/node#56671 and the general strategy around node:test usage in tests.

@lpinca has taken to blocking many of these.... https://github.com/nodejs/node/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen++%22test%3A+migrate+tests+to+use+node%3Atest%22+

My general opinion on it is: Our tests as a whole need (a) more structural consistency, (b) better structure with clear delineation between individual things being test, (c) A clear consistent style across the test suite, (d) more documentation about what is being tested for, what is being asserted, (e) more separation between internal API tests and public API surface tests, etc. I would rather we not end up in a case where we have more inconsistency between tests where some have a more defined structure and others have no structure at all, some have more documentation and others have no documentation at all, etc, and we're in a situation now where multiple contributors, including brand new contributors, are being blocked by a single individual over what appears to be mostly a disagreement over style.

[anonrig]

I think the plan for this meeting is to invite the folks at @nodejs/platform-smartos to discuss. Can everyone interested join this?

I can't attend tomorrow due to doctors appointment, but I've tried to ping the team and all issues I've encountered/seen in the past 2 weeks. Most recent one by @joyeecheung: nodejs/node#56590 (comment)

[anonrig]

Can we please be sure to discuss nodejs/node#56671 and the general strategy around node:test usage in tests.

@lpinca has taken to blocking many of these.... https://github.com/nodejs/node/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen++%22test%3A+migrate+tests+to+use+node%3Atest%22+

My general opinion on it is: Our tests as a whole need (a) more structural consistency, (b) better structure with clear delineation between individual things being test, (c) A clear consistent style across the test suite, (d) more documentation about what is being tested for, what is being asserted, (e) more separation between internal API tests and public API surface tests, etc. I would rather we not end up in a case where we have more inconsistency between tests where some have a more defined structure and others have no structure at all, some have more documentation and others have no documentation at all, etc, and we're in a situation now where multiple contributors, including brand new contributors, are being blocked by a single individual over what appears to be mostly a disagreement over style.

@nodejs/tsc I can't attend tomorrow but I'd appreciate if you could discuss nodejs/node#56027. It's not blocked by anyone, and can be merged as it is, but due to the relation of the topic agenda, it would be in benefit of the project to talk about this one last time before merging it.

[joyeecheung]

My general opinion on it is: Our tests as a whole need (a) more structural consistency, (b) better structure with clear delineation between individual things being test, (c) A clear consistent style across the test suite, (d) more documentation about what is being tested for, what is being asserted, (e) more separation between internal API tests and public API surface tests, etc.

I feel that these are not very well related to the use of node:test or not. Just yesterday I was banging my head against test/parallel/test-node-output-errors.mjs - even though it is written with node:test, I don't find it any better in these regards that help me understand it when I changed the module loader internals in a way that broke the test...

[jasnell]

I personally don't care if it's node:test or not. We need to improve our tests and we need to do so consistently. I'd like a blessed approach not an ad hoc approach that just leads to more inconsistency.

[joyeecheung]

we're in a situation now where multiple contributors, including brand new contributors, are being blocked by a single individual over what appears to be mostly a disagreement over style.

FWIW I would agree that these should not land, to quote myself from nodejs/node#56027 (comment)

I think maybe a good measure about this might be: only the people maintaining what the test is testing get to choose what format the test should be written in, and forbid test-only changes from PRs that don't simultaneously change the features that the test is testing (unless they obviously had many commits in said feature or they reach consensus about this if there are multiple people maintaining said feature).

Style-only changes, in general, are counter-productive for our workflow. For example I am in the process of backporting require(esm) to v20.x, and it has many dependency commits. The amount of conflicts already makes it hard enough that I am on the verge of giving up and I only have not given up because many package maintainers count on this to be able to drop dual shipping this April. But if I had to struggle with mass conflicts in the middle that were only introduced for stylistic preferences, it would be annoying enough that I would not do it.

[joyeecheung]

I personally don't care if it's node:test or not. We need to improve our tests and we need to do so consistently. I'd like a blessed approach not an ad hoc approach that just leads to more inconsistency.

I feel that in that case, we should focus on the guide lines that actually help improve the tests e.g. writing comments, splitting tests properly, and leave node:test out of the equation. Personally I find many of the existing tests that use node:test are harder to understand due to the fact that they squeeze way too many test cases in one file, or have only very few words that don't even form a sentence as descriptions, like the one mentioned and many other test/es-module. I doubt blessing node:test makes any difference if the existing tests that use it are already not great in terms of readability, or worse than many tests without it that are smaller and have more comments.

[lpinca]

My general opinion on it is: Our tests as a whole need (a) more structural consistency, (b) better structure with clear delineation between individual things being test, (c) A clear consistent style across the test suite, (d) more documentation about what is being tested for, what is being asserted, (e) more separation between internal API tests and public API surface tests, etc.

This was already discussed in nodejs/node#54796, and I think the wast majority of our tests are good as is. I agree with (d) and it can be solved it comments. (c) is already in place, inconsistencies are being created by the useless refactors. I also partially agree with (b) and if the a test contains multiple subtests, using node:test might make sense (I would prefer to split it into individual tests though).

we're in a situation now where multiple contributors, including brand new contributors, are being blocked by a single individual over what appears to be mostly a disagreement over style.

I do not remember of ever blocking a first time contributor PR over this. I have actually refrained of doing so in some cases (nodejs/node#55747 (comment)) and it is not about style, it is about adding value. All the PRs I am blocking do not improve anything, they are just making things worse than they are.

Quoting myself from nodejs/node#56027 (comment)

After months of discussions (nodejs/node#54796, here, several refactoring PRs) I still can't see any good/solid reason in favor of using node:test for existing (and new) tests. All the reasons listed so far by proponents (3de15b8, nodejs/node#56027 (comment)) are weak (sometimes invalid) and don't even remotely outweigh the disadvantages.

To name a few

• Added complexity
• Spurious code run as part of the test
• Slower execution
• Harder debugging (doc: add restrictions around node:test usage node#56027)

[jasnell]

Very well. I'll drop it. I completely disagree but I can see no progress will be made and it'll be pointless to try.

I do not remember of ever blocking a first time contributor PR over this

That literally happened yesterday in nodejs/node#56671 but ok I suppose.

All the PRs I am blocking do not improve anything, they are just making things worse than they are.

Opinions can reasonably differ.

[lpinca]

That literally happened yesterday in nodejs/node#56671 but ok I suppose.

Not a first time contributor, find another example.

[aduh95]

That literally happened yesterday in nodejs/node#56671 but ok I suppose.

Not a first time contributor, find another example.

tbf, at the time of the block (08:12 AM UTC) that user didn't have any commit on main – nodejs/node@23c2d33 landed later on the same day (17:16 UTC) – so it's possible that GH UI was showing a First-time contributor badge at the time, which is probably the source of the confusion here.

[lpinca]

The commit-queue label was added to nodejs/node#56659 on jan 19, 2025 6:39 PM GMT +1, but ok.

[jasnell]

@lpinca :

Not a first time contributor, find another example.

@lpinca ... I'm sorry but this dismissive and pedantic attitude is toxic and unwarranted. The contributor IS a first-time contributor. The fact that they happen to have had two PRs in the pipeline at the same time does not change that fact. They are a brand new contributor seeking to make small initial contributions so that they can learn the process of how contributions work, how code review works, etc before seeking to make more substantial contributions later. So far the experience has been... less than encouraging... for them and this kind of response is unfriendly and unwelcoming.

[lpinca]

@jasnell no offence but so is this

and we're in a situation now where multiple contributors, including brand new contributors, are being blocked by a single individual over what appears to be mostly a disagreement over style.

Again, find other examples where this is true.

[mhdawson]

PR for minutes - #1679