Updating Project Dependencies

Boss, and Scott

key.

Welcome to Syntax in this Monday. Hey, Steedreet. We're gonna be talking all about updating your project's dependencies All of that fun stuff when it comes to your packages in your projects. My name is Scott Talinski. I'm a developer of Bender Colorado. And with me as always is Wes Bos.

Excited to talk about updating dependencies.

And I'm excited to talk about 2 of our excellent sponsors today, LogRocket and Magic Bell. The first of which is going to be LogRocket.

LogRocket is the perfect place to see all of your errors and exceptions happen as they happen To the users they happen to. That's right. You actually get a video, a scrubbable video replay with console log, network request, and even your Redux store if you're using Redux.

Normal depth. You can have a hosted version or an on premise version. It's really pretty amazing. Check it out at logrocket.comforward/syntax.

Check out all of their little demos and documentation videos. Give it a try. Pop it in your project. I know that we love and use it over here at level up tutorial. So check it out. And, Wes, do You want to talk about Magic Bell? Yeah. We had Magic Bell as a sponsor,

a couple I don't know. Last year sometime.

And they're back for some more, and they've got looks like they got a whole bunch of really cool new features as well. So Magic Bell does, notifications for your application. So if you need to notify your user about, something happening in your application, whether that's some their product has shipped or, somebody has followed them or whatever.

Magic Bell is an entire framework for working with those types of things. They do push notifications, email notifications, in app notifications.

They have this really cool thing called smart notifications, which I love because, if you're, like, in an app let's say you're in an app and you get a notification about, like, Scott Tylinski has followed you. And you see that, then, like, I don't need an email that also tells me Scott Tylinski has followed me. But if I'm not in the app, Then I should. Or, like, do I need a push notification if I've already seen that? So Magic Bell has this thing called smart notifications, which if they've seen it in one part, then it's not gonna notify you about it in the other, the other parts, which is super super smart. They batch task. You can have preferences.

This is one of those things that's, like, you think it's so simple to just add a notification little little bell to your, your application, but then you get into all of these little edge cases and all of, like, somebody wants a notification only once a day or I want to, if I've seen it in the app, then don't email them. It just gets very, very complicated. So if you need notifications in your app, check it out atmagicbell.com.

The free plan gives you a 100 MAU. You know what a MAU is, Scott? Meow.

It's Mau, monthly active users. That's that's what that means. So you can get a 100, of those for free.

And if you use the coupon code syntax f m, you're gonna get 10% off for your 1st 12 months. Thank you, Magic Balve, for sponsoring. Nice.

Cool. Let's get into updating project dependencies. We all love dependencies.

So For for those of you who don't work a ton in JavaScript or maybe you're a new developer, our projects, they rely on other packages to to work. Right? If you're running a React package or React website, then React is going to be one of those packages. We call those dependencies. We depend on them Because they're the packages that we're using in our application. So that's what a dependency is.

And, Wes,

take it away. Yeah. I I just did a bunch because, like, I started off the year with, a new gumption for life And I decided I'm going to update everything. So I, uses that tech website was on Gatsby 2. Now it needs to be on Gatsby 4. Personal website was on Gatsby 3, needed to be update updated to Gatsby 4.

My course platform had a whole bunch of dependency updates updates that needed to happen.

The syntax website was on Next. Js ten as well as a whole bunch of other things, and that was updated to Next. Js 12.

So this I updated 4, like, fairly large websites, and I have put together a sort of a process For for going through these things. And we've joked in the past and half joked and half real of just YOLO updating some of your stuff, which means that you just literally update it all And just hope for the best. And you can you can do that in to a a certain point. But when you Come back to a project you haven't touched in 6 or 8 months. There often is major versions that have been updated, and there's fifteen, 20 things that are all new versions. So, like, what is your process for even approaching that? So I've put together some steps as to what I think, is a is a sane way to approach this type of thing. And I'm curious to see how how Scott does that as well.

This is this is more gonna be on like like tools or not sorry, not tools, but like more of methodology. Yes. Right. And in the past we've talked about, an actual project called, npm check updates, n c u.

And that's specifically what I used to check if there are any updates.

And if you're using a mono repo, I learned you can do dash dash deep, and it will go through every package JSON and tell you what updates are in there. And then use you just told me that there is something built into PNPM for this as well. Yeah. Yeah. I use PNPM,

