Untangling Your Dependencies: A Pattern for a Well-Knit React Project

Hi, everyone. Thank you so much for joining my session on untangling your dependencies. This is a topic that I really enjoy talking about and I feel resonates with a lot of us who have to manage our dependencies, especially in larger projects.

Just to set the stage, I saw a message in the Vienna Freelancers Slack group that said, I have a client looking for React Native devs. Remote, freelance, good rate, could end up being a retainer situation. And I'm sorry, I always laugh when I read this because it always sounds like that TikTok audio, you know, the one that goes, like, I'm looking for a man in finance. Anyway. So I said yes. Being a freelancer has really given me the power to sort of feel confident to just jump in and be like, well, I've never done TypeScript, but I'm sure I can. The project was also React Native, TypeScript, and a lot of fun to work with. And it was a really interesting challenge for me.

Because when I went in, that project hadn't been worked on in a while. So much so, that when I ran it, I got an error. I tried running the iOS version and the error I got was, could not find iPhone 6 simulator. And here's the thing, folks, I tried 6 is not from last year, as I feel in my heart. It is. But it's actually been more time between the iPhone 6 and now, than has been between the original iPhone and the iPhone 6. Just sharing a little bit of my pain.

Anyway, cool. I tried, I was wildly out of date. What about the Android build? I tried, I tried, if you're not familiar with React Native, it lets you write apps for both mobile and I tried platforms as well, including the web. And yes, that includes iOS and Android. So anyway, I ran the Android build, and I got some Java error. I wasn't sure what it meant. But that's okay. I thought to myself, you know what, I'm just gonna upgrade everything. It's gonna be fine. And well, I tried to know how that went. So first, I tried, okay, well, the React Native version on this project is 55.4, and at the time of recording this, of writing this presentation, React Native was at 074.1. And so, I just upgraded it in one go.

Just went into the package.json file and just changed that number. NPM install, up we go. And you might imagine I got an error. Something about React DOM not working well. And I thought, okay, no problem, I'll just update React DOM. And then React broke. And then some other packages broke.

And after a while of trying to fix this, it kind of felt like one of those cable boxes. Do you all have these at home? Like, I want to hear it in the chat, please. Like, do you have in your home just a box full of cables that you really desperately know you need some day? And you've probably got people in your messages or whatever or your friends telling you, throw away those cables. Let me tell you, don't throw them away. You never know when you're going to need that Nokia 3310 charger. Trust me.

Anyway, working through all of this, I tried to stick with our metaphor a little bit more. It kind of felt more like I was working with a very tangly ball of yarn when trying to knit a project. I tried as you get the drawing itself not made by me, but the squiggles a little bit more made by me. I'm not a very good artist. So anyway, that's what we're going to get into today. The question isn't so much, what are the best practices for managing dependencies? I'm a big advocate for best practices change over time. Instead, I tried to talk about what are my favorite practices for managing dependencies. And in order to do that, I'm going to tell you a little bit about myself.

So hey, my name is Katmin, pronouns she, her. I'm originally from Chile, living in Austria for a very long time. I'm working as a developer educator at a company called Directus. And I'm the cofounder of the Bad Website Club where me and my friend Jess make developer education more accessible and get folks into coding in a very low stress, low perfectionism environment, as much as we can. I try to really love communities. I feel like this is one of the best ways that we can learn and grow as human beings. I try to think about dependencies is sometimes we take them for granted, don't we? We just sort of like throw them in and just be like, yeah, whatever. I need something to like, you know, make my life a little bit easier. And I'm not going to really think about the code.

But at the end of the day, it is still a piece of code that you're introducing into your project, isn't it? So I tried. Thing is, with time, those dependencies add up in size. You've probably seen this meme before. Heaviest objects in the universe and your Node Modules folder is quite heavy. I remember I was at a conference and somebody gave a talk about how they took that concept of the Node Modules folder and made a Katamari game out of it. Where if you're not familiar, you play as a little character and you roll a ball and as you pick up bigger objects, the sphere that you're rolling grows in size. And they did that with a Node Modules folder, which I thought was hilarious.

I tried working with all of those dependencies. It kind of feel like a very I tried balancing game. And I don't know about you, but sometimes I get a little bit nervous that if I just I tried one part that I'm moving, the whole thing is going to collapse. Kind of like a big game of Jenga. I tried. I tried. I'm going to do that part where I bring a quote by a really smart person into the presentation. And I really tried hard to make sure that this wasn't one of those Mark Twain situations, you know, where it gets attributed to Mark Twain. I'm like fairly certain it was Leonardo da Vinci who said, art is never finished, only abandoned. And in some ways I kind of feel that applies to software as well. So what I'm going to do is I'm just going to show you a couple of tricks and tips for managing your complex dependency management systems and how you can understand those better. I tried from the top, weren't we? I tried to talk a lot about dependencies and we, you know, wax philosophical on different management styles. But what about understanding what kind of dependencies there are? I tried. I tried. I tried. I tried. And we see these when working with, for example, a package.json file where we have dependencies and dev dependencies. Now, I'll admit there was a time where I would just like throw everything into the same box. I'm just like, oh, you know, I'm, I'm developing a project. I'll just put it into dev dependencies. It'll be fine. I tried friends. I tried dev dependencies do not get included in a production bundle.

