Hello, everybody, Welcome to another thrilling episode of JavaScript Jabber. I am Steve Edwards, the host with the face for radio and the voice for being of mine. But I'm still your host. I'm flying solo today on the panel. Dan is on vacation. Chuck has this name thing called work, you know that gets in the way of the podcast, And so you're suck with me today. But a very special gift, mister Anton stoychef, how are you doing? Anton?
Pretty good? It pretty good? Thank you good?
It's uh oh yeah. I forgot to give weather update. The great here in Portland. The summer has been awesome up until this week, and starting yesterday the rain came in, so it sucks. I miss my sunshine. And Dan always gives his update about how it's hot and dry and Tel Aviv, and I'm so jealous.
I have these kind of updates very much often. I work with Esa ellis in there constantly. I was a nice day at the beach. It was a fantastic day today. The water was perfect and it was a freezing kind.
Of over here right right, So before we get started, why don't you just give us the background on who you are, what you do where you work, why people should give you money, etcetera.
Absolutely, so again thank you for introducing me, Amanton. I am currently working at Joppo as a core platform team in front time Infrastructure officially name right, so it's a team serving the whole company and other developers within it. I've been doing this kind of thing front time JavaScript whatever you want to call it, like JavaScript on a spectors let's call it. Even touched in the good old days a PHP kind of a templating world, the websites and web press and ages ago boy, yes, like I
don't know, twenty years ago or something like this. I'm not sure. So from is support until today kind of the world. That's me And I've naturally had like the design or interest into the nitty gritty stuff front end, How do we get there? How does the production work? Like what do we do to make it super fast? But how does that piece work? How do CD ends work? And I kind of naturally ended up doing this kind of thing, which is built optimizations, tooling, optimizing the tools,
making sure they work, and making sure upgrades work. How do we release? How do we upgrade? And this is the sort of thing that the team does. Of course, alongside core stuff like design system. I think most companies have that, like a core team, Like most largish companies have that, like a core team that kind of serves the rest of the company and tries to make the developer experience either better, faster, whatever you want to call it.
That well, I guess that depends on the size of the company.
Sure, sure, sure sure.
My previous place, I was on developer team, and I was also doing a lot of the core stuff and you know, tools and infrastructure to you sort of the many hats type of things. So I suppose when you get to a larger company and you can have a separate team just for that versus you know, the developers itself, and that would be nice.
This is like a natural revolution. I think in previous company, I was like, ah, but who who is responssible for that? Okay, I will be the responsible person for that. So it naturally evolved finally finding a place that has attention to detail enough to like and kind of treasures and have maybe legacy enough to pay attention to, like, Okay, we need that team to kind of improve the situation. That's usually what I think what happens like or from the
beginning somewhere. They already experienced that in a previous place, so they set it up from the core from the get go.
Yeah, so let's go back real quick. So you mentioned PHP. I came a bit very similar to you. Oh, he started with PHP and I still do a lot of PHP with Laravelle okay, which I love to work with La Belle and you and a nurse.
By the way, I was one of the first few people like a lot of version. I don't know how much, like zero points something. It was, Yeah, it was. I think it grew explosively, like I did not expect lave to become such a I remember the days of zend framework and yes and the such I don't know, like, well, Ei, there's.
A let's see. I remember nuke PHP okay, kke php, which is still around PHP nuke pH what that was? I did some of my first websites. I just didn't plane PHP.
No SAM SAM framework, no templating, just like combining HTMLA oh god.
Well then you're talking about the templating. That just brings back nightmares because I was at a few years ago, the last the last couple of years that I was in the droupile world. So I lived in the droupile world for you know, from the That was what first got me in well developments druple because I got tired of writing my own thing like many people, and so I found the CMS and I lived in that world
professionally up until probably about twenty ninety. But I was at a very huge, large multinational corporation and we were converting an old website based on Microsoft Server two thousand and classic ASP, not SP don that Classic ASP to Druple seven with the patch and solar and some other things.
But they had decided, because of the whole fear about SEO and jobascript frameworks back in the day, to stick with jupo on the front end and the built in PHP template at the time, and I got tasked with caching and I still have nightmares about that to this day. About cashing with PHP templating, I mean, cashing.
On its own, even if you don't combine it with like a CMS, is a mess because it only takes one person to just forget something or like not to have like guardrails and do something wrong and then you get the productionich right.
Well, you know they say that the two hardest things in computer programming are naming things cash and validation off by one by one errors, you know. So so yeah, I can. I can botch that anyway I can. And then you talk about it six and I can remember, you know, designers would literally charge extra because they had to accommodate for I E. Six abnormalities in their CSS.
Oh yeah.
And then when it finally died, it was at a Drupal con in New Orleans in like twenty thirteen twenty fourteen, literally had a parade celebrating the death of eighty six and micro Microsoft finally said, Okay, we're not supporting it anymore.
But the next thing was I E. Eleven. Like that was like a you know, like there was a phases of I E. That people were like dreadful about.
Yeah, until you got to edgyum, you know, or you know that's whatever you call the when they finally changed engines.
Yeah, chromium based eight.
Yeah. So yeah, yeah, it sounds like we've been through some of the same same wars.
I think it's kind of like edge based edge based, So once you start web development early on, you can't even inevitably going through these trenches, which I find to be super helpful, Like I love to have gone through this. I like, I don't think of them like, oh, wasted my life or something like this. I think I've gained super useful knowledge even for today's work, where like asking AI, like, oh can you do this for me? Yes? Thanks?
Right, Remember the days of figuring it out?
I mean they're not gone. I can I can spend like two days talking about my day to day configuring CD and stuff and like going through documentation, asking KI together with me and not being able to figure out stuff. So I mean it's not gone, It's still there, right.
I had one of my favorite interviews I did on another podcast, Views on Views with Taylor well Blaara Bell, and he was asking us about our thoughts on where Larravelle should go in terms of just focusing on PHP back end or focusing on the front end framework. And we talked about the pendulum switch, where you know, when you and I started, you learned from the back end.
You started with a lampstack and you had to know the back end and stuff, and then you learn the jobscript in front of that, and then you've got to today where a lot of people get into well web development from the front end from the job script frameworks you know, Angular, use Felt, React React predominantly just because it's so dominant anymore. And then they don't know the back end. So now they got to learn the back end,
and how do you know, accommodate for that? So it's real it's been an interesting pendulum watching the pendulums when back and forth. For sure.
Yeah, I mean I'm just thinking ancessary at the moment because this is like my daily driver the last few months.
But anyway, yeah, yes, sorry, okay, So let's get into what we're here to talk about. Then, So you worked for the companies, how do you say? Yeah?
Yeah, yeah, it's like Israeli a US company you PO, so that they're kind of big in the e commerce, right y O.
T p O. In case you're you're you're looking for dot com?
Yeah cool, yes, in there we open source something a few months ago and it is something we use actually internally to manage let's say the migrain of upgrading or maintaining tool link working and let's say up to date. Uh. And of course have quality quality gates some people call them code checks. Usually you can see them on things like GitHub on your prs and basically guarding you and helping you by the way, especially in the AI world where someone needs to put the brakes on on some
of the code or let's get generated. So it's kind of a double important to have some code checks. Of course, you can wing it aka vibe and just see what's up. And then I don't know, I ask another AI to maybe refractory, Sure, but I.
Think refactor ais are you?
I think so? I think maybe there is a future where we don't care about quality. We just use the model as of today, and then think about two years in the future, the model will be better, so they will generate something better and we ask them to just improve the code base. You know, there is a world maybe.
Well. The problem with that, though, is the AI is training itself on the old stuff.
Yes, yes, yes, yes, on itself maybe. Yeah. So we wanted to kind of enforce this and do this in a company that has been around for more than ten years. And I think it's natural if you have projects for more than ten years or even five years, that you kind of accumulate legacy. And I maybe in this podcast you talked about it, and maybe I've read it somewhere,
but legacy is not naturally a bad thing. Legacy means you have something working right, true, but this thing that is working is no longer performance, is no longer maintainable. The tools that you use can no longer work with it. If you want to upgrade one tool, you're kind of stuck in this Nightmarrey scenario where you're like, oh, I need to upgrade my e is lint. It's not connected to my code. I want upgrade it, but the new version requires a new version of no JS. Oh okay,
So I need to upgrade no JS. Oh okay. Then I need to pay all my other packages because they also need they need to be compatible with a new version. So there's a vicious cycle of upgrades, basically because everything kind of depends on each other and they're all grouped
into one thing. Even though if you think about it, most of the things that are not really connected to each other, like es lint doesn't use your built stuff like things like es lint, like code checks, yeah, unit testing, it doesn't use your actual built unless you were talking about VAT and v test, which kind of shares the
same build mechanism. But let's let's say we're talking about web pack or turbo pack, uh, and just they do their own thing, like unit tests are built differently than the web back, so they actually live in total isolation, like into two different universes where just do this its own thing with your source code, and then web back or whatever tool you choose do their thing with your
source code. So in theory they are absolutely isolated. But for historic reasons, we kind of put them in the same package, put them in the same bag of dependencies, like, oh, let's put web back, let's put just let's put the way Yeah, go ahead, Wait a minute.
Those are two different things, though, I mean web Pack and just you're doing two different things, just as you're you know, you're unit testing, your code testing, right, Webpack is more concerned with the bundling.
And absolutely and absolutely taking apart.
So I guess I'm confused as to I mean, it's like you're complaining two different things there, I.
Know, And I think this is where I haven't explained it probably well to have been more clear, but this is my point. There are absolutely two different things. They have two different purposes and they have like two different universes of building. I think we're on the same page here, right, Like web Pack doing is own thing and just but
what do you usually do? You have one package jacent, and all of the gest related stuff and all of the web pack related stuff they live in the same package jacent, aka in the same bag of dependencies called the giant node modules, right like you you kind of combine them together. And there's a weird scenario where let's say you have you found a bug and it's a really nasty bug in jest. That just a scenario. It could be any other too, right, it could be slaint.
It could be let's say, even an end to end testing tool. Right, but you found a problem and in one of great the two only like you don't want to deal right now. You have other priorities, right, you have to do a new future or do some actual product work. But you want to fix this bug. And the bug is fixed in the new version of jest. Okay, is how I get ingested. This is about ingest itself, ingest itself absolutely clarify. But you found it. Oh wait, in three versions in the future, this bug is no
longer there. It's fixed. So your options here is like, Okay, I can maybe live with this bug and document it very well and just try to stay away from it or try to upgrade JEST. And this is where I'm trying to say, there is an actual problem for me. It might have. It's like a dependency management. If everything lives in the same bag and you want to upgrade EST, just we'll tell you. Wait, you want to upgrade from version I don't know five to version eight. Okay, but
I need a new note dress. I need no Dress twenty seven, let's say twenty four. Okay, this is I think the LTS version twenty four. But then when back will tell you, hey, okay, you're graded JEST and no Jess, but I'm not working with this no Jazz version like sorry, no, or even worse, you build two links like let's say you're not a React world, you're Angular world or something else. Most of those even React nowadays with the React compiler or something was code. They actually have a thing that
runs together with your build. An Angular whole thing is that they actually control the build. They have a compiler, Anglar compiler, right, So imagine this also tells you, hey, I also don't work with the new no Jess. Figure something out, figure something out. I am not going to work with this version. And then you end up okay, so I need to upgrade. Also, not only just I only wanted to jest. I only wanted to cread this thing because there was a bug. But now suddenly I
need to upgrade the entire framework. And guess what, when you great the entire framework, you need to refractor all your code because there's probably breaking changes. Right, You're probably a grade two versions in the future. So now you end up in this situation where are you either Oh, I cannot upgrade. I'm stuck. I have to live with whatever I have today, or you have to upgrade everything, like you have to upgrade all your tools, all your
framework related stuff, all your run time dependencies. Maybe maybe not, but let's let's say framework at least, right and refractor. So I'm not sure about you, but I find that very kind of a scary moment because this is what defines kind of the depth of a code base. You're you're kind of stuck and you cannot upgrade it. It's too much work to upgrade it, or it's it's kind of an equal to a rewrite, because you have to upgrade like ten versions in the future or five versions
in the future. So the effort of upgrading is almost equal to the effect of like let's start something new, something small, as something performant, and let's gradually release it.
Well, I guess it depends on the size of your project. I mean it's a lot of project. Yeah, you know, larger project that's not even a possibility. You know, you gotta do what you gotta do.
Yeah.
I ran it out with Lara Bell you know, on the back and just because I was tasked with upgrading from Larra Belt eleven to Laravelt twelve and my boss was like, day one, Larrabelle twelve is up, let's do it. I'm like, okay, I'm running into all kinds of dependency issues for the dependencies have not upgraded to, you know, to be able to handle Laaravelt twelve. And so you're either looking at patches or you're waiting or I'm nothing.
By the way, I'm not sure if it's somebody's watching listen, but I'm heavily noting here because this is it.
You can't upgrade.
You're kind of in a moment of shit. Oh I'm sorry, but like I can't move. I'm stuck with whatever I have, so I need to make it work or start a new thing. But as you said, you can't start a new thing every time you get stuck, right, Okay, So I'm gonna offer an alternative to this world it were talked about the typical scenario where all of your bag of dependencies you can put in any language here by the way, like Laravel, like it's all the dependencies, Python
with all the dependencies. But here the open source that I'm talking about breakproof dot depth, which is just a gidab repositor readirects there basically offer the following concept. Okay, in the JavaScript ward and the JavaScript world of dependencies, right, what we are used to is this bag of dependencies not modus. Okay, but what if we can isolate each tool with its own dependencies and its own node jazz version, separate from the everything else but still be able to
work together. Okay. So let's say typescript or Jest has its own list of just plugins, just configuration, right, and specific note version, and I can only upgrade the note version for Jest, and I can only upgrade the Jest dependencies, and this does not affect the node version for any of me any of the other dependencies that are heavy my project no matter whatever they are. How does that sound?
I can already I already have a few questions running through my head here about how you go that, But I'm hereous well, I mean, just obviously do you want does that mean you have multiple note versions running concurrently somehow or how do you you know? You're saying, Okay, I can upgrade this dependency from this version not to twenty four. Maybe this one still has to be in twenty two for instance. How you recofy that? But I'm assuming you'll get to that.
Absolutely it did, But I think this is useful, Like if this is your first question, super vialent question, by the way, and there is an answer as you as you guessed, yes, this means multiple no jailed versions, right, and maybe immediately you have an interfere of like oh my god, like I have to maintain multiple versions of no jenis right, But maybe you can actually limit that, like don't you don't need to have all the versions of notices. You don't need to have like fourteen, sixteen, eighteen,
twenty twenty two, twenty four. You can have like a white list you have like, okay, I support this twenty twenty eight. That's it, Like three white listed ones, right, And this is where we come into the repository. Why is this open source, like I reposed, this is just a template for repository. And something we mentioned before we started recording is mono ripples, right, And there are many
tools for mono ripples as a whole. Like if you start like research for mono repols, everything will come up, like there's RUSH, there's NX, there's turbo ripple, I think, and all of them are kind of helping you with mono ripples. And we went through them with the team, and there was one that kind of popped up which is actually alternative to NPM, and it's called PMPM. It is popular, like, oh, this is I discovered VMPM. Let me tell you about it. No, I know, I know,
it's kind of popular. It Actually many people don't realize or at least I found many developers I work with not. Actually I realized that other tools like NX and other tools like to go pack under the hood, they actually use PMPM or they advise you to use PMPM, so they're an abstraction on top of PMPM. So you don't have to only learn the tool if you like it or like NX or turble pack, but you also kind of need to know PMPM because underneath this is what
it's working. Right, So if you get a problem or if you have a specific need, you kind of have to know it.
Well, isn't that sort of like in order to view you really sort of need to understand JavaScript, have PHP right, So right, real quick, real quick, before we got too far, can I always like to define terms for those who might not know. Can we define what a modo repo is and give us an example of working mono repo.
Absolutely, mono riple is a get other kind of repository. But I'm guessing nowadays git repository that is not holding only one project, but it actually have multiple projects in it, each isolated usually in its own directory, and each of them have their own set of dependencies defined. This is I would say, the definition of a mono repole. And you can work only in one of them, but they are in the same repository, so everything is kind of connected.
One of the perks may be one of the main perks of the mono repo that you can use other packages within the repo together without going to the whole process of let me publish that, let me update the versions on all the other packages, et ceter So you can directly kind of depend on other packages in the same repository. That is mono ripole in my mind.
Okay, okay, so if I so you could so far like a company you know, could have different applications, say they've got a view app versus angular app versus whatever. The developers can work in the same repo, but only on their projects and only impact. Yeah, I mean so when, so how does that work? So when you're creating a branch, right, let's say you create a feature branch for your particular project, you're creating a branch of the entire repo just working within your.
Yes, you're creating the ripple is one. So you're creating branches every time on the entire repo. But you can focus on your think, only on your think. And this is where tools like PMPM work come in. Because naturally MPM doesn't have this understanding, or it didn't have. I'm not sure. I haven't followed up to the latest and latest MPM. I'm not sure what it offers, but it didn't historically have the concept of multiple things in the same ripple right, like you have to go there each
individual kind of things. They cannot be connected like NPM doesn't have this concept of connected packages within the same repol, So you need other tools, and PMPM, I think is one of the few ones that are super successful. I think MPM has nowadays or for a few versions, something like workspaces, but I haven't fully explored that because PMPM is just so amazing at the things that it can do and performance compared to MPM that there's at least for some years that I've worked with PMPM, no point
of kind of switching. So PMPM is a much I would say faster and leaner and very kind of focused to and can allow you to be super strict in things in a monopeople. When I say strict, we can go into very much the depths of dependency management. But maybe I can pause here and let you maybe direct me or point me to some questions or directions that are interesting kind of.
I've always been curious what that first P stands for in pm PM.
I think it's performance. I am not one hundred percent here, don't like put me on record, but I think it's performing.
Yeah, I always have the important questions like that.
So yeah, that's that's kind of your responsibility.
So anyway, okay, so now we've established what a what a mono repo is, and what PM in pm PM is, so let's go forward. So what is it? What are you here to talk about? What is it that you're doing that is somehow enhancing this or what is this? Uh I'm sorry the break proof? Yes, do force in that environment?
Amazing? Thank you, Thank you for that kind of question. By the way, I adore the level of ability that you can break down something and you can kind of keep the conversation get clear and not like go to bike shedding or something like this. So thank you.
Oh yeah, yeah, I like to make it clear.
So yeah, we establish some backgrounds on PMPM and monory pools, and I kind of try to outline a problem that I see in the typical way of like putting dependencies in one big list of things that we do. By the way, in mono repos is the same thing. You can still have many packages, and this is what usually happens.
You have an application, let's say view. Let's use your example, and inside of you you have all of its dependencies and all of its tools, so it will contain just Yestlen, cypress, playwright, whatever you have, it will be there, right, Okay, So what is this breakthrough thing?
Right?
We wanted to try and escape this locking the thing that I kind of the concept that I offered. We wanted to be able to upgrade one tool, and we face so many situations, I mean so many is stuations where we wanted to just a break one tool like linked stage a little too. That helps us with running checks before get commited right or on get a pr We won't just oblive that.
Yeah, I think we use that on my project. So yeah, I know what you're talking about.
So we won't to agree that. But that required a new version of not just a new version. I'm like, oh no, we're stuck in the same thing, the same loop. So we we were looking for a tool and we actually talked with the maintainer of PMPM so don amazing guy.
It was.
It was an amazing call, and we kind of teased him with this concept like, hey, but what if what if we don't need Cyprus to be coupled with our other stuff. We don't need just to be coupled with our view stuff. Right, there are totally different concepts, like if you go back to our previous example web back and just they're totally different. Can I just be able to say I'm in a mono reple Package A is my application. This is why I run my viehw code
or React whatever. Right. But I had package B, and this package B is all my JEST stuff. This is where all my GEST configuration lives, all my plugins for jests. And what I want to I want to be able to do is any application like package A or package C. If it's another application, as you suggested, maybe I have a view and an angler app, right, or let's say I view and a reactor. I want both of them to share my configuration. I don't want to redo it.
I don't want to. I won't be able to just call jest, have some basic configuration that makes sense for our company or for this one repole, and just run it from package A and package C. So this package B, this magical JEST must be able to be isolated and must be callable from the other packages. Right, So package should be able to say, hey, I need GEST from package B, and package should do the same thing. Cool.
Let's say in a classic Mono Repo. No matter whether I use PMPM, you can you can structure these packages. Now there's two questions, right, how do I call one package from the other package? Like how do I call JEST from package B in the AD from package to package whatever? Right, So I'm not sure how other tools do it, and I don't think it's so popular as a thing, but PMPM allows you to filter out to query with a command line. Basically, you open the terminal
say PMPM and you can filter packages. So you can select one package and run a script from its package Jason, or run a dependency that it's installed in this package. Okay, So I can say PMPN filter my GEST package JEST, so that will run just from my package that has all my est stuff. Okay, So this means this allows basically to collest from these two other packages without installing JEST.
So my package with my view application doesn't have just install nothing, doesn't even know about just, but it can codest that is instelled from the other package. Now, probably the question here is like, okay, okay, why are we complicating things making this separation? And now this is the key here. This is because because PMPM. After we talk with Zutan did one feature, which is I think it's for me. It changed the game in terms of a
mono rip. They introduced the concept of runtime per package, and they in the latest versions, by the way, a few versions back ten something. I think it's now. They even allowed different than no Dress runtimes. So you can say, my package A will have no Jess fourteen. It's a legacy one, let's say Angler eleven. But my package B has all the all the latest React nineteen, like running some CLI that only runs on the newest no Dress.
And I can even have like a concept experimental app that runs on bun or other runtime and still live in the same ripple, and I can still manage all of their dependencies through the same PMPMCLI. Right, So back back to the original example. I know, very lengthy, I'm going to pose in a minute, I promise. Back in the original example, I have my view application and I have my gest related stuff in a separate package right in the mono report.
The MPM package. Is that a separate like a separate directory. Yes, separate directory.
Sorry, yes, let's simplify think, yes, two directories. One is my view application with all of its dependencies, and one is my GEST stuff a separate directory with all of his GET related dependencies inployees. Right. So the NPM with this feature what allowed us is the GET related stuff to be running at note twenty four while your application can run a newer or older note like the application meaning the build of the application.
Right.
So this means that I can run GEST. I can say from my application. I can say, hey, can you codeest from the other package, And what this will do is calle the other NOTEJAS that is associated with the JEST from my application and can run on my source code. This way, I can use the specific note that I know it works with jests from my application, that I know that it works with a different note all the same note, but let's put it in a different note.
This gives you the ability to absolutely freely a great jest. You can a great GEST and the only thing you need to do is make sure that the configuration doesn't break when you up great and that's it. You don't have to think about all the interconnected dependencies that it might bring in. You can have great in isolation. That is, let's say the largest change that this breakproof freepoint and template is promoting. It's not only that, and it's not like as you can see, it's not a major thing.
Everything comes in from PMPM. There's a lot of other goodies, let's say. But I think this is the highlight, like being able to upgrade individually.
I'm okay, So yeah, I got a lot of questions here. Being visual, it's hard to do this without actually looking at something.
But so where.
Do you so normally, you know, in any project, the way it's always worked is you have your node mantostrecture, right, which has all your different dependencies and their indpendencies and so on under your project route. So in your mono repost setup, then where do these separate versions of note actually get installed?
Yes?
Where is the physical locations of those?
Fantastic? Okay, so you have two direct directories, right, I know it's a very visual thing. It's a podcasts people some some people listen. So you have the two directories and you can just accept them as two absolutely individual projects. They have inside of them the note modules for their own note modules. But your question was more like where is the note dress? And maybe maybe the other question is who stous the o JISS like, how do how
does you get the nogs? I'm not sure if you have an innate understanding or maybe you already know the answer. But maybe people are used to have a manager for no JS versius like MBM very popular.
One version manager.
Yes, no version manager, it's a CLI too. I can say use this version, or I can set it up so that when I go to a certain project with automatically which is not okay. It can also install note versions can also uninstalled them like it manages no verse. Cool. But what happens in this PMPN world and now this is the other fantastic thing. PMPM is not a dependency
that lives under note right. It is written in JavaScript, but is it's bundled as a standalone CLI so it can work without a specific like that you don't have to have NOTE to be able to run PMPM. This is a huge difference from npm MPM is always bundled with a specific version of no JFS right right, Okay, cool,
So you have PMPM and it's a standalone thing. And the new feature is like addition to PMPM is that it can also manage no JAS versions, so it has like an MVM features, so it combines NPM and MVM together in one two. I'm saying combined because PMPM, in my mind, is a superset of MPM, which means it has all of the functionalities of MPM to be honest, even the same commands and underhood, basically it's kind of the same results, but also can manage no JAS versions.
And having that that new feature that a PMPM introduced after we talked to Zutan that allowed each package to define it. PPM reads a specific property in your package jason file. You have two directories and each have package jason file right, and each of them can specify a property that I think is called runtime environment and PMPM knows about this property, reads it and checks if there is an installed NOGS with this version. If it doesn't have,
it installs it for you automatically. You don't have to do anything, So even if you try to run something from a package that you don't have the OGS version four, it will install it for you. Of course you can pre install it, but it would do it for you if you haven't done this step. I hope that this gives a better idea like PMPM does it for you basically in a short answer, a PPM does it for you?
Okay, but again, where so is it like you have a separate package for each version of no. Twenty two, twenty three, twenty four, you know, whatever versions you're using. It is kind of report.
It is kind of the same as MVM. It has told them in your system, in your home directory, maybe if it stolls them somewhere. It just knows how to run them for each package. Basically, so if you have a package with just independencies, it knows that if you want to run stuff from there, it will use the installed no Jazz version with debt version. Sorry, the installted no jas with debt version.
Okay, so I would So in your packages there are two. There's save and then there's saved dev. Right, so there's the tools that you need just why you're developing, and there's the tools that the packages that need to be installed for your application actually run. Right, So you could have so to use examples we're using just as a testing utaility, so you only need that at development type.
So that would be a saved dev type property in your package that Jason absolutely say a CSS framework say tail wind, which is a real popular win, right, that's going to be a uh you've got to have that in your bundled job description in order for your application to work or at least to look decent. So can this handle can you have I'm trying to think how a word this? Could you have? You runtime packages that you need to actually run your application that aren't saved,
that use different versions of Node? Is that a non issue?
Give me a second too, kind of.
Actually an issue? Because notice is your runtime from when you're developing?
Yes, yes, if you're asking about runtime versus death time.
Yeah.
If if runtime is the browser, you don't you don't need to think about it.
Okay, Yeah, never mind, I just realized that as that.
And if you're talking about different tools, if you're talking about different tools, let's say just andy istlink, you can expand on the example and have a package for island. So the package with islint comes with its own no Jet version and all of it's plugins, right because it drags in it drags in a lot of plugins and they have their own dependencies, right, So maybe these dependencies are like a mismatch with your own dependencies if you store them at the same place.
Okay, Yeah, so I think I get to just so it's basically installing the different versions of no JAS on your system and then just referencing them from the packages as you need, but being.
Able to kind of use all the tools from one package that doesn't have them installed, so they don't they don't interfere with your dependencies, and they don't interfere with your no Jazz version. They have their own thing.
So now the other you touched on something here briefly that I wanted to ask about, and that's other run times. So you got Bun, You've got Dno, You've got other things. You don't necessarily have to use no JS as your as your run time. I think was it Phoenix? Was that another one that was supposed to be and then sort of diet on the vine.
You're you're now reaching my ability to like to know. But Dino, I know, Bun, I know, No, just that Phoenix, I'm not sure.
Anyway that yeah, I forget that one. I didn't know much about it anyway. The point is, does all of this, the PNPM and this report that you had, does that only worked in no j or can you support Bernardino or other run times as well.
Fantastic question. The latest one of the latest versions of PMPM allowed this new thing. They started with this concept after we talked Zotan. We talked about it, and they introduced no Jess only right, so you can have no eleven and twenty. But I think in the recent versions they change that. So they introduced the ability to choose Dino for one environment. No, so one package, one directory. This will run with Dino. So all your scripts, all
your stout dependencies, we will run through Dino. DINU will run them basically. Right, So you specified Dino and a version and another directory in another package. Jason, you specify no jess aversion I can, I can hear, can not commit to. How many run times does it support. I am not sure. I'm not sure how many of them they support, but I am sure I saw Dino, sure sure,
and I think I saw done. And I think these are the kind of I hope I don't offend anyone, but these are the major let's say, talk talking discussion points, et cetera kind of is run times. I'm sure there's others. There's probably edge run times that I don't know if they have, Like a you can install them, Like I know, cloud for has their own thing, my edge workers have their own thing. Versailles has a run time, but I'm
not sure if it's just no jaiz. So many jobscript runtimes, by the way, I'm not sure if they're all installable.
God of reminds me. I saw post on hacker News probably in the last month, and it was a history of JavaScript run times. Oh and the guy said it took probably like a year to just to write this article. Because I was like, oh, yeah, there's a few. Holy cow, it was crazy how far he back. I mean, just link after link after link, and I don't know if this is the one. I'll have to find it maybe, But I was like, holy cow, there's been a lot
of a lot of jobscript run times. Yeah. Here it is the many, many, many JavaScript run times of the last decade. And they'll do this as a pick anyway. So there's a lot, but we're just focusing on on these three kinds right now. Kind of yeah, yeah, okay, So you have this young po breakproof based mono repo m this is it's on GitHub Breakproof, dash base, dash
Mono repo under Poe Ltd. So how would this be implemented, or how is this something where you'd have to fire this up and build it, you know, from everything from the beginning, or can you implement it into say an existing modern repo, or how would you use this?
Okay? Also also fantastic question. I mean I think I should just pick your questions and put them as a list. How I start talking about this? Okay? So even by its name, I hope they'd give some clue about it. So it says base mon and go break break Yeah
it is, I mean, I mean breakthrough. Okay, Okay, Okay, Given given your status of dead jokes owner and king, I think you're you're kind of picking on the important thing is Yes, breakproof is the key is the king keyword, and it is because of specifically that it doesn't allow you to break one package just because you have great another. Right, That's that's where it all started from. This is where it started from. But base Mono reple it kind of gives the clue of how it's supposed to be intended
to be used. Right, So the giftab has this concept of template repositories. Not sure if you've seen it, but if you enter a template repository, It basically has a button say create from this template.
That makes sense, I mean that's just kindard template type.
Yeah.
Sure.
The one thing why is this not a template? It basically fits perfectly perfectly the case of a template repository. But what happens that it's not super known is that when you press great template repository, it blanks out the entire history of the ripo. So it basically commits all the files of the ripple as a new REPO with no history. Okay, so you have a blank new slate and you don't have all the previous changes, et cetera.
Okay, well, that can be good or bad.
I suppose exactly exactly. It could be good let's say size of the repole. You don't have to care about this stuff, right, But one of the let's say not so great stuff is that if you fork it instead of that, if you create your own base on the history, it's kind of easy to pull changes, right Like if you let's say you have a library and I want to do a PR with some feature or a book fix, usually what I do is fork it, do some changes in my own branch, and create a PR to your
own original repository. Right. And I can do that very easily because GIT knows about the history is their share. My fork has all of the history of your original repository, right and vice versa. If you update your original repository, I can pull in all the changes.
Right. So we picked you're talking about working the whole repel, not just a branch within a right, you fork the entire ripple.
You fork the entire repole. Usually it's the main branch, like you kind of copy the main branch only. So what is the what what is the major difference? Okay? So this is where I need to mention a bit more maybe about what the repository is. But the whole intended uses you kind of clone it. You clone it to your own repository and you start from there. Why why why do you use this as a new repository? Okay? And and you asked, how do I get my projects in it? Can I just plug it in my own
existing ripple? The answer here is no, you can't really plug it in yours. But what you can do is you important project from your existing ripple in here. We created some utilities like interactive CLI with like questions like where is your ripo? Where do you want it to be.
So when you clone the brakeproof based monitor reple and you get like this copy of it, you can then import the projects from elsewhere, so you can import them from other monor reples or other just repoles, and you put them as a package inside of your copy of the breakproof monitor rep That's the intended use. And I guess there's very much announce here of why is this
like this? And I should mention something, but I'm going to pose again here to let you pick the first questions if you already have.
Some, well, if we're talking about getting your project into this repot, no, I don't have any questions, but I do have some after that.
Okay, cool, So you have your own clone, right, you copy the repository with the ford it with the entire history. Next step you imported the project. You got it, So why do you have why do you need this step? Extra step and extra work of moving project?
Right?
So, so far we only talked about this PMP mobility of isolation. Okay, but what it gives you is this based moment ripple. Doesn't only have this concept, otherwise it wouldn't be a based moment ripple, right, it would be just a read me file. You can do that with PMPM do it yourself, good luck bye. What it comes in is with already some tools installed as isolated packages. Right, they're not installed for your package. You can create your own package with you, but there's already tools in it.
There are most of them. They're in a directory code Infra as we just go back there. Yeah, if you go back to our original conversation, there's like categories of packages. Right, there's something about the built, there's something about code checks, there's something about testing. So this is a kind of a tooling that you usually have in an application. So this ripple comes with some of those packages that are isolated when their own dependence in their own packages, and
they're all Jazz version already there. So what you are able to do is have your project already runs, linked, already run, just already configured with some base sensible configuration. It's not opinionated and you can change it, but it's centralized and it's already working. So this concept that we introduced in the beginning, it's a starter. It's a starter that you can use, so they are already working. A COO part is usually as we talked about scale of companies, right,
and scale of projects. When you have time projects, you kind of want to reuse and not repeat every single time and have one project with slightly different test configuration from the other, because you end up with this bug chasing where the result and the causation usually is like ah, it was fixed, but not in the other package, but
in the other one. Right, So you want to have something centralized as a base sensible configuration, and the repository comes with sensible configuration for just based, sensible conforation for yes, lim and different kind of tools that are not very known but kind of useful, like finding unused dependencies, finding dependencies that are not in stout but you kind of use them. All these kind of code checks. They have their own package. They're all no jazz and all based
configuration that your own package can just reference. Right. And of course, if you have your view application, let's we use the example and you want to extend you want to change some isline plug in, Sure you can do that because it only it only provides you with a base config. It just extends the base config and you just apply it with more configuration. You overwrite something, you disable a plugin enable a new one. This is just a base for you to play with and already isolated. Yes, Limp,
and I want to just mention one more thing. What is the coolest part for me personally? After this isolation? We talked about artists. You have your clone, you have your copy. Right in several months, you say, wait, a new version of ISLNT. I'm not sure if you dealt with upgrading Yearlint eight to yearly nine. But it wasn't a pleasant upgrade. I can tell you that it was not pleasant.
Speaking personal experience, I mean, yeah, I.
Mean Islant is amazing. I love Islint. I'm super thankful to I think, Josh. I mean I'm hoping. I'm hoping. I'm not getting this wrong. I love that and we use it extensively, but that grade was hard. So imagine if you have your clone and the base breakproof repository, keep on changing, right, and at some point the base repository upgraded. Ye is lint in itself and you want
also upgrade. What you can do instead of you upgrading it yourself in your clone is just pull the changes from the base without fearing that it will break anything. Because it's isolated, it doesn't affect your package. It only upgrades is link. It only upgrades no JS maybe for the is link, but it's very isolated. So now one of a sudden, suddenly just doing git pull from breakproof or whatever. Right, your get clone second origin, let's pull it.
You now suddenly have upgraded islink and that's it. You continue there without a major like, oh, let's figure out configuration now, et cetera, et cetera, et cetera. So you suddenly have a newer version, like even major version of island. We just want get poll. Okay, I'm gonna post here if it makes sense. If it doesn't, I guess my thought is.
You know what I'm trying to get my head around is you know you've got this when you pulled in your project. So going back to the example that we've been using, you know, it's just and or having different packages that ah that use different versions of node. You know, say, so where does that happen? At what point? Is that something you have to do manually where you split out your just to a separate directory in the mono repo.
Yes, and this is already split in the base. However, you can have other tools. You can have other tools if you have a CLI twol called Steve right, or you have a I know, I think if that it doesn't exist, go book it trademark right here. So if you if you want to, if you want to create a tool like this, yes, you have to create your own package. You have to define what the run time to run. And basically all other packages can call stiff from its own package, which will be run with the
specified run time. But for some tool which are kind of popular, let's put it in the web world, right. It doesn't have to be front end, but it's majorly This repository is kind of focused on the front ed side of the JavaScript rate, but it can be use alful, not just so it comes with some popular packages. I
wouldn't say that all of them are favorable. I know, for example, Cypress is kind of going out of favor for years now, and some of them are because simply we have legacy and as a company we need to kind of pay attention. Once we started using a big thing like Cypress to do our integration and to intest, we kind of want to keep going to a certain point.
So we have a package for Cypress for Jest for years, lind for even little things like DPDM that I mentioned that lesser known code checks for also build tools like web pack and other interesting cult checks by the way, and bi tools I mentioned. I think I mentioned likes con fixed as well. It's a it's another big topic, but there it's coming already there. So back to your question.
You don't have to create separate packages for the things that exist, but for any other new tool that you want to introduce, you can create one.
Okay, yeah, I think I'm gonna have to play with that at some point just to get my head around, head around and how it works. I certainly get the concept and it makes a lot of sense because yeah, I can speak from personal experience on version upgrades and version conflicts between different packages that they all depend on.
So and now I want to maybe, let's say, for see one possible question that we might get when I mentioned this, right, we mentioned these effortless upgrades. You just pull in the latest changes from breakthrough freeball because it's a separate trip which keeps evolving. Credit your loan is from the time that you cloned it from or like copying now you can then upgrade and you get all
the latest just yes, link typescripts or like the other tools. Now, maybe a question you have is like Buttanton, the new year is lint have a new algorithm and new rules and new maybe strictness. Right, maybe you even change the conflict, the base conflict right the time extending in my application?
What does that mean that my entire application now will like shout at me with red squiggles everywhere, right, Like, I mean you only mentioned what is upgrading is lint as its own thing, but what happens to my application and my rules? And you'll be right to ask that because if I didn't have an answer for that, this is exactly what would have. Like you upgrade ye is lint and all the conflict and suddenly in your editor
everything will be read. You'll not be able to commit, your prs will just light up with like all the errors that are coming in. And this is I think
where the interaction with Dan happened on Blue Sky. He was talking about having a project with JavaScript or like an older version of typescript and wanting to go to newer version or more stricter or even just introduce typescript okay, And this is kind of the same scenario, like changing the islin conflict because if something in the code checks become different and all of a sudden, all your code screams that you and says like it's red. So how
do you jump over this hurdle? How do you go from previously it was working, now with a little change, it's now suddenly not working. And Don actually talked two times on this podcast from the two years that I've listened to prolifically about this topic, and you mentioned several times like, oh man, this is a nightmare, and yes, it is a nightmare because you don't have many options.
You have like okay, maybe only introduced for the type script files and we don't check the JavaScript files, or we only introduce a few checks but not all the checks that we want, right because in the ideal world, we have like a list of checks that we all agree on that are good and this is how we should be and we turn them on. But in this scenario everything goes read. Okay, So what am I talking about?
What is the solution? It was proposed to me. It wasn't original, as I said, even this repository, it's kind of all going around t MPM with some more stuff just around it. Right, So It was proposed to me in a previous company I work with. It was the idea of having an old project running with the strictest possible CONFIIC for isling whatever you like, all the plugs that you want, however, running a snapshot of all the errors aka remembering in my file called anton dot ts.
I have five errors of this type, I have seven error of this different type. I have twenty errors of undefined. I have twenty more for console look that I don't want to have in my file, right, and remembering that for each file that you have in the repository, and just having this kind of a mini registry. Imagine it like adjacent file of like key value, found name, type of error, how many found name, type of error how many? And this is an invaluable resource in when upgrading and
going stricter, going to a better roule. Why because it lets you see the problems. It lets all of your developers see aha. Edit, my editor is saying this is a problem, so I can focus on it, or I can at least understand there's a better way. While your CI checks at the point of upgrade, at the point you make it stricter, still pass Why because you run yes, Lind, but you also tell Eslin, hey ignore all of these
number of errors in these files. So if you have five undefined like let's say errors in this file, then you do a change. If there are still five or less less than five, it's okay. If there's more than five, then you scream and you fail the commit and you fail the PR. So it's an approach that lets you gradually kind of increase the checks but still remember the status quore like not forcing you to change all of your code today. So I think this is where the
let's say the breakproof part comes in. It allows you to keep going on. It gives you the errors, it tells you what they are, It lets you upgrade. All of the tools live in isolation, but it lets you keep going on. Of course, you can plant tech that you have to plant right when to do it, but it doesn't force you to do it now, and still lets you use newer stuff because newer stuff don't don't
come only with stick the stuff. They also come with improvements, maybe performance, maybe like a different kind of built, maybe a new feature that you've waited so much in typescript four point eight. I know that's your opinion. Specifically on This is not about typescript. But let's say yes Lin or you change from Yeslin to another too. You want to remember the new set of errors. You don't want
to fix them. Now, Okay, a lot of talking. I'm gonna pause again, but that's that's how we handle the flawless. Let's say the interrupted upgrade. You get the new version, you snapshot if there's any problems, and you keep going, gotcha.
Okay, yeah, that makes sense again, something I probably want to play with a little more before it can ask any good questions before we wrap up. I will know one thing in here. I'm just looking at the directory structure and I noticed you have charactors for configured for GitHub, for idea, which is basically all the jet Brains tools, and then vias code as well. These are the standard
What kind of settings are you keeping? There's any number of settings you can put in there, So what kind of stuff do you have in those directors?
I love the questions. I mean, I told it probably many times, but this is an excellent question because many of the more ripple tools that I mentioned there, they exist, right, They help you manage it, and they give you tools to and like descriptions somewhere online documentation of how to configure your development environment, like how to configure intelligence, how to configure VIAS code to better best work with this report.
But in the company, we're okay. We wanted this to be seamless, like we don't want to ask developers to readocumentation and each of them follow each steps. Maybe someone didn't read one step they contact us us, Hey, this doesn't work, right, Okay, I see you know then you know that you know the drill. So we added some
based configuration that we know. And because we know this repository setup, we know how it's managed, right, we know all the tools, we know how to run the tools, and we know how to kind of configure your editor. So we went and went with a base configuration for your editor, plus a CLI that you can run to kind of onboard. You It's like if you run pmp te us a command I don't remember, Behart, but if you ru in command let's say PMPM breakproof on board and to ask you what is your editor? There we
go and you'll structure. I will now set up the base settings for this repot. So it's best for the initial introduction, so to configure let's say yeslint in your VSCO, you configure eslint running for jet brain, so you don't have to forget. I've seen it so many times. You get a new project, you open it up, islin doesn't work, or a diferent version of Yeslin. By the way, it's possible to run like this is total possibility, even vs code.
I'm not sure how many people know. It comes with a built in versions for these kind of tools like typescript, and by default it will run them, not your version, so you get different kind of verse in your editor that the ones that you get when you built, which is super confusing. So yes, thank you for the question.
This is what these repositories are. And there's one for gifthooks basically, which is the things that will run automatically for you on pre comitt Because why because it comes in with some like structure and conventions that you can follow. Like all of it is nothing like separate packages and additional abstractions. It's just a convention for your own package. For example, as long as you have a pre commit script maybe or I think it was called linked pre commit.
As long as you have this script in your packageation it will specifically run it before you commit. You don't need do any additional configuration, and it's all possible because it knows it's managed with PMPM. Okay, I'm gonna post here.
I know.
Were kind of wrapping up, so.
Yeah, yeah, or if my case, you you just skip the pre commit hook sometimes just to get a committed We won't talk about that. Uh yeah. So we sort of hit a time limit here, so we need to start wrapping up. So before we get to picks, was there anything two questions? One, was there anything that you wanted to cover that we didn't cover about this repel?
Yes, I'm not a fast talk or maybe i am, but I'm I'm not able to be super concise. Maybe the one thing that we didn't cover, like we can go into more details, I don't know later on is the fact that because the repository is so integrated, as you see right, editors packages that are already there, right, it comes in with understanding of the structure of the repository. So it comes in with already working CI, already knowing what to run on your pr, already knowing how to
publish your package to MPM registry. All of the things are there and they work very well with the repository because they understand it. So it's not only a management for dependencies and project it's also for you to eliminate the step of like, oh I need to set up now jobs for end to end testing, for publishing, for deploying, for checks. All of it is there, configured with like concurrency and everything that you need. But yeah, that's my short answer. Yes, I did have something I didn't cover.
So okay, all right, well thank you. This is uh my brain hurts.
I'm sorry.
Sorry, that's quite a right. Yeah, there's a there's a classic are if youamiliar with the fire side, there's a real famous cartoon here. I'm not in a state. Oh it's awesome. I look it up online. There's this guy. There're just you know, one panel cartoons, and there's a famous one where he shows a kid in class raising his hands. Excuse me? Can I leave class? My brain is full? So that's right. Look that up that I'll make that as a pick. I don't know where to
find it online, but it's awesome, all right. And then if people want to follow you and give you money, your read more about this stuff? Where are the best places to do that.
Okay, I'll start with the project it's breakproof dev. It will just redirect you to the repo Breakproof Death. Otherwise, for me personally, I use blue Sky. Not extremely active, but I'm there. I respond to messages. That's my kind of a small area of social online life, sometimes LinkedIn, sometimes linking.
Well, that's it, and what are you on blue Sky?
I'm Dev So it's my family name Dev. Yes drinks.
Alrighty, Well, with that, we will shift the picks Pixar, the part of the program where we get to talk about anything. We want to talk about, anything from games to books, to food, to movies, to social issues, you name it. I'm going to stick in the tech realm and reference blog posts that I mentioned earlier called the many many many JavaScript run times of the last decade.
It's on buttondown dot com whatever underscore Jamie, and it is amazing just all of the drun times that are out there that he talks about, whether it's TVs, UH operating systems and native apps and micro controllers and edge computing and so on. And at the end he gives a little summary. He says this was published in June of this year. I think it was June twenty seventh to twenty five. And at the end he gives a
little summary. He says he started he started working on this in April of twenty twenty four and stretch the limits of button down. I guess that's the platform here edit history at over five two hundred and sixty revisions whoa before by August of that month. So yeah, even then he still doesn't think it's finished. But yeah, it's a great interesting if you're into this type of stuff.
It's a great blog post. And then with that we'll switch to the dad jokes of the week, which are the high point of any of these episodes, as any fan will tell you. So we'll start out. My wife was mad at me because I woke her up at three o'clock am, but I just wanted to tell her that she forgot to take her sleeping pills.
Thanks you.
I think everybody knows the movie Jaws. You know about the shark? Did you know that if you watch it backwards, it's actually a heartwarming story about a shark who gives arms and legs to people who need them. And then recently I saw a story about a man who's suing company that makes a product called smart water for not making him smart. I'm not sure what he was thinking, but along those lines, I would like to formally announce my lawsuit against thin mits because they really don't make
it thin. So those are my picks god jokes of the week. What do you have for a santon?
I am trying to find the translation for it in English. Give me a sack, but I both like it's a kitchen thing. It's a kitchen thing, and I amazed my father with it. Give me a second, give me a second, ah a second? Oh yeah, and.
I'm gonna yeah, pretty famous.
What is that the time limit? Oh no, no, pom gran pomegranate, pomegranate, pomogrand Okay, I'm sorry, I mean pronunciation ship. I know, so pommegrant is kind of a famously messy to open it and clean it, and I love it. Yeah, it's true. It's the fruit. It's like a red fruit. It's prolific in let's say, Grease, which is like a neighboring country here in Bulgaria. Uh and it is also part of the south parts is there and my dad, as a person coming from there, I loves this loves this.
I mean when I was growing up, it was just pomegranate and pomegran pomegranate, like any any time it's is the season, and of course it's like a special type of like opening it and getting the seeds out, et cetera. And I recently, I just I don't know, brows online is kind of a shopping, anti depressing, running away from reality moment. So I ended up at the kitchen tool that you kind of put the pomegranate on, and it
comes with a little hammer, like it's super good. Comes with a little hammer, and it removes the mess from getting the seeds out, and it keeps the pieces that host the seeds out of the seeds. It's amazing. Like I know, maybe I'm not doing a good service and a job describing it. It's a pomegranate cleaning tool or whatever. And I love it. Only the fact that it amazed my dad when I showed how this works was worth
so highly highly recommend that anyway. And it's called what I pomegranate too, Like there's no real name, there's no product name, to be honest, Like I think it was like yeah, like I couldn't find like a brand that sells it. It was like a random websites to be honest. All of them have like a different brand names, so I'm not sure there's like a one origin brand that created this.
Yeah. Amazon's got a few pomegranate tool Yeah, yeah, I mean yes, Oh, I think I see this, Okay, Yeah?
Is it like you think?
What I'm seeing has like a bowl and then a piece.
Of it's a little metal bowl. Yes, it's almost like a sie. If there's like a little bowl that is exactly the size of a pomegranate, it looks like this lemon squeezers. There's no squeezing kin. Yes, but you put the bommegranate on it and use the little hammer. It's just ridiculous. It's just ridiculous when you think about it, like being in the kitchen having a little wooden hammer
with it and just knocking out the seats. I mean, I love all all of it and how it functions, the efficiency of it, and by kind of the my wife coming in and just looking at me hammering away at the pomegrap I love all of it.
Yeah. Yeah. Pomegran Appeeler twenty twenty four. There's a few different options amazing.
I know, ridicular spick that could have picked so much other stuff.
Yeah, the life hack type, those are the best ones that helped solve the little problems. Cool for sure. All right, well we're going to wrap up. Thank you Anton for coming on telling us about your project. I know there are many people out there that use mono repos and as I sort of mentioned off there, we have a project that we're looking to move forward open sourcing in a mono repot type of structure. So so that will be uh definitely a tool to look at.
Thank you for having me, Thank you for having me.
My pleasure, pleasure, pleasure. All right, thanks everybody for listening, and we'll talk to you next time on JavaScript ever.