Node.js Tooling WG Session  ## Metadata - Author: [[OpenJS Foundation]] - Full Title: Node.js Tooling WG Session - Category: #articles - Document Note: --- tags: [#nodejs, #tooling, #workinggroup] - #nodejs - #tooling - #workinggroup Author: Node.js Tooling WG participants Source: Node.js Tooling WG Session (YouTube) Reference: [Watch on YouTube](https://www.youtube.com/watch?v=SD4DtXoxjjg) date created: 2025-08-24 10:45 --- # Title: Node.js Tooling WG Session: Challenges, Contributions, and Future Directions ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: The Node.js Tooling Working Group (WG) session highlighted persistent challenges in tooling contributions, especially around PRs getting stuck due to lack of platform access and unclear documentation. Discussions emphasized the success of features like the argument parser and test runner, while pointing out gaps in mocking/stubbing capabilities. Contributors stressed the need for clearer processes, reduced meeting frequency, and standardization efforts (e.g., package.json). The session underlined the importance of lowering organizational barriers to enable sustained contributions and future-proofing Node.js tooling. --- ## 📖 Main Content: This session covered: - Tooling origins as a userland-inspired group for maintainers and users to collaborate. - Challenges in adding recursive directory traversal to core due to FS complexity and platform testing gaps. - Platform access issues: SmartOS and AIX lacked clear support/documentation, leaving contributors blocked. - PR bottlenecks: Draft PRs often stall and miss attention; experienced contributors know how to unstick them, but new contributors struggle. - Success stories: Argument parser and test runner, both widely adopted and praised. - Test runner debates: Should it remain minimal or expand to include mocking, stubbing, and broader feature parity? - Calls for interactive CLI support to reduce reliance on external packages like Inquirer/Yargs. - Proposal to reduce meeting cadence (monthly/bimonthly) to encourage more effective contribution. - Agreement to standardize package.json and improve tooling APIs in the near term. ### 🗒️ Notes - [00:00](https://www.youtube.com/watch?v=SD4DtXoxjjg&t=0) WG context: userland-inspired, collaboration hub. - [01:00](https://www.youtube.com/watch?v=SD4DtXoxjjg&t=60) Recursive traversal effort blocked by FS complexity. - [02:50](https://www.youtube.com/watch?v=SD4DtXoxjjg&t=170) Contributor blocked for months due to SmartOS/AIX gaps. - [07:52](https://www.youtube.com/watch?v=SD4DtXoxjjg&t=472) PRs get stuck, draft PRs often ignored. - [11:25](https://www.youtube.com/watch?v=SD4DtXoxjjg&t=685) Argument parser + test runner successes. - [15:08](https://www.youtube.com/watch?v=SD4DtXoxjjg&t=908) Call for mocking/stubbing in test runner. - [18:25](https://www.youtube.com/watch?v=SD4DtXoxjjg&t=1105) Test runner responsibilities unclear. - [21:52](https://www.youtube.com/watch?v=SD4DtXoxjjg&t=1312) Proposal: reduce meeting cadence for effectiveness. - [25:08](https://www.youtube.com/watch?v=SD4DtXoxjjg&t=1508) Standardize package.json, finish create/init tooling. --- ## 📖 References: - Node.js Build Working Group docs. - TAP API specifications. - NPM/Yargs/Inquirer tooling ecosystem. --- ## 🗣️ Paraphrase: 1. **Original**: “If a new contributor got hit with blockers on SmartOS, they’d walk away forever.” **Paraphrase**: Without proper documentation or platform access, contributors are discouraged and abandon efforts. 2. **Original**: “Reduce meetings to once a month; too many meetings reduce contributions.” **Paraphrase**: Lowering organizational overhead enables more time for actual code contributions. --- ## 📰 Newsletter: 🛠️ **Node.js Tooling WG Tackles PR Bottlenecks & Test Runner Future** At the latest Node.js Tooling Working Group session, contributors discussed successes like the argument parser and built-in test runner, while identifying challenges with PR bottlenecks and platform testing (SmartOS/AIX). Key takeaways: - Reduce meeting frequency to monthly for better contributor retention. - Improve platform documentation to prevent contributor drop-off. - Expand test runner with **mocking & stubbing** capabilities. - Push for **package.json standardization** and interactive CLI improvements. 👉 Watch the session: [Node.js Tooling WG Session](https://www.youtube.com/watch?v=SD4DtXoxjjg) --- ## ✅ Action Items: - Align with **WordPress contributor onboarding**: Document platform requirements clearly. - Highlight **test runner debates** as a parallel to WP’s unit testing gaps. - Advocate reduced **meeting burden** in OSS governance to avoid burnout. - Position standardization of **package.json-like metadata** as essential for OSPO leadership. --- ## 🧪 Hypotheses: - Clearer documentation increases contributor retention in OSS projects. - Lower meeting cadence improves quality of contributions. - Adding mocking/stubbing to Node’s test runner increases adoption. ### 📊 Methodology: - Survey contributors about blockers (docs, platform access, PR handling). - Analyze PR timelines for stalled vs. successful merges. - Compare contribution rates before/after meeting cadence changes. ### ❓ Questions: - Should test runner remain minimal or expand toward feature parity with popular frameworks? - How can other projects replicate Node’s argument parser success? - Could WordPress benefit from standardized `package.json`-style metadata? ### 🔮 Future Research: - Comparative analysis: Node vs. Python tooling ecosystems. - Metrics on contributor attrition linked to meeting burden. - Standardization efforts for interactive CLIs across ecosystems. ### 💡 Implications: - Practical governance changes could **increase sustainability**. - Better docs + fewer meetings = healthier OSS ecosystems. - Expanding tooling APIs improves adoption across languages. --- ## 🧠 Learning Styles Assessment: - **Visual**: Transcript lacked visuals ❌ → add diagrams of PR flow/testing matrix. - **Aural**: Available as video/audio ✅. - **Verbal**: Rich with narratives/examples ✅. - **Kinesthetic**: No hands-on demos ❌ → add repo exercises. - **Logical**: Strong causal reasoning ✅. - **Social**: Group discussion format ✅. - **Solitary**: Reflection prompts absent ❌. - **Naturalistic**: No analogies to systems ❌. --- ## 📊 Accessibility Assessment: - Transcript improves screen reader access ✅. - Alt-text missing for any referenced visuals ❌. - Meeting video lacks captions ❌. - Navigation depends on timestamps, works but could be clearer. --- ## 🌍 DEIB Assessment: - **Cultural Relevance**: International contributors (Israel, Italy) ✅. - **Inclusive Language**: Neutral, non-gendered ✅. - **Neurodiversity**: Dense, complex dialogue ❌ → needs clearer structure. - **Representation**: Technical-only, no explicit identity inclusion ❌. - **Psychological Safety**: Supportive tone ✅. --- ## ✅ Logical Validity: - **Sound reasoning**: PR bottlenecks reduce contributor engagement. - **Causal logic**: Too many meetings → fewer contributions. - **No major fallacies** detected. - Tone: collaborative, problem-solving, sometimes frustrated. --- ## 🔍 DARVO Analysis: - **Deny**: Not present. - **Attack**: Not present. - **Reverse Victim**: Not present. 👉 No DARVO tactics. Instead, session was collaborative and constructive. --- ## 🔍 SEO Evaluation: - **Keywords**: Node.js, tooling, PRs, test runner ✅. - **Meta description**: Missing ❌ → Suggest: *“Insights from t - Summary: During the Node.js Tooling WG Session, members discussed ongoing progress around tooling using Node.js, including efforts to add recursive traversing of directories to core and the challenges of making sure features work on all supported platforms. Participants also highlighted successful efforts, such as the argument parser and the test runner. Some attendees expressed interest in better documentation and procedures for accessing and using certain tools and platforms. - URL: https://www.youtube.com/watch?v=SD4DtXoxjjg&list=PLyspMSh4XhLO15jJD9Sj069fN18j12AbQ&index=12&ab_channel=OpenJSFoundation okay so yeah welcome everyone to thetooling group meeting so we're here todiscuss uh thingsyou know the everything that revolvesaround tooling using nodejs so this isuh this wasn't very much a user landkind of inspired working group but it'sInception right like a place whereauthors maintainers and users can cometo and you know talk about their Banksand propose Solutions and new stuffright like and uh yeah yeah we've done a lot of uhyeah yeahlet's letlet's start with Ethan here who whoended the last one right yeah the mostrecent yeahuh userlandum everyone has wanted to be able torecursively Traverse a directoryum and there was four or five differentpackages all that did the exact same thing in different ways and everyoneseemed to either write the codethemselves a million times or use one ofthese random dependencies andum I think motivation was to can we justadd this to core it was a little bitharder than originally suspected basedbecause of the complexity of Fs in corewhich is one of the oldest apis in nodeif not the oldest and so it's just likeit took a little bit to get thereum but we did and uh I think actually one one thing that came of that that wemight want to dive into isthe the biggest Blocker on the wholeproject uh or the contribution was atfirst what API do we even want to landthere that we unblock that prettyquickly with just land anything land thesimplest thing and we'll iterate fromthere cool problem solved but then I'mimplementing it it works on my machineit works on all of the normal machines so Linux Windows Mac even some of themore Niche things but smart OS and AIXthe only two where it failed I don'teven know what these things are I don'teven know how to run it and I couldn'tfind someone for the longest time infact it was a whole year ago I think Ibrought up like hey guys I can't finishthis I don't know what to do can someonehelp me and someone's like oh yeah likelet me help you they were not much helpand then and then I waited anothercouple months and I Revisited and I was like okay someone help me and I tweetedabout it no one said anything and theneventuallyum uh I believe his name is moshum he or at least mosh low on on GitHubhe actually was able he sat down andpaired with me for like four hoursum and he he's in Israel I think sototally International awful time zonesbut we spent four hours and we figuredout the one problem and then there was asmall change that you made and next thing you know it lands and it's one ofthose like I think the biggest learningthere is a why the heck are we likewhat's the smart OS thing and like whywas that such a blocker and like ifsomeone's not an expert in smart Os orif we don't have someone who canactually run one of those systems andlike uh debug on it then likewhat are we doing trying to like why isthere a supported why is it supportedand why because it's not supportedbasically yeah because it's not exactly and it's notbut but if a if a potential contributorwho has all like every intent on doingthe right thing wanting to test againstthe Matrix and and and build for thoseenvironments can't find a machine orcan't get access to a machine and andI'm I know you're a smart person likeyou will find and we're probably havinga hard time finding like like anenvironment for you to like reproduce that issue if we don't have those toolsthen how can we expect anybody like howcan we expect like to be building forthose platforms yeah can I ask have wedone any of the iteration you mentionedand if so has this come up as a repeatedproblemum so in this feature in particularum I followed it up almost immediatelywith another pull request that umimproves the algorithm that's being usedand uh at least so far I don't believeit has tripped up in those same systems um interestingly enough those systemsdid catch a very weird Edge case thatonly happened on those systems but it'sit's a kind of fault where to gettechnicalum it's like essentially it came down toan issue with stat like when you runstat on a file system object thosesystems basically don't give you anyinformation versus every other systemgives you information when you run stat on on file system objects so that's athat's a I guess a real Edge case thatactually our file system code is verycomplex as a result because we need tosupport that niche as case and it's likeokay actually my code was wrong Iactually I wasn't considering this Edgecase that's not documented in our codethat has no clear signal it's one ofthose ones where even the people I wasasking all these questions for no oneknew that and we had to ReDiscover that edge case now that I know it it's it'sobvious now it's one of those okay Ihave that experience where that is hitbut the go back to it is if I was anyother contributor who got hit thatblocker and wasn't as invested in thiscommunity I would have walked awayforever ago and we would have never hadthis feature and it would probably stillbe sitting incomplete on a pull requestso I'll add we do have a procedure maybeneeds better publication but you can get access to any of our platforms on fromthe build working group yes that thatprocess someoneum I think I literally wrote in ourslack Channel how do I get access to oneof these things and the replies I gotwere just go ask in the repo and I waslike nothing in the repo says thatnothing in the build or any there's nodocumentation that says if you needaccess to a certain Os or build systemor anything there is no formal processunless it is it is written down in the build there's a process written down inthe build working group for how you howwe give out access and the requirementsI know I'm not saying I'm saying it isit is documented in the build workinggroup but I said in the beginning couldbe used better publicationis there any documented process for whatis and is not supportedplatforms and how to build changes tothose there is a list uh in I think this one is actually in building in the mainrepo there's tier one through tier tierone two three two through tier three andI think experimentalso smartos is at most tier twocontains node version 0.10that's what it ships with so why are webuilding node 20 to run smart internallyso interesting they're they're they'rethey they I mean smartass came from joint so at one point it was like wowthe main thing that that they wanted tosupport they're still interested I willadmit I prefer they were a little moreactive in the project so if there is aproblemBrian's and I forget his handle but likewe can we can say heythere's a problem on on smartos and andget them involved but it does take morework to uh to do thatI mean I think what I'd say is like a good example of a general problemit's very easy for PRS to get to getbogged downand not get help right so if you knowwhat to do you've been in the project along time you know who to reach out toyou know there's a build working groupyou can unstick your PRSif you're submitting a PR that somehowgets stuck or even sometimes likeI try to avoid this myself now if youactually submit something as a draft and you want it or early don't do thatbecause it means that by the time youmake it undraft it's like way old peopledon't notice it you're better off like abrand new PR then that those are theones that people see and so that's thebigger problem is is maybeand I don't know how you solve thatbecause it all comes down to peoplespending their own timebut it's easy to get a PR that basicallygets stuck there and you're like helpand like well nobody else cares so theydon't help right think oh okay go ahead oh just about aquick question I'm not going to mentionthat we have title one two and threesupport four platforms but from what Isee when I set up PR if I get let's saya red on Smart OS my PR will not bemerged so we are not actually havingentire different types we just supporteverything at the same level right yeahyes yeah like that definitely if it's in our CI it needs to passright is basically the way that that itis you're right on that like we don'tsay hey you can you can land it if it'sred on because then it's red forever andlike your Ci's read that just doesn'twork right yeah I think I remembered Iremember the days of of red CI and ittook it was a Herculean effort to makethat actually green and it's nice nowthat you can actually add a feature andadd extensive tests to it and all the systems do come back green I will saythat I think the the hardest part is forme is the if we want we have all thistalk about new contributors and tryingto get sustained contributors and likelike West joked like I don't have manyPRS myself to the node project in fact Idon't even have I think the actualcontributor role like I can't like uhadd labels or anything like that yetI've been involved since 2016 and I'vedone things in fastifying all thisthere's that weird line of like if if the node projects even wantscontributors like myself to con to stayin involved and be more consistentwe need to improve some of these theseprocesses tooling group is probably thebest place to do some of this because itis that was the Big Driver originally toeven get me doing that contribution waslet's do it just just ship it and yeahI just realized I think we're very short on time here because it started lateyeah I think I think we're supposed tobe wrapping up at six but I think we'regoing to take a little longer rightalmost six yeah almost six butyeahI mean the GitHub event like right nextdoorI think it's right supposed to be hereI'd like to mention my just on thissubject of the introduction we'retalking about you know uh what are thebiggest hits from the group I also my favorite one would definitely be the uhargument parser right that one tookforever and like I I know not everybodywas happy with the result the outcomebut yeah exactly exactly and that's abig yeah yeah me too all the time now II need to use it more yeah we're uhwe're gonna search which major versionto land inyeah no nowe have it got back bordered yeah yeah go aheadohI think so I think so and I'll say likeas someone who's not didn't work on itlike it's it was a success fromum I use it in like all sorts of toolsnow like obviously the CLI hasn'tadopted it but now if I'm writingespecially an internal tool or somethingthat is I I just it's an amazing feelingto not have to reach for another packageyeah I think the community like aspectof it it was a big hit like yeah writingsamples to honestly like writing samples is just a joy now has it landed in yardsunder the hood yetthat I'm not sure that I don't think soI thought that was the plan that Bensaid it was okay yeah I think Ben reallyuh uhuh lowered his open source contributionsitself I know it's hard for him to be uhshipping Network now right but uh Ithink that's a plan yes okay yes stillthe planthe test Runner loving that um I see a lot of contributions landingon that uh every like every time I checkit out looks like something new getsadded something new gets fixed loving tosee that also loving that it's the nodeit's the tap API and then we talk aboutlike there's like you know the semper isstandardized but it's not tap isstandardized but it's not like we haveinternal debates all the time and I betevery other company does too of likejest versus mocha versus Ava versus and I'm like I know and I'm like I'm likehey everyone no tap and guess what it'sin core and everyone's like oh okay doneit's in coreI don't want to get uh since we'rerunning out of time but just a questionaboutum that and in general like the toolinggroup what is is there anythingdocumented for like how far we want thetest Runner to go because as youmentioned like test Runners are full ofopinions and full of surface area in my opinion we're like do you want it toautomatically look at your changed filesbased on your git status and run just onthose and how do you want coverage towork and like there's a lot of opinionsthere has there been discussion as likehow far should the node built-in runnergoohapologies where do we go with this how limited canwe stay like what's the most limitedversion of this becauseI'm a crazy kind of like yeahone thing about the test router is thatsorry now that we have the test Runnermaybe we should expand the assert modulea little bit so we can catch up on theirsession that you get in not dub for instance so I'm not saying that we haveto match the feature of notap becauseit's way beyond our scope but at leasthaving a similar assertion to T comparewith the dependency that they're usingwould help a lot to for simple casesto do a set of response I have insuranceyeah I would say like a hundred percentum I look at the node test runner atlike tooling group perspective wiseum I ain't planning on on writing likelarge swaths of integration tests and end-to-end things using the built-intest Runner what I would love to do iswrite a new feature throw in a coupleunit tests on that and call the day andthen if I need to reach for the likecraziness awesomeness that is likeCypress and or node tap itself and dothese you know when I have 5 000 teststo run in parallel I don't expect notest Runner to ever do that butyou know proof of concept or even my mybasic unit test coverage for a brand new feature that's where I'm like no testsshould be all I needum and so yeah bring you some featureparity would be awesome it's actuallycool maybe um maybe if this is anopportunity for node tooling groupum in my team at versel we actually dida comp an intern internal comparisonbetween a bunch of different testRunners because we're trying to makethis decision and it turns out thatthere is not a crazy featuredifferential difference there's betweenthingsum so it'd be cool to maybe share some of those findings and be like what canwe do to bring up the node test Runneryeah maybe I wonder what you say on onum feature parody I think one thing whatI would miss to switch to note Runnerimmediately is the mocking capabilitiesor starving capabilities like I need tobe able to say dependency XYZ I want tohave this stuff in there or this fileshould not be part of the test I want tostop it out and mock the interfaces ifwe can get this out I think things like white and just they all youknow can be focused on browser testingmore my node can be good for node and Ithink mocking and stabbing that could besomething that every node developer justwriting tests for node platform couldreally use and I'm not sure if there'salready a tool for thatbut I was talking to the white team andthey have open source the package fortheir mocking but I think that worksdifferently anyway but we can probably achieve that if wejoin the um the initiative fortypescript support remember thatproviding the loaders a better loadersAPI to interpreter we can probably usethe same API for mocking purposes beforeeven you start the test use that loadersto intercept your uh request and mockthem probably that might be a jointeffortthe loaders that you pass isn't even themain proposal for that that you pass itas a command line flag at the start of the process so you need to like childprocess the test run of course I don'tthink the current Runner is doing but Iknow like a lot of the other Runners dothat yeah but no good right nothingProvince you to internally use your ownAPI to provide mocking support even eventhough the API is for another purposeyou can probably use the same oneuh one more general question what is uhif it didn't come out of the toolinggroup what's the best place for futurediscussions about the test Runner is there a working group responsible forthat or is it just within PR's and slackchannelsjust uh just discussion about thecurrent test Runner and yeah I think thecurrent test Runner correct if I'm wrongbut I think the two collaborators I seemore active on it is uh and Marshall andand Colin yeah so I think like reachingout to them directly like maybe gettingthem to sit down you know because Iwould be curious we do a lot of very interesting test usage in the CLI rightwhere weum there's certain places where like webroke node tap or it needed a fix and notap because we are forced toum like overwrite the process object andoverride process exit and test that andthen it's like but node tap was alreadyyou know mucking with proxy process exitbecause they need to know when the testsend and like you know we can get intoedge cases and I'm curious if I didexperiment with that on the CLI who would who who could I reach out to rightright yeahI'll I'll break I'll break itright away yeah yeah what uh I knowwe're like out of here I know we're likewe can just chat until we go to thewhatever the next thing is are there anyother big tooling initiatives you wantedto highlight well I I wanted to at leasttry to discuss something you know other than the highlights like if we don't getkicked out right like I think we can getyeah oh so you're the next session sorryabout thatACPyeah yeah so the other thing isis are we gonna all miss the dinnerbecause I think it's now where there isa dinner nowsix so that's what I'm saying if we're continuing here we are fully missing thedinnerI need to eat and it is your companyjust wondering what should like why thisperson why did they scheduleD okayyeah in in the light of learning thatthe speaker the next talk is next topicis here so I think we should wrap upbut this was great I think that is tointerest for group right like and thegoal of having running a session here was to kind of try to pick up interestagain right and see if we can get a anagreement on a date and time that worksfor everyone to kind of meet every oncein a while maybe just even if it's oncea month oryou know but at least keep the groupalive I think that's uh I mean I thinkwe did a lot of great stuff and it's agood it's a good tooling forit's a good group for onboarding peopleto the project you know like and doerspeople that want to contribute that wantto do stuff so yeah if I can I'll say what I've learned fromum getting winter CG up off the groundfor the past year-ishum almost a year now I think it startedlast summer isthere is a balance between theorganizational efforts and thecontribution efforts I thinkum thelowering the organizational efforts canactually let there to be morecontribution efforts in the sense oflike don't ask me to come to a tooling group meeting every week don't ask me tocome to one every other week either askme to come to it maybe once a month andyou've got a good shot of me being therebut alsocreate an issue assign me the task andthat'll be like let's let's go build thetoolthe mpmrcs every week can you never showthat yeah I know why yeah but now youknowyeah too much too many meetings so it'slike if you I think if we want to restart tooling group again I don'tthink I attended many tooling groupmeetings either but the one the one ortwo times I do it's like let me makethis as most effective so if we can turnthose meetings into a once a month thingthat might give us some new successbecause it's also super easy to attendone meeting one time yeah than trying tomake it become because everyone's busyeveryone's got all the other meetingsand time zones are a mess yeahokay any any suggestion West uh no I I like that idea I'm fine withthat I would totally I think be able tocarve out you know a meeting once amonthum I wanted to ask this is sort of achange of topic is that all right are wedoneI want to ask if there's interest ininteractive clis we have so we haverighta parser if we had a promptimplementationwe could make so a lot of I think a lotof things are moving to interactive clis because they make more sense to set up aworkflow for people I mean even like npmand net right yeah uh and and thecurrent stuff that is in core is justincredibly unhelpful if you want towrite a a read line is like I've done itand it is like right not funum I'm just wondering if the toolinggroup is has any interest in doingsomething like pull in right bulletin inacquire maybe I don't know or somethingmaybe not that robust but like something because the only reason I'm still notusing in my main CLI is that I maintainat Netflix the main only reason I'm notusing the newuh Arc parser is because the thing thatI'm using wraps yards and Inquirerbecause it's a interactive CLI right andso the I you know when I do I want tomake the change but I would be weird tomake the change for half of it but thenstill be relying on Inquirer it'd bereally nice if I could like re-wrap that whole thing on a just node core apisI see I don't know if yeahI love the idea as well I think that's Iwould that would that be as someone whomaintains versus CLI oh my gosh I wish Icould rip out our Inquirer and argsparsing usage because it's all or likeThe Yards usage it's all old and messyand I'm like it makes me frustrated justthinking about it so if I could like fixthat and use something nicer in core and and ditch some of thoseyou can use my wrapper right now if youwant I have a thing it's called opta andyou it basically takes the Inquirer APIand The Yards API and then munges themtogetheryou know you have like you have like 12but the idea is that it gets rid of allthe probably the code you're complainingabout that's messy that's specificallywhat I wrote it for because I was doingthe create package stuff and the idea is there's this weird thing where like youhave defaults and then you have thislike I passed a command line flag andthat command line flag then it's aninteractive CLI so shouldn't thatcommand line flag either make you notask that question at all because you'vealready provided the input or it shouldset the default to what you input andthen you hit enter right like there'sthese weird interactions and and I wroteall of thatvanilla way and I and I was likehellishly messy right so that's working group pick that up finishit and if there's pieces that followthat that are like that are like itdepends you like the interactiveuh the CLI component like then westandardize that or we say that that'sgood right so let's finish the let'sfinish one of the things that we startedthat's a good ideagjs which actually willplay into also the standardization effort for like let's say in the nextyear right would play into well likebecause what I think this group has beenreally good at and it was kind ofmentioned before a couple people got outhere it's actually like Christian likewe were really good at and big up toChris Hiller for also kind of kickingthis off like essentially going out anddoing like analysis of the currentecosystem and saying here's all thecompetitive analysis of all thesedifferent packages that do the samething can we get something in core thatlike basically does the most minimal version of this thing yeah get thatminimum Baseline thing so you don't needmaybe this more robust thing but you canstill use it if we're not trying to likecut people at the knees for their theirusage like they're still gonna offersomething yards is still going to offersomething on top of that so like I wouldsay let's go back to finishing thatproject and then it plays into thepkg.js and then if interactive CLI popsout of that then we say hey like thiscould be add on to the argument parseryeah at some point I was planning on moving yeah I like this next year thisyear this year let's finish create let'sdo in it and we can do somestandardization of brown package Jsonall through this toolsso okayall right so let's wrap it up but pleaselet us open an issue for the interactivethings I wasn't sure if people cared andI'm going to follow along you know allof you try to see if we can schedule arecurrent meeting that we can all likeyeah something like monthly or maybe even every two months if it's too muchhaving it monthly let's seeyeah okayokay thank you all now let's continuewith the HTTP parser, Node.js Tooling WG Session, OpenJS Foundation, 01h3j60c6wvya1n2tf00kg8nhs.