 So, this is my talk called how the NPM CLI team manages almost 100 open source projects. And I think what I've submitted to the CFP, we had about 94. And since then, we've deprecated a bunch and given a bunch away. So we're now in like the 80s, I think, which is really exciting. I love to give stuff away. Give projects away. But a little bit about myself first. My name's Luke. Luke Carries. I live in Arizona on the NPM team. Not sure if you can see it on the projector. That's a place I like to go ride my bike from my house. So I live in the desert. It's the opposite of here. There's no green. But you can contact me at any of those places. And the reason I needed so much help getting HDMI connected was this is the last, this would be preparing for my last talk. And then this is me preparing for this talk. So Sandsbeard, you know, only one kid. Now there's multiples. They don't number us. And so I think it's about eight years since my last talk. So feels good to be back up here doing talking about JavaScript. What? I did not talk yesterday about sports betting. I did not. All right. So like I mentioned, I'm on the NPM team. I've primarily spent the last two years as part of this NPM CLI team. So we are responsible for currently, these are all numbers as of this morning, 78 packages that are across 78 repos, about 19,000 stars across those, which is not enough in my opinion. I think there's 70, 70 repos of everyone in here stars all 70 repos. I think we can add a few thousand before the end of the day. Be nice. I have a script you can all run after just a GH star all of NPM. And then all together that is about 4.3 billion monthly registry downloads across our full open source portfolio. So that includes Semver, which hosted get info and a few others, which are the top downloads. And a lot of our download metrics don't even account for registry downloads because the CLI itself bundles all of our dependencies. So there's there's a lot of downloads. And that means we have a lot of users. So these are our responsibilities as engineering team. There's currently between two and four ICs working on the NPM CLI at any given time over the last two years. So between two and four ICs, we have weekly and bi-weekly NPM CLI releases. We're currently in a bi-weekly cadence due to me, you know, being here for a few weeks and a few other staffing changes. All the NPM CLI dependencies and all the releases for those, those happen on an ad hoc basis as needed. But I actually forgot to run the numbers for those, but across all 78 packages, we definitely average at least a few releases a week as part of the CLI releases. And so over the last year, I can't do the math, but it's a lot, a lot of CLI running because of us. And we also are first level support, so we do issue triage and pull request review for community pull requests across all of our repos, as well as community engagement with like the RFC call that we have and open office hours. Those are currently on hold as well due to some staffing changes, but we're switching between office hours and the RFC call. So the RFC call is more structured where we discuss specific RFCs pertaining to NPM and then open office hours is like kind of come and ask us questions, which some of you in the crowd I have recognized, take full advantage of. And then we also do, we have bug bounties that we don't triage ourselves. That's part of the GitHub security team does that, but they get escalated to us and those become priority. We fix those as well. And then this all, we also ensure this all is supported across, works across all supported versions of nodes. So we run integration tests across all supported versions of node, nightly node, as well as top packages in the NPM ecosystem. So we run tests like for, what are some that recently bubbled up with actual bugs, create rewired, I forget what the actual name of the package is, but the create react app has a plugin called rewired, which like rewires your create react app config. And we found a bug in NPM when we were publishing version nine RCs. So we run tests against a bunch of top packages. And then we also do backports, which is something new. We just started, we figured we did not have enough to do. So now we, we wanted to develop a system so that we could backport any and all of our features to old release lines. Most recently we, I think we backported a security dependency fix to NPM eight. And it's possible there could be more backports, you know, to NPM six as well. I know there's a few people here as well, which would have been asking for those, but we at least have a system now to do backports. Used to be very difficult, if not impossible. So then our other, you know, those all fit under the umbrella of open source, the MPL. I see our main responsibility as open source, like what does that even mean? It's a, it's a big umbrella, but hopefully I plan to go through like how our approach to open source and what we consider kind of our responsibility within open source as well as the node, the node ecosystem in general. So the first thing I want to say is that everything we do is open. This is a, the new GitHub code search, I'm not sure if you can see the query, probably not, but searching for in the GitHub org or in the MPM org is private. And this is me logged in, obviously authenticated to see private repos and nothing comes up for the MPM CLI topic. So we have a big GitHub org that is the registry and the CLI combined. And we put a topic on all of our repos and all of those are currently open source. We have one repo in a different org, which we use to triage, security, private security vulnerabilities. And that is our, our currently our only private repo. So that, that includes our status board is public. Our future roadmap is public. All of that is open source and everything is open. You can sing that to the, the Lego theme song that my kids sing all the time. I couldn't write that without singing it in my head. Everything is open. So the other thing we want to do is open source that scales. I already mentioned the 4.3 billion download a month mark. But that's not really the kind of scale I'm talking about. Like that kind of scale is separate from open source. Like our approach to, we want our approach to open source to scale. Like we don't, we also want our, you know, the end product, the code to scale as well. And, you know, the registry to scale and all of that to scale. But we also want our, what we can do to support open source to scale. So when I joined the team about two years ago, we had a lot of issues around that. We had like a bunch of repos that like were maybe deprecated, maybe archived, maybe attached to packages that were deprecated. But the repo wasn't archived, stuff like that. A lot of mismatched expectations as far as like what was supported within our open source portfolio. And so we also want to really quickly be able to open source new things that we find helpful and valuable and be able to do stuff like that, publish new packages. We see ourselves as solving a lot of novel problems in the JavaScript ecosystem. So if we have a solution, we want to make sure we can open source it, we want to not just throw it over the wall, style open source. We want to make sure people can use it, we can support it. They can ask questions. We can take people's, we can collaborate on it. Like when we open source something, we absolutely always want to be able to collaborate on it with within the ecosystem because our style of open source is like we're not going to do everything perfectly, but we want to basically not have years long pull requests that are open. We went through Sember, INI, and I believe one other one and got them down to just a core set of pull requests that are still open, meaning like those open pull requests are things we are considering. Everything else has been closed or merged after like years long period of time that they were open. And so like I said, everything is open source. This is our status board, which is also open source. You can see the link in the corner to see the status board that also has on the status board. There's a link to the GitHub repo for it, but you shouldn't be able to read all this, but it's essentially just to show that everything that is open source we want to be able to measure and look at and support. So if something is not on this list, it means we're not necessarily tracking it. If you do find something that's not on this list that you use that is published by us or in our GitHub org, let me know, open an issue on it, tag me in it, and I add the NPM CLI topic to the repo and then that adds it to the status board. It runs once a day, pulls in all sorts of data so that we can see how green we are. I think currently, yes, some people here helped build it and helped have ideas for what we could use it for, because it used to be a lot more red than this. Actually, this amount of green is shockingly good, and this was also taken this morning. I did a bunch of extra screenshots this morning just to make sure all my data was up to date. So the other thing we want to do is, as I mentioned, share this open source. So open source is, by definition, open. We can share it with people, but I really mean collaborate and share it with people. So when we open source a solution, we want other people to use it. So the newest member of the NPM CLI family is NPM agent. I believe we did 1.0.0 in December, and then 1.1 is open right now with a bunch of new features. And this is a new HTTP agent that will be in the CLI that will allow for much more configurable timeouts, and stuff like that that the NPM CLI currently doesn't allow for. There's only one very not granular way to configure timeouts in the CLI currently. So this will help that, but this can also be used by anyone that needs an HTTP agent with configurable timeouts and stuff like that. So we are not just open sourcing stuff just for ourselves. We are the primary user of all of our stuff, but if we use it, we want to make sure that other people can use it, because that means it's easier for us to use it as well across that many repos that we have. Like there's still ones I think that I've probably not committed to yet in two years, and that just means that just goes to show how much stuff we do support. So there's repos of ours that I approach as a new contributor, sometimes even being on the team for two years. So as I mentioned, we want to be able to support all this open source. So it's a big area of responsibility that we have. And as I mentioned, there's a lot of things that can happen when you have a portfolio that big. My probably worst bug was when I published the CLI and manually published the dependencies that are part of it, the workspaces, and just missed the very last one. And since we bundle our dependencies, I didn't see it as a bug like in running my system, but then probably like overnight, we just got a flood of bug reports that you couldn't use Yarn anymore to install that version of NPM because they handle stuff slightly differently, as you might have noticed in Darcy's talk yesterday. And so that was a fun one to figure out why it was breaking in one system and not another. And this was kind of a time when we were like in a transition between automating some of this stuff and not. So I was like, you know, I know exactly how to publish the CLI. Like, let me just publish all these workspaces. And I'm pretty sure I just left one letter off like the very last command that I ran. And it didn't, I didn't look at that all the generated output at the end, just saw that most of them, you know, saw that there was green and that the CLI was working and all of our tests pass. But that was an interesting one. And that approach to open source, I think, doesn't scale. And we can't support that if like we're not running all of our code across a bunch of different systems. And so I consider that like open, if stuff like that is happening, we don't feel confident in, you know, supporting that much open source. So, or we want to deprecate it. We want to support it or we want to deprecate it. As I mentioned, I think in the last like six months we've gone down a bunch of repos. And Isaac, the original creator of MPM, took a bunch back stuff that was like no tar. Darcy, what was the other one? Yeah. What? Yeah, yeah, it all got passed by by legal. So this was a case where, you know, I, if you're not familiar with the, you know, the details of the MPM CLI, that's okay. It's not super important, but you know, it makes heavy use of tar balls and tarring and untarring stuff and streaming tar and stuff like that. And we are not the Isaac, the original maintainer. He's the expert in tar. And so we make heavy use of it, but we weren't supporting it to our, the level that we wanted to like people were coming to us with bug reports. And I remember looking at the repo and saying like, you know, someone had a one line fix to make it work and like node 18 and node 18 was just released. And our whole test suite pass, but I wasn't 100% confident that that one line of code, you know, it was just making something wait slightly longer in an async setting. And so I wasn't as a not the subject matter expert in tar. I wasn't super confident in merging that so that bug, that PR set open for a long time and that's not the level of open source support we want. We want people to be able to, you know, have confidence in giving us pull requests that we are going to merge them or close them with good reason, not just let them sit open and say like, I don't feel confident merging this. So we want to give stuff away. You know, we want to make that status board smaller, eventually fit on one one slide. Hopefully, I could not get it to fit on one slide, even like shrinking everything as much as possible as I could in my browser. So this happened again recently with our CI detect module. That package I'm not sure if anyone's familiar with that but it's essentially just looks at a bunch of environment variables and tells you whether or not you're in a CI environment. And so someone opened this and said, hey, can you document like what the maintenance status of this is. And we had actually switched in the CLI to a different better in my opinion, and all of our opinions package do CI detection. Developed by it's in the Watson GitHub or so I'm not sure exactly what company is responsible for it, or what maintainers are responsible for it, but it was just a lot better to us and was keeping track of. By definition, I think CI detection is like something that's constantly moving and constantly changing you have to stay up on pull requests. If you want to be, you know, have the best possible package there and so ours had a bunch of open pull requests. There's had been merging stuff like that. So we just switched to it in the CLI. But what we forgot to do was archive this report deprecate this package. So this person came by the repo and asked the question I responded and said like, you know, yep, this completely fell through the cracks. Sorry about that. We didn't. That's not this is this wasn't part of our process at the time of like if we stopped using something what happens to it is now where it will actually bubble up on status board. If you either deprecate the package or archive the repo and just remind you to do the other one as well, but it's not a. I consider it like really lucky when when people come by and ask us questions like this because the alternative for every one person that asks this question there's I don't know 100 1000 that are looking at the repo and just saying like this is really frustrating. I can't tell if this is used or not if this is maintained I don't want to use this you know how can I figure this out so we want that to be like a binary question of looking at our open source portfolio is like is it maintained. Yes, if it's not you get the big archived GitHub bar at the top of the repo and if you go to the npm package you get the big deprecated up at the top with hopefully a good error message for what to do in this case it tells you to go install the version of CI detect, I believe no ours was called CI detect the new one is called CI info which just tells you to go install CI info instead so I see that as a really positive outcome for our how we support open source giving either giving stuff away or deprecating it. I want I love deprecating I love deleting code getting rid of code so that kind of leads into the next thing of like we want to do open source that inspires confidence across our users. So, yeah, you should immediately be able to tell from our repos whether it's supported or not and the answer should always be yes unless it's very very obvious that it's not. And that also means, I think confidence goes a lot to, we were able to build confidence by making everything look the same if it is supported. So, there's no, there's currently no levels of support it like I mentioned it's a binder we had discussed internally whether we wanted to have like some other level of support which indicated like we aren't accepting pull requests for this we but we are maintaining it we will publish new versions. And we found that was probably just going to be more work for us to like maintain a whole different level of support. As far as like with a small team. So, we just have decided to either deprecate or give something away or like fully support it meaning we're committed to keeping it up to date. Kind of with that whole list I showed at the beginning we're committed to releasing it, fixing security vulnerabilities, keeping it up to date with any latest versions of node. There was a current change in node 20 that changed how the exit code was basically whether it was undefined or I can't remember all the details someone else on the team ended up triaging it but we fixed a bunch of our repo so the test would pass. Once we started testing in node nightly at that point so that was another really positive outcome of like since we support everything and test everything across our full matrix we were able to be like okay this change needs to be made and then let's make it across all of our repos. And so with a large open source portfolio it is inevitable that things will fall through the cracks. It's not possible. It's not probable like it will happen all the things I've described so far like those are just the times I've personally been responsible for things falling through the cracks. And so with a team of multiple people that can happen a bunch of a bunch of different times so we another one I can think of is the time like we've also had to abort a bunch of CLI releases when we try to do weekly releases for a while we were just in a cadence of. Hitting a bunch of CI issues or like differences across machines that were not scalable and just having to abort unreleases until we could like figure out what was going on because we the last thing we want to do is release something that decreases user confidence of like have a bunch of. Flaky releases in a row that like have some simple bugs that we're not catching because like we're not fully running CI or we're not confident in our CI. And so that's how do we do that. I just said a bunch of words about like what we want to do and I think I use the word like everywhere everything all the time like those are a bunch of like very absolute terms that are. Difficult to do in practice. And so I've always wanted to come up with an acronym really badly and have it like become a thing so hopefully next year someone gives a talk about P PAP is what I'm calling it. Feel free to like you know rearrange those letters or come up with better synonyms and tap the taps already a thing. Tap tap. So like I said, I've always wanted to come up with one which is why I probably never have and never will because I'm like really bad at naming things but for the purpose of this talk and the purpose of coming up with terms that I could put on slides. Last minute patterns process automation and tooling are the four umbrellas that I came up with of how we accomplish what we do so far. So, but yeah, just feel free to tweet at me or to that me with with better acronyms. So the first pattern is make everything the same or MPX at the same. We use make for a long time in the CLI. Now we just kind of dog food the CLI with itself and with npm itself to run a lot of our commands to keep everything the same but there was like a lot of as I mentioned before there's still repos that I haven't committed to so there's a lot of power in it's really powerful to like clone a repo you've never been in before and have it feel familiar. And so some examples of that are like even really small things like everything goes in a lib directory or a bin directory. And we don't allow files anywhere else in our repos, unless they've, you know, there's ability to whitelist or have an allow list of stuff. But in general, like there's just one place you're going to look for the entry point to a package or just any any of the source code for a package for that matter. And just the same linting the same formatting, same CI workflows, all the CI workflows in every repo are named the same thing. So if you are running, you know, the same if you want to check the action for something across two different repos, you can use a well known URL, you know, well known GH CLI command if you want to to get the output of those logs for two different repos because everything's named the same. And same with, we've had a lot of success with our change logs these days, which used to be non existent and a lot of repos. Someone gave a talk yesterday about an annoying trend of projects having no change log. And we did that. But now, now we have change logs everywhere and they're named the same thing in the same spot in the repo have the same headers. If you, you know, I've even written, you know, one off tools that we use to like just parse our change logs because I know. And that was easy to do. I didn't need a markdown parse or anything because I know like, you know, we have one hash for the title to for the date, you know, three for the, the number of the release. So it's like really powerful to have all of that be exactly the same across a bunch of repos. So the next time I go clone something like I've been in Sember a lot recently, but they were probably like the first year I didn't do anything in Sember. And then when I first pulled it down for the first time, it was wildly different than any of our other repos. Sember is kind of like the behemoth. It gets around 1 billion of those 4 billion downloads a month. So like a quarter of our downloads are just from Sember. So we take a lot of care with changes we make in that repo. Jordan has dissuaded me from some changes I wanted to make because I didn't realize like that they were breaking changes. And when something is used, downloaded a billion times a month, like everything is a breaking change by the strictest definition we found. And again, we've been lucky enough that users told us that when I accidentally dropped node, an odd number, maybe like node 13 support accidentally out of the engines field and like the next day there were issues open saying this started throwing in CI because it doesn't support node 13 anymore. And I was like, that's an odd version well past end of life anyways, but like, you know, we did a patch that day to, you know, fix it so those users wouldn't have failing CI anymore. So, but that was just another example of when things were different, it made it much more difficult to make those changes. And obviously not everything can be the same because, you know, we need different source code in our libraries we need a bunch of different stuff. And so when we do have differences we try to reduce them or abstract them to the smallest possible surface area so we have configs and a bunch of our packages and repos that will do things like switch it between CGS and ESM. So we, you know, always, we still publish common JS for everything, but we have a few like internal tools or like leaf packages that are just that we can use ESM with because, you know, I think there were some dependencies I wanted to pull in. And it's nice for like CLI tools if you're not expecting someone else to consume it like things that we just publish as like other separate tools. And so we have a config in our packages that can just switch between those two modes and make sure that like your linting files get named correctly your that we lint that your file extensions are correct like that we use MJS for ESM and stuff like that things that are going to be different across projects but you don't have to remember you only have to remember to change that in one place in this project. And if you forget to like you're just going to, you know, all linting and all tests are going to blow up until you just switch that so it's very discoverable that you need to change that config you won't be able to get very far without it. And we are currently have an internal plan to adopt formatting across all repos. One thing that we found difficult is during in reviewing community pull requests, there's like a lot of back and forth about formatting. We don't want anyone to have to worry about that especially when contributing. We've also found a big trend of like people that just use the GitHub UI like the dot you press dot on a repo you get to the dot dev, and they'll commit like typo fixes in our docs or just like typo fixes and comments, and they're not running any sort of linting or CI or have like, you know, a super robust. It is VS code in the browser, but like maybe they don't have VS code, they're not going to go through a bunch of time to set up extension sync and have like a really robust dev environment there. And so we found people do that and then we'll have to pull down their pull request and update it for them which is work that we're happy to do because we're enabling contributors but there's tooling that can help with that including like prettier and adopting that so like if someone has a line that's too long it just see I will just fix that for them. And we're experimenting with ways that like the pull request can detect whether the red you know if the pull request is in a red state it can detect if it's a linting problem and then you know the GitHub action the robot can fix it for us and push to that pull request without manual and with all with also without dissuading contributors because we've definitely been very guilty of that in the past of leaving contributors on red, I believe as the kids say, where, you know, someone will have a really good change and we're just not able to get to it and it doesn't filter up as high in our notifications because it's a red, you know, CI is red and we're just, you know, you know it's going to be a bunch of work to go in and manually fix someone's pull request, which is, you know, we don't want to close because we do, you know, value that contribution but so far it's been difficult to do those without like these patterns I've been mentioning. So here's an example of Semver where it has different engines and CI versions. So currently we support the late all the LTS versions for 141618 and then anything above 18 so like including 1819 and 20 but Semver supports everything above 10 and that means we want to test in all in a bunch of new stuff as well so this is just a config setting that changes Semver to test and more stuff and provide more node support for more versions because we didn't want to do a breaking change when something's downloaded a billion times a month. Breaking changes are are much more expensive as far as adoption goes like we can look at the download counts for old patch versions and old majors and see that like, you know, there's still hundreds of millions of downloads a month on old majors because you know projects that are being updated so we don't want to do majors for like really expensive majors when when we don't have to. So another thing we wanted to do is make adopting new patterns automatic like I mentioned prettier if we want that to be something across all our repos. That's just a robot wrote like a, you know, prettier itself is just writing all of our files since they're all in the same place. And we're confident of like the standardization across all our repos, we can make that automatic like we don't even have to have any manual step to adopt prettier across all of our repos. So we recently did that with auto publish. So using granular access tokens. We're now auto publishing a bunch of CLI dependencies not the CLI itself yet we consider that one still like, you know, we it's it's good that it's manual. We don't want to accidentally publish the CLI but all of our dependencies. Now, as we update them they get auto publish for free because that was just a GitHub workflow that has like this was the default basically to get added to our template or templating repo. And then it's across all repos that want it and like I mentioned before we abstracted that down to publish true as the config so if you have published true to our templating config the repo gets that because there are still some like Sember also actually no we did do Sember once we felt confident with the approach across a bunch of other repos Sembers now auto publish as well so that was a big deal. And then there are always going to be new patterns that are time intensive to do so we want to make those visible and measurable for our team. So, an example of this is coming up with the standardization approach was like a very time intensive task we had to do it across all of our repos one by one essentially manually because that was work that I don't know chat GBT wasn't up to it at the time. I haven't asked chat GBT for yet to do it for me but I'm still you know I'm still skeptical that it could that could do this if it can then you know maybe I can take a break. Another one we want to do is we haven't had time to support types for all of our packages so we've been steering people towards definitely typed and as great of a community resource as that is we still find that we get bug reports and unhappy users when we we follow Sember so like even if we're publishing something that only we primarily use if we're removing an API or doing something like that we are updating a major version and then types are slow to follow. And then if a users happens to be using that in a project they will you know get the wrong types and and have a poor experience because you know I use VS code daily especially within VS code because it's just giving me a tell intelligence based on those types so we want to start publishing our own types but we are again like a lot of manual work that needs to be validated first so we are approach to that is kind of to add it to our status board as a new column. And so this is a poor crust from last year where I removed the templating column from our status board could we actually finally templated everything which meant we were confident in the node version it was at and a few other things so I got to remove all those columns from our status board because we no longer needed needed to track those things so kind of like as our status board gets more green we're able to drop columns and then add new red columns to force us to do more work. But it's good work and you know it's it's easy to make sure that we're doing it the right way because we'll validate the approach in one project and then make sure it scales and then we'll be able to track it here so it was a really nice approach and you know it's a nice at the end of the stick for like going to this and seeing like one by one year you're making stuff green for a while I would go to it every morning because it's a CI it's a CI job that runs overnight so like I'd go to it in the morning, make sure that there wasn't any new. We also run a bunch of CI overnight to like check for new security vulnerabilities or even that like our tests aren't breaking due to transitive depths. See Darcy's talk for what a transitive depth is. But you know to check to check all those CI runs but then also see like you know teammates were going and doing repos one by one so we get to see you can sort the status board by color so you can say like show me you know sort by red at the top and just see that number go down was like a really good feeling and then dropping those columns was the best feeling because it's like we don't this is not something we need to track anymore we we did it let's you know track something else. And also we want to make make our process. Rotatable. So we have everyone go see our you know everyone takes turns doing all these processes. So you'll never be like blindsided by a brand new process that you've never seen before it's all incremental and you're free to like update the process while you're responsible for it and so you know it's kind of like a fun surprise. But you know it's all documented so the next time for a while like our release process was being overhauled like pretty much every person that worked on it so you'd get a new. A new like new documentation or what to do every time you ran the release but it was all clear because we standardized it so we also want to make all these process changes transparent so we use. GitHub wiki to kind of store playbooks for this stuff and the one thing I want to highlight here is our release process is 222 revisions. And so we keep we keep them in that we like the GitHub wiki for this because like we don't want to force us to review these pull requests they're just things that are. Someone can do but it's it's nice to have this audit log for it essentially. And we also want these processes to be discoverable so as I mentioned this is the our current release process and it opens a pull request for you and gives you checkboxes and each command that you should copy and paste in your to your terminal and run. And this and it auto it replaces anything that's really specific and so you really just copy and paste and as for the question is like why can't a machine do this and like for the ones we auto publish a machine now can do it but we consider the CLI. To big of a target where like we don't want to mess up or like have a process bug that we haven't thought about before like run amok and have you know. Our release process become sentient or something in the CLI releases itself a billion times and eats all of our. CI I don't know it's been a while since I saw Terminator. So the next is automation we want to have automation that we can kind of tweak and configure over time so this is the current list of all of our config automations and hopefully this is. These tools are not prescriptive kind of everything in the first half of the talk like those are the general my general thoughts about open source and like kind of the themes of this and all this is is I mean it's open source I don't know if I mentioned that yet. You can go look at this adopt you know decide to adopt this for your team or not. It's currently very like fork friendly open source which means like you could fork it and use it and we can collaborate on it if you want like there's a thing in the bottom of the repo for our tooling that says like this works for us. If it works for you if it doesn't work for you let us know. I believe I'm pretty much at time but we have one more tool I wanted to show off is our templating tool. And so this is kind of like the path to profit with our templating tool which just means that it updates itself so we use template OSS to tell depend about to watch for updates to template OSS so depend about can apply template OSS updates. That I tried to make a graph for that and I just yeah yeah no it's it's it's a it's a snake eating its tail but in a good way. So this screenshot is our post depend about workflow that template OSS writes to repos and then depend about runs and then the very last line of it you can see it runs template OSS apply so we're in a constant state of getting all of our own updates. So here's one just for a single repo that updated it from 14 to 15 and then here's the rest that need to be merged. So like this is how many pull requested opened again hopefully one day I can fit this on one slide like it keeps going down but I couldn't. And so the last thing I wanted to mention is just a quick plug for making your own tools and having a common set of tools. So we currently have you need node and the GH CLI and that's it to run stuff no one installs them like this but this was like the easiest copy and paste way to install them without being with being as prescriptive as non prescriptive as possible. So every you're free to have your own opinions on how to install these things but as long as you have them you can run our tools. And so we also have staff tools again open source fork friendly feel free to go through the repo see anything you find if interesting. Wes in case there's like people that want to do Holly repo plus monorepo configuration solutions this will be the the place to look. And so this is just a bunch of screenshots of everything you can do with our staff tools that we wrote just as as needed. So this was just kind of ad hoc as needed stuff and these are all the places you can contact me if you have a blue sky invite. Let me know. Thank you so much. No. No time for questions but feel free to grab me in the hall about anything. Oh yeah Darcy had we had two thousand two hundred and three releases over one hundred thirty main maintained project and dependencies for average of twelve point five releases a week. So this was at December. I believe that was for all of twenty twenty two we average twelve twelve and a half releases a week for a year. Yeah we ship so let's collaborate on all this open source. As I said it's either it's all supported if it looks unsupported yell at me like tag me by name in repose please and let's collaborate and open source and we also have we need more people to help us do this now. So if this sounds interesting to you that URL will have some open job postings next week or feel free to come come at me as well. Come at me.