Dependency Management with pnpm

[00:00:00]
>> Steve Kinney: One of the questions that came up, which is like, so I have all of these micro frontends, whether they're in a monorepo, this particularly works if you're in a monorepo, I could come up with clever ways that you could work on it if it wasn't, but like, assume, assume, like I said before, you could have multiple separate frontends, they exist in a repo together, all things become easier with that strategy than if you have more than one repo.

[00:00:24]
But we all have more than one repo also, so it's a little bit of a mix and match, but pnpm has ways to kind of force a little bit of the synchronization of those dependencies and keep everything at a certain level. Um, we saw before in. Uh, well, let's talk about the problem first. The problem obviously is you've got either that shell, or whatever the root thing, which is maybe got multiple dependencies.

[00:00:51]
What do you start doing when some people are on React 18, some people are on React 19, some people are on, you know, more sometimes problematic is, uh, your internal design system, right, and stuff along those lines, because at least like, for like, some of the major libraries, there is like usually like a deprecation period, because like, they're big projects and can afford to do that. The moment you are like having that much ceremony on your internal tools, you are probably sitting in more meetings and writing code anyway.

[00:01:28]
Uh, but you know, the common problem that comes up, which is, OK, I've broken up into a lot of pieces, how do I keep the dependencies in sync, right? And actually, pnpm has a pretty like clever way of doing that. We saw that, um, workspace.yaml yesterday, pnpm-dash-workspace.yaml. And, you know, you can kind of use some of that as well. And so a bunch of the different problems that you come across, uh, now once you take the monolith, you have none of these problems, but we talked about that, which is you eventually end up with other problems, um.

[00:02:03]
You know, but in any of the kind of more distributed architectures, yeah, you end up with Team A on React 18.2, B on 18.3, which is not necessarily a compatibility issue, it's just like saying that you hate your users, right? And you would like them to download every version of React in order to do anything on your site. Um, you know, but more more times like a lot of the internal libraries where it's like, we would like to keep the design system consistent, which means like, if there are some major changes, right, how do we deal with that?

[00:02:33]
And like, design systems are hard, and we'll talk a little bit about that towards the end of the day, because like, you could have a situation where there's a new component that you want everyone to use, but no one's willing to upgrade because 3 teams. Like, made their own special button and now can't upgrade because it breaks the compatibility and like no one's willing to put that into the next sprint, forever and stuff along those lines.

[00:03:01]
Uh, the other ones are, like, if we kind of like mess up the kind of either monorepo or micro frontend thing with the package.jsons and pulling them all together, and we start playing games where we. Play fast and loose with, uh, like the directory like structure, and like, I'm just going to dot dot dot dot dot dot my way out of my package, and, you know, dive into another one. That's not necessarily a declared dependency.

[00:03:28]
It's now in that bundle, right, and can break if the other, you know, group changes something. But it's not necessarily like a stated dependency. And like, normally, most people would smell the you know, dot dot slash dot dot slash dot move, right, where it becomes a little bit tricky. I think we were talking yesterday with somebody asked about like, what about just using like, you know, aliases or TypeScript aliases, where you don't necessarily see it in the code that you accidentally did that somewhere.

[00:03:59]
Right? Uh, and some of these you just kind of have to be mindful of and, you know, kind of enforce. We'll talk about ways that you could seek to codify that in a little bit as well, but you know, they are. Some of the hard parts of our job when our applications grow, which is to like, start to have, you know, to build up the sense of like, oh, that doesn't look right. You know what I mean? When you just even see something and you're like, that smells weird, right?

[00:04:29]
And that's kind of part of our job here today together to do that as well. Um, but pnpm has, uh, also on top of just the clinical workspaces, this idea of a catalog, right, which is like, what are the versions that we're using, right? So we talked about it yesterday where it's like, if you don't have pnpm because you're using npm or. Uh, Bun or something like that, you can obviously just write a script that goes finds them all and tweaks the numbers.

[00:04:56]
The JSON file, I think we're all pretty good at taking a JSON structure and manipulating it. It's kind of like what we do. Um, but like pnpm will also allow you to say not only the workspaces, so you can do that workspace colon, star or whatever, you can also then define some of the npm or third party packages as part of the catalog and do something very similar too. So like if the catalog at the root of the directory says 18.3, or 19.0, or what have you, right, you can then reference that, so you are always using that version too.

[00:05:32]
Um, so, you know, now this would be somewhere in your package.json. Instead of saying that, hey, I'm going to have React 19.0 or 19.0.3 or whatever, we're going to say like, whichever one is declared at the top of the repo is the one that we are using, right? Again. Somewhat pnpm specific, but like, even if you use a different tool, right, one could theoretically like take deep inspiration from that and have even like a JSON file of their own, or a YAML file or a TOML file, whatever your favorite way of like structuring data is, and like, have some process, whether CI/CD or some scripts or something along those lines, to like apply a similar approach.

[00:06:14]
I'm not saying that you need to like switch package managers tomorrow, right? If you like your package manager, you can keep your package manager. But some of the ideas and principles can apply, right, as well.