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