I tried most of the time. I remember seeing a GitHub issue where somebody discovered that. I think it was in Meteor that a bunch of, a bunch of like dev dependencies were being included in the production bundle, which again, aren't necessarily needed in it. Some things like TypeScript, linters, that sort of thing.

I tried. So, these are called direct dependencies. But you remember that meme I showed you earlier, right? With the heaviest objects in the universe. What about the ones that the dependencies that get installed by dependencies? And these can sneak in and just make the box grow in size. These are called transitive dependencies.

I tried, but those aren't the just, those aren't the only types of dependencies we can work with. There's also peer dependencies. And peer dependencies are dependencies we're going to see more often if we're working on a package ourselves. There are dependencies that our package is compatible with or meant to be used with. I'll give you an example. You can see here, I'm working on a package called fancy charts. And I'm declaring as a peer dependency, chart.js. And what this means is that when somebody goes to use and install, I tried fancy charts, chart.js will be installed along with fancy chart, not as a dependency, but a peer dependency.

I tried, I tried. And there's one more place that we look at when we're talking about dependencies in our React projects. I tried, I tried the package lock file. Has any of y'all actually ever gone in here and looked around? Because it's wild. I mean, just look at my text editor here. Line six, hold up, 16,427. It's a meaty file. And I have to admit, I mostly work with it when I'm getting merge conflicts. I tried. So, yeah. These are different places where we're looking at what the package lock JSON file does, by the way, is declare exactly which versions of those dependencies we're going to be installing if somebody goes, wants to go and develop and work on our project. I tried, okay. Those are the types of dependencies.

I tried. We're starting to work with them. And I tried running into troubles as I was with React Native. I want to harp on again about that power of community. I tried folks work on incredible tools that help working on, that help us with working on our dependencies. And I want to show you just a couple. There's different ones for different package managers that you use.

For example, yarn upgrade interactive or NPM check updates. And these tools are amazing. I'm going to show you yarn upgrade interactive real quick because what it does is it shows you which dependencies in your project have updates available that you can update to and which ones are I tried to upgrade or could be a breaking changes. We'll get more into that later. I think this is absolutely wonderful when I just need to like, you know, polish off a project and see what's meeting with upgrades.

But there's also tools specific to the environments that you're working in. Like I tried, I cannot tell you all how much the React Native upgrade helper has saved my butt so many times over the years. Because what it allows you to do is you can say, cool, what version are you working with now? What version would you like to upgrade to? And it'll give you not just instructions on how to upgrade but also a diff of the configuration file so that you can see, cool, we're not using this anymore. We switched it out for some other bundling, thingamajig, all that stuff. It's really powerful. And I'm so thankful to communities for making it possible for us to work easier with our tools.

I tried, I tried, I tried those tools that help us, I tried, I tried and interact with our dependencies. What happens when we're stuck? After all, as software developers, we're problem solvers. We get stuck a lot. At least I do. I tried, pretty sure a lot of us do. I tried, I tried the problem down into smaller chunks is such a powerful tool for helping me focus and getting the job done. I tried, I tried, I tried to have you run into the issue, error resolved, could not resolve. Something about could not resolve dependency React depends on this. But this other project, this other dependency depends on that. It's a nightmare to work with. So what do I do? I break the problem down. I tried to remember when I was working with this React Native project, I couldn't get the iOS build to run and I couldn't get the Android build to run.

So what do I do? I tried on one at a time. Oops, sorry. I got excited. I tried. So, cool. I'm just going to focus on getting the iOS build running and then I'm going to break that problem down into smaller problems and just focus on one at a time. First, we're going to adapt to auto-linking. Done. Fix compiler errors. Done. UI elements broken, fix it. Bugs introduced by upgrading. Fixed. Compiler warnings, fixed.

And once that's done, I'm done with iOS. Now I'm going to focus just on Android. Same thing like before. Tick, tick, tick, tick, tick, tick, tick. Fix everything. Still make sure that the iOS build is running. Oh, actually, by trying to get the Android build running, I kind of broke the iOS one. But that's okay. I didn't find that out until the very end because I was focusing on one problem at a time.

I tried, I tried, I tried, I tried to have a video game. I'm going to massively age myself by referencing this, but I hope there's someone in the audience who knows or remembers Greenhouse from Game & Watch. It hurts me that this is from 1982. But I played it on the Game Boy. But the point is, you're playing as a gardener taking care of his garden and there are vermin coming in to, like, eat your crops and you're supposed to, like, hit them with a spray. I tried really, again, it's that focus of one bug at a time. See what I did there? Because it's a programming and there's bugs.

Anyway, again, I tried to stay focused. Fix one problem at a time. That's what we do every day as software developers and the same goes for that as dependency managers.

I tried, I tried, I tried. Now, I tried thinking about dependencies, especially as React developers. We're going to do some arguing about tooling. I'm teasing. We're not going to argue about tooling. And, of course, I tried super important and I don't know. I'm a big believer in not so much, like, there's one tool that fits all, but rather picking the right tool for the right job.

