Making Monorepos Breakproof with Anton Stoychev - JSJ 694

In this solo-hosted episode, I (Steve Edwards) dive deep into the world of modern monorepos with special guest Anton Stoychev from Yotpo. Anton shares his journey from the early days of PHP and IE6 nightmares to his current work in front-end infrastructure, performance optimization, and developer tooling.

We talk about the challenges of managing dependencies, upgrading tools without breaking your codebase, and the evolution of developer experience across teams and companies. Anton also introduces Breakproof, Yotpo’s open-source monorepo template designed to make dependency management and tool upgrades painless—even when working with multiple Node.js versions, runtimes like Bun and Deno, and complex CI environments.

If you’ve ever struggled with upgrading Jest, ESLint, or TypeScript in a large monorepo, or you’re curious how to isolate dependencies to keep your codebase maintainable over time, this episode is a must-listen.

🔗 Links & Resources

• 🔧 Breakproof on GitHub: breakproof.dev
• 🧠 Yotpo LTD on GitHub: Yotpo Breakproof Base Monorepo
• 💬 Follow Anton Stoychev: stoychev.dev on BlueSky

Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Episode Transcript

Speaker 1 (00:05):
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

(00:26):
special gift, mister Anton stoychef, how are you doing? Anton?

Speaker 2 (00:30):
Pretty good? It pretty good? Thank you good?

Speaker 1 (00:33):
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.

Speaker 2 (00:48):
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.

Speaker 1 (01:00):
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.

Speaker 2 (01:14):
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

(01:34):
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

(01:55):
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

(02:15):
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

(02:37):
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.

Speaker 1 (02:47):
That well, I guess that depends on the size of
the company.

Speaker 2 (02:50):
Sure, sure, sure sure.

Speaker 1 (02:52):
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.

Speaker 2 (03:10):
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

(03:32):
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.

Speaker 1 (03:42):
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.

Speaker 2 (03:56):
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.

Speaker 1 (04:15):
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.

Speaker 2 (04:29):
No SAM SAM framework, no templating, just like combining HTMLA
oh god.

Speaker 1 (04:37):
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

(05:02):
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.

(05:25):
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.

Speaker 2 (05:48):
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.

Speaker 1 (06:03):
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

(06:25):
to accommodate for I E. Six abnormalities in their CSS.

Speaker 2 (06:28):
Oh yeah.

Speaker 1 (06:29):
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.

Speaker 2 (06:43):
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.

Speaker 1 (06:51):
Yeah, until you got to edgyum, you know, or you
know that's whatever you call the when they finally changed engines.

Speaker 2 (06:57):
Yeah, chromium based eight.

Speaker 1 (06:59):
Yeah. So yeah, yeah, it sounds like we've been through
some of the same same wars.

Speaker 2 (07:05):
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,

(07:29):
oh can you do this for me? Yes? Thanks?

Speaker 1 (07:32):
Right, Remember the days of figuring it out?

Speaker 2 (07:36):
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.

Speaker 1 (07:53):
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

(08:14):
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

(08:35):
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.

Speaker 2 (08:45):
Yeah, I mean I'm just thinking ancessary at the moment
because this is like my daily driver the last few months.

Speaker 1 (08:51):
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?

Speaker 2 (09:01):
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.

Speaker 1 (09:08):
T p O. In case you're you're you're looking for
dot com?

Speaker 2 (09:12):
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.

(09:34):
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

(09:54):
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.

Speaker 1 (10:08):
Think refactor ais are you?

Speaker 2 (10:11):
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.

Speaker 1 (10:27):
Well. The problem with that, though, is the AI is
training itself on the old stuff.

Speaker 2 (10:31):
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

(10:51):
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

(11:13):
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.

(11:34):
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,

(11:55):
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,

(12:17):
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,

(12:37):
let's put web back, let's put just let's put the
way Yeah, go ahead, Wait a minute.

Speaker 1 (12:42):
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.

Speaker 2 (12:52):
And absolutely and absolutely taking apart.

Speaker 1 (12:54):
So I guess I'm confused as to I mean, it's
like you're complaining two different things there, I.

Speaker 2 (12:59):
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,

(13:21):
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

(13:43):
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

(14:04):
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

(14:24):
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

(14:45):
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,

(15:10):
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,

(15:34):
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

(15:55):
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,

(16:18):
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

(16:41):
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.

Speaker 1 (16:54):
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.

Speaker 2 (17:05):
Yeah.

Speaker 1 (17:05):
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,

