Repository navigation
Node.js Technical Steering Committee (TSC) Meeting 2025-01-22 #1676
Description
Activity
I think the plan for this meeting is to invite the folks at @nodejs/platform-smartos to discuss.
Can everyone interested join this?Reacted by Joshua M. Clulow and Brianna MadelineCan we please be sure to discuss nodejs/node#56671 and the general strategy around
node:testusage 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.
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)
Can we please be sure to discuss nodejs/node#56671 and the general strategy around
node:testusage 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.
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:testor not. Just yesterday I was banging my head againsttest/parallel/test-node-output-errors.mjs- even though it is written withnode: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...Reacted by Luigi Pinca and Michaël ZassoI personally don't care if it's
node:testor 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.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.Reacted by Luigi Pinca and Michaël ZassoI 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.
Reacted by Luigi Pinca and Michaël ZassoMy 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:testmight 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:testfor 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)
Reacted by Michaël Zasso and Beth GriggsVery 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.
That literally happened yesterday in nodejs/node#56671 but ok I suppose.
Not a first time contributor, find another example.
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 aFirst-time contributorbadge at the time, which is probably the source of the confusion here.The commit-queue label was added to nodejs/node#56659 on jan 19, 2025 6:39 PM GMT +1, but ok.
@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.
@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.
Time
UTC Wed 22-Jan-2025 16:00 (04:00 PM):
Or in your local time:
Links
Agenda
Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
nodejs/node
nodejs/TSC
Invited
Observers/Guests
Notes
The agenda comes from issues labelled with
tsc-agendaacross 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.