And, let's see. It's p n p m up is the command. And if you pass it the hyphen I, lowercase I flag, It will give you an interactive version, which is just like one of those lists where you can hit space bar to fill in the dot and choose which ones you want to update. You passed in a, hyphen capital l, it will give you all latest versions of packages rather than just, like, I think, patch or or minor version updates. I'm not I'm not exactly sure. I always use the l just because I like to see what the newest stuff is even if I'm not going to update to it. But, yeah, I I love these interactive tools, whether it is the yarn version of this thing, p n p m version or n c u. All of them, are are just this is the way I do it. There's also another strategy, which would be, like, there's plugins for Versus code that will tell you if there's a new version in your package dot JSON. And you can do it via package dot JSON. It seems like a little more tedious to me, but if you're the type of person who likes to work in that kind of environment rather than running a script or something. Yeah. You can have, like, a GUI. Yeah. That that seems like a viable option as well. So yeah. So those are the tools. Let's talk about approach. So the first thing I do when I do these is I'll run

n c u. I'll see a huge list of everything, and it will tell you what needs to be updated and what versions are there. And it will usually color them, green or red Or yellow.

And or yellow. And those are associated with SemVer, a semantic versioning.

And that's those software in SemVer. That's what that's what Node. Js uses or npm uses, is a three point system. So 1.3.1.

And we've said this before, but really quickly. The, the first point, if you're going from 1 point whatever to 2 point whatever, That's a major version, meaning that there's likely going to be breaking changes in that.

And then if you're going from 2.0 to 2.1, Then that is a minor update, and that should not have any breaking changes, but it can have new functionality Or at least backwards compatible functionality. Maybe they've changed how they've done something, but the API should still work or they're not gonna take away a method that you're using in a minor update. And then there is a patch release.

So, 2.2.1.

Shoot. When we released 2.2.0 something broke or there's a bug in this, like, weird edge case. So we patched it, and it doesn't doesn't change any. It doesn't add functionality. It doesn't break any functionality. It just fixes how it should actually work.

And that's how most people Should follow it. It's it's definitely not always the case. But in most cases, if you get one of those, patch updates, I'll update all of those first, like, oh, there's a new lodash, unique of 3.5.2.

I'll just update that. That's probably fine. You know? Then I'll go through all of the minor updates, as well, And then I'll leave the major ones, for,

I'll talk about that in just a second. Yeah. I do the same thing. I I do I do the exact same thing. Patch first, minor next. Yeah. Beautiful.

Then I'll go through and upgrade groups minor groups at the same time. So I won't update everything every single thing at once. That is a minor update.

I will update groups at a time. So Interesting.

Gatsby and all of its Gatsby plug ins. I'll do it. You can do a dash dash filter on your NCU, and you can update anything that has Gatsby in the word, and that will update all the dependencies, ESLint and all of the ESLint plugins. I'll update all of those at once if they're all minor. And then finally, once I'm done that I'll go through any any other minor stuff that that hasn't been updated.

Number 3 is update major dependencies. So these are things that have done a full version bump. Now you're getting into, something might break here. This we have to really pay attention to this type of thing. So, Gatsby 3 to 4 was a big one. ESLint 6 to 7 or 7 to 8, A major version of Babble, major version of of React.

You can you can kind of expect That if you are doing a full version bump, that something might break. Or a lot of places like React, they will deprecate but not remove functionality in a major version.

And then the next major version, they'll remove it. So, if let's say React wanted to remove useEffect, we're on React 18 right now. React 19 would not remove useEffect, But it would start throwing warnings saying, hey. Pretty soon, this is gonna be removed. They're not they're not removing his effect, but that's just an example.

And then in React 20. They would totally remove it, once everyone's had enough time. And usually, you get at least,

like, a year, 2 years to to catch up to those things before you actually have to to upgrading and and actually change how your code works. Yeah. And then honestly, it depends, like, what the repo is. Right? Because I I do know that, like, some things are more likely to break than others. For instance, like, Mongoose is like a pretty mature package. If If it's going from a major version to another major version, you can probably guess there will be breaking changes there, especially because it's some very semantic versioning where You know that a major update is for breaking changes, but, like, if you have, like, ES Lint or something, I have no problem yellowing a full version update of ESLint because it's, like, really low stakes. Right? So I do like to calculate the stakes. And also if there is, like, a high stake one before I before I make any sort of change or modification to those packages, I will go straight up to their change logs and look in the releases section. Releases of the GitHub repo. If you've never if you've never seen it before, you go to any repo. You can look at the releases section. I think the link is just right there on the Just under the about, there's a releases. A lot of packages will say, here's the releases, and they'll typically have a change log or at least at least an ability to look at some of the PRs to see what exactly went in there. And so major big packages, I'm definitely checking out that first. Yeah, that's exactly what I did. So it's funny you say Mongoose. That's the one that I just upgraded