We can argue about whether Yarn or NPM or PMPM is better. Fun fact, by the way, when writing this talk, it was one of those things where I was, like, what does PMPM stand for? What does a P in PMPM stand for? It stands for performant, which makes sense. And I tried the benefits between Yarn and NPM and PMPM is important to make sure that you're doing the job you need done. And, again, it's one of those things where not one size fits all.

I tried, I tried. Besides, it's not just about package managers. It's also about tools to help you figure out, for example, where your dependencies are coming from.

I tried, I love NPM why? Because what you can do is just say in your terminal NPM why deqol, for example. We're going with deqol. And then it'll tell you which subdependencies are depending on deqol and which versions they're of.

I tried, this is extremely handy when you're trying to prune out those dependencies that you don't really need anymore. I tried, I tried, I tried. Why do it yourself if you can let a tool do it for you automatically? Clip is a really powerful tool for finding out which unused files dependencies and export SSS in the website you don't need anymore. It's a fantastic tool. Shout out to Josh for introducing it to me.

I tried, I tried. Okay. We've been talking so far about projects with probably one set of dependencies, right? What about monorepos? And I'm not going to get into an argument here about whether monorepos are good or bad. I'm just going to acknowledge the fact that there are projects that use them.

I tried, if you're not familiar, monorepos are a way of having, I tried code bases that ideally share dependencies or share a repository. I tried, I tried one of the phenomenal set of ways of doing this is Yarn workspaces, which again, lets you have several code bases in a repository that share dependencies. In fact, Yarn uses this. Yarn uses Yarn workspaces to have things like website, the package itself, having multiple packages, all in one repository, all in one, a code base made up of several code bases.

I tried, I tried, and X does the same thing, including much super powerful tools for CI and other automations to work to make working in complex code bases much simpler. I tried, I tried, I tried, I tried, I tried, I tried, and then there's npm shrinkwrap. Don't know if you've heard of it. These are tools that come with npm, which I always find so fascinating.

I tried, and in concept, npm shrinkwrap creates a lock file, very similar to lock json. I tried, I tried, change that with the difference that I tried to include it when publishing a package, and you might think, why on earth would I ever need that? For example, I tried my tools using something like npm publish will let you publish this shrinkwrap lock file. I tried, I tried, remember when we were talking about upgrading dependencies, there are also tools like npm audit to help you find out which one of your dependencies is out of date, has a security breach, and needs an upgrade urgently, which again, doesn't have to be done by hand. Can also be done automatically by services like Dependabot, Snyk, and Renovate.

I tried, I tried, so cool that's some tools to work with dependencies. I tried when making those upgrades, how big a leap do we make? I tried, I tried to make the call of, oh, I'm just gonna go all the way to the latest version, because when I was working on this project, right, I could have gone the route of upgrading from React Native 55 to 59, make sure everything works, and go from there. 59 was a milestone, because it introduced some JavaScript stuff for Android, in general, to make everything more efficient with React Native. I tried, would have gone from React Native 55 to React Native 60. I tried, I tried, I tried all of the native modules for doing things like working with the camera and that sort of thing are auto-linked, which means I don't have to do any complicated, what are they called, linking of dependencies with the iOS and Android builds, respectively.

I tried, I tried, but I went all the way to 0.74. I tried, you might be wondering why, that sounds really painful, and the answer to that is a rather cheeky why not. I tried, I tried, because I tried gone a little bit and just left it as it is, but here's the thing, not only am I making sure that I'm on the most stable version, remember, when working with something like React Native, you're not just dependent on the JavaScript project, the React project, the React Native project, you're also dependent on the whims of Apple and Google making changes to their platforms, so staying up to date is a really good idea with this sort of thing.

But also, I tried, I tried, going to happen eventually, might as well get it out of the way. I tried, and then you can adopt a workflow of doing it more often. I tried another quote from Martin Fowler who writes, if it hurts, do it more often. It has the happy property of seeming nonsensical on the surface but yielding some valuable meaning when you dig deeper. If you're going to be upgrading, at least have a workflow for doing it at a set regular interval. I tried, I tried, I tried doing upgrades like this.

I want to take a moment to preach one of my favorite practices for version control, which is called the bleeding edge branch. I don't know if you've heard of this, it's actually referenced in the Git manual as something you can do, which is you have a branch that's just sort of like a sandbox, such of a scratch pad, where you have tiny, likely broken commits where you're just like upgrading something and it's broken, something else is broken, just keep committing so that you can have a history that you can fall back on to understand what were the steps you took in making this dependency upgrade, but also makes it extremely to rebase.

I tried, I tried, I tried, I tried to the end, I tried, I think it's also really important to know do I need to upgrade all of my dependencies in one go. I tried, in the project that I was working on there were 72 dependencies in it and I did not update them all and I did not update them all the way. I tried looking at something like semantic versioning, you know where the number on the left is a major API breaking number, the minor version is new features that don't break anything in retrospect, and the rightmost number is the patch version that just introduces bug fixes and good idea to, relatively a good idea to keep those up to date.