(17:26):
to be able to handle Laaravelt twelve. And so you're
either looking at patches or you're waiting or I'm nothing.

Speaker 2 (17:32):
By the way, I'm not sure if it's somebody's watching listen,
but I'm heavily noting here because this is it.

Speaker 1 (17:38):
You can't upgrade.

Speaker 2 (17:39):
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

(18:00):
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,

(18:24):
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

(18:45):
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

(19:05):
of me any of the other dependencies that are heavy
my project no matter whatever they are. How does that sound?

Speaker 1 (19:14):
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

(19:36):
assuming you'll get to that.

Speaker 2 (19:38):
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,

(20:00):
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

(20:21):
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,

(20:44):
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

(21:08):
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

(21:29):
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.

Speaker 1 (21:40):
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.

Speaker 2 (22:00):
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

(22:24):
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

(22:45):
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.

Speaker 1 (22:54):
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,

(23:15):
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.

Speaker 2 (23:23):
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

(23:45):
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

(24:08):
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

(24:30):
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.

Speaker 1 (24:49):
I've always been curious what that first P stands for
in pm PM.

Speaker 2 (24:53):
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.

Speaker 1 (25:02):
Yeah, I always have the important questions like that.

Speaker 2 (25:05):
So yeah, that's that's kind of your responsibility.

Speaker 1 (25:11):
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?

Speaker 2 (25:32):
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.

Speaker 1 (25:45):
Oh yeah, yeah, I like to make it clear.

Speaker 2 (25:48):
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,

(26:09):
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?

Speaker 1 (26:23):
Right?

Speaker 2 (26:24):
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

(26:45):
checks before get commited right or on get a pr
We won't just oblive that.

Speaker 1 (26:52):
Yeah, I think we use that on my project. So yeah,
I know what you're talking about.

Speaker 2 (26:55):
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.

Speaker 1 (27:10):
It was.

Speaker 2 (27:10):
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

(27:32):
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.

(27:56):
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

(28:17):
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

(28:38):
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

(29:00):
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,

(29:20):
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.

(29:43):
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

(30:06):
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,

(30:29):
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

(30:50):
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

(31:10):
have my gest related stuff in a separate package right
in the mono report.

Speaker 1 (31:15):
The MPM package. Is that a separate like a separate directory. Yes,
separate directory.

Speaker 2 (31:20):
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

(31:41):
can run a newer or older note like the application
meaning the build of the application.

Speaker 1 (31:47):
Right.

Speaker 2 (31:48):
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

(32:10):
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,

(32:33):
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.

Speaker 1 (32:58):
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.

Speaker 2 (33:06):
But so where.

Speaker 1 (33:10):
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

(33:31):
actually get installed?

Speaker 2 (33:33):
Yes?

Speaker 1 (33:33):
Where is the physical locations of those?

Speaker 2 (33:35):
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

(33:58):
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.

Speaker 1 (34:14):
One version manager.

Speaker 2 (34:16):
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

(34:39):
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

(35:00):
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

(35:24):
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

(35:46):
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,

(36:08):
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?

Speaker 1 (36:31):
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.

Speaker 2 (36:43):
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

(37:04):
no jas with debt version.

Speaker 1 (37:07):
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

(37:28):
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

(37:48):
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?

Speaker 2 (38:12):
Give me a second too, kind of.

Speaker 1 (38:15):
Actually an issue? Because notice is your runtime from when
you're developing?

Speaker 2 (38:19):
Yes, yes, if you're asking about runtime versus death time.

Speaker 1 (38:23):
Yeah.

Speaker 2 (38:24):
If if runtime is the browser, you don't you don't
need to think about it.

Speaker 1 (38:28):
Okay, Yeah, never mind, I just realized that as that.

Speaker 2 (38:31):
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

(38:54):
are like a mismatch with your own dependencies if you
store them at the same place.

Speaker 1 (39:01):
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.

Speaker 2 (39:09):
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.

Speaker 1 (39:22):
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.

Speaker 2 (39:41):
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.

Speaker 1 (39:49):
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.

Speaker 2 (40:03):
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.

(40:26):
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

(40:47):
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

(41:07):
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.

Speaker 1 (41:22):
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,

(41:44):
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.

(42:05):
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,

(42:29):
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?

Speaker 2 (42:39):
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

(43:02):
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,

(43:23):
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.

Speaker 1 (43:44):
That makes sense, I mean that's just kindard template type.

Speaker 2 (43:46):
Yeah.