on Friday myself. They went from a major version to another major version, and we have to do some of them yet. Is it is it a bit is it a breaking? Is it a big thing? It was a little bit. There was no breaking changes at the end of the day, but I needed to also update the version of, it was actually the other way around is that my host is updating the version of MongoDB that's running on the server. So I needed to update mongoose so that, it worked with the newer version. So I sort of just, like, prepared myself for that upgrade that's coming in a couple weeks.

What are breaking changes, and they will almost always have a bulleted list of usually obtuse APIs that nobody ever uses.

And you just go through each of those bullet points, and you can almost always just search in your your course platform or not course in your code base And say, did I use this? Did I use this? Did I use this? And then when you hit something that you did use, it'll say, we don't no longer use this. If you need to use this like, for an example, I was using, in Mongoose, I was using dot count, and they changed that to either dot estimate entries or dot count entries.

And there was a little bit of like if you need to filter based on non index fields use this one, otherwise use this one. So you just got to kind of read through it, update your code base, make sure it still works, and then you're you're good to go. As I'm doing this, I will be doing git commits for every like, upgrade Gatsby, upgrade Mongoose, upgrade ESLint, and that allows you to sort of batch these updates.

Should anything go wrong, you can always roll back

that specific changes. Yeah. I always create a new branch for updates, commit in between each of those those runs. But oh, this is another area. I do wanna say that TypeScript can really save your bacon too. Because if there already major API changes and everything is fully typed, TypeScript is gonna yell at you. It's gonna say, hey.

This is no longer a method or whatever that error ends up being. Yeah. Yeah. Or you're you're passing a string here. It's no longer supported to pass a string. You have to pass an object with a value prop inside of it. Something weird that, you know? And that's another huge up huge benefit for TypeScript.

Totally.

Finally, after that, once I've done all those major dependencies. I'll upgrade any stand alone stuff.

You have to do some research on like, for example, I had to update a, I had to actually update my database version. So this is not a dependency, but it's what's actually running on my database side.

You sometimes need to regen some some, API keys. So a lot of times, I know I know Stripe does this. I know Sanity does this. A lot of, really good companies will version, their APIs to associate with, API keys.

So if you are upgrading to a new version of a package. Sometimes you'll have to regen a new set of API keys for that as well to go along with it.

And you need to make sure that you're updating those API keys at the same time that you're running a build or wherever it's being used.

What else? Test, test, test. So if you've got tests for your codebase. Obviously run those. Those are save your baking huge because you can automatically catch those things. If not, run the thing, click around, Make sure everything is good. Like Scott says, you have to, like, know, like, is this major or minor? Am I updating my database or my checkout flow? Those are major for me. Or am I updating a dev tool or like a tiny little format money function where something something may break but it's not the end of the world. Right? So those are it's important to know if these are major or minor.

Watch your error logging. Specifically, I have Sentry in my front end and my back end, and I will just kinda have it open. And and Sometimes something will break and you'll see it spike in your sentry and you can say, oh, okay.

Very clear to me that, that was a that was a botched update and you can roll it back. That's a really nice feature of a lot of these immutable hosts is that you can Just roll back to a working version. Oh, yeah.

You don't have to necessarily roll back a git commit. You can just

Fix forward, I think, is the word that a lot of people do. They say, don't roll back, fix forward. And even better, you if you have TypeScript, you can have TypeScript deny the build On your your you need to go to build it. You can run TypeScript first and say, hey, Mark. Part of your your build pipeline.

Last thing I have here is is just pray.

This kind of comes back to the Yolo update as, just hope that everything thing goes because that's the one thing about using all these dependencies in Node. Js world is that You don't always know what has changed under the hood unless you read every single line of code down the 50 dependency tree lines you have to know. And There was an issue the other day where a popular open source maintainer just kinda nuked his packages and broke a lot of stuff.

But luckily, those were major version updates. And anybody who YOLO updated and didn't check what happened in the major version update.

Kind of on you. Kind of on you. Yeah, totally. Yeah. All right. That's that's my tips that I have for updating a major

major Node. Js project. Hopefully, those are helpful. Anything else to add there, Scott? No. It's funny. We have We've kinda independently came up with the the exact same general workflow for these things without you know, it's not like we sit here and discuss this beforehand. But No. I really end up doing all the same things you do in that. I think that's a good sign that what we're doing is is both practical and reasonable. So Totally. Yeah. Totally. Alright. Well, thanks for tuning in. Catch you on Wednesday. Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.