Speaker 1 (43:47):
Sure.

Speaker 2 (43:47):
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

(44:10):
and you don't have all the previous changes, et cetera.

Speaker 1 (44:13):
Okay, well, that can be good or bad.

Speaker 2 (44:14):
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

(44:34):
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,

(44:57):
right and vice versa. If you update your original repository,
I can pull in all the changes.

Speaker 1 (45:05):
Right. So we picked you're talking about working the whole repel,
not just a branch within a right, you fork the
entire ripple.

Speaker 2 (45:13):
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

(45:38):
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

(46:00):
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

(46:23):
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.

Speaker 1 (46:35):
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.

Speaker 2 (46:45):
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?

Speaker 1 (47:00):
Right?

Speaker 2 (47:02):
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,

(47:28):
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

(47:50):
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.

(48:14):
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

(48:35):
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

(48:59):
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

(49:20):
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

(49:41):
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

(50:02):
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.

Speaker 1 (50:18):
Speaking personal experience, I mean, yeah, I.

Speaker 2 (50:21):
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

(50:43):
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

(51:04):
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

(51:25):
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

(51:50):
thought is.

Speaker 1 (51:51):
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,

(52:13):
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.

Speaker 2 (52:22):
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

(52:42):
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.

(53:05):
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

(53:27):
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

(53:48):
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.

(54:08):
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.

Speaker 1 (54:18):
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.

Speaker 2 (54:38):
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

(55:00):
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

(55:21):
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

(55:43):
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

(56:03):
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

(56:27):
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

(56:48):
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,

(57:08):
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

(57:31):
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.

(57:55):
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

(58:17):
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

(58:40):
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

(59:03):
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

(59:24):
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

(59:45):
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,

(01:00:07):
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

(01:00:29):
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.

Speaker 1 (01:00:44):
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,

(01:01:07):
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?

Speaker 2 (01:01:19):
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

(01:01:42):
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

(01:02:03):
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

(01:02:24):
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

(01:02:46):
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

(01:03:07):
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

(01:03:28):
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

(01:03:51):
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.

Speaker 1 (01:04:08):
I know.

Speaker 2 (01:04:09):
Were kind of wrapping up, so.

Speaker 1 (01:04:10):
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

(01:04:30):
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?

Speaker 2 (01:04:43):
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.

(01:05:07):
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

(01:05:31):
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.

Speaker 1 (01:05:48):
So okay, all right, well thank you. This is uh
my brain hurts.

Speaker 2 (01:05:55):
I'm sorry.

Speaker 1 (01:05:57):
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

(01:06:18):
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.

Speaker 2 (01:06:37):
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,

(01:06:59):
sometimes linking.

Speaker 1 (01:07:00):
Well, that's it, and what are you on blue Sky?

Speaker 2 (01:07:03):
I'm Dev So it's my family name Dev. Yes drinks.

Speaker 1 (01:07:10):
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

(01:07:35):
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

(01:07:57):
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

(01:08:19):
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

(01:08:40):
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.

Speaker 2 (01:08:55):
Thanks you.

Speaker 1 (01:08:57):
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

(01:09:19):
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?

Speaker 2 (01:09:40):
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.

Speaker 1 (01:10:01):
I'm gonna yeah, pretty famous.

Speaker 2 (01:10:03):
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.

(01:10:24):
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

(01:10:46):
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

(01:11:07):
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

(01:11:27):
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.

(01:11:50):
All of them have like a different brand names, so
I'm not sure there's like a one origin brand that
created this.

Speaker 1 (01:11:58):
Yeah. Amazon's got a few pomegranate tool Yeah, yeah, I
mean yes, Oh, I think I see this, Okay, Yeah?

Speaker 2 (01:12:06):
Is it like you think?

Speaker 1 (01:12:07):
What I'm seeing has like a bowl and then a piece.

Speaker 2 (01:12:10):
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

(01:12:32):
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.

Speaker 1 (01:12:48):
Yeah. Yeah. Pomegran Appeeler twenty twenty four. There's a few
different options amazing.

Speaker 2 (01:12:54):
I know, ridicular spick that could have picked so much
other stuff.

Speaker 1 (01:12:58):
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

(01:13:21):
be uh definitely a tool to look at.

Speaker 2 (01:13:24):
Thank you for having me, Thank you for having me.

Speaker 1 (01:13:26):
My pleasure, pleasure, pleasure. All right, thanks everybody for listening,
and we'll talk to you next time on JavaScript ever.