‫In this lecture,
‫we're going to talk about a bunch of
‫more stuff that you should know
‫about working with npm packages,
‫such as versioning, updating, or deleting packages,
‫and also some other stuff, so let's get started.
‫The first thing that I want to talk about
‫in this video is these version numbers of our packages.
‫Most of the packages on npm
‫follow the so-called semantic version notation,
‫which means that their versions numbers
‫is always expressed with these three numbers.
‫The first one here is called the major version.
‫The second one is called the minor version.
‫The third one is called the patch version.
‫There's actually a meaning in these three numbers.
‫The patch version, which is just this last one here,
‫is only intended to fix bugs.
‫Let's say that in version 1.18,
‫the developers found a bug and so
‫they fixed that bug and then released 1.18.1.
‫Then they found another bug
‫and then they released 1.18.2
‫and so on and so forth until they reached 1.18.11,
‫which is the current version number.
‫Again, this last one here is just for bug fixes.
‫Then after that, we have the minor version.
‫The minor version introduces
‫some new features into the package,
‫but it does not include breaking changes.
‫All the changes that are done in a new version number
‫will always be backward-compatible.
‫If one day the nodemon team, for example,
‫decides to release version 1.19,
‫well, that will then include some new features
‫but it will not break our code.
‫And the same of course happens with this one here.
‫So if some day, there is Slugify 1.4,
‫well then our code is still going to work the same.
‫There will not be any breaking changes.
‫Simply there will be something new,
‫so some new features, which are not just bug fixes.
‫Bug fixes again are for the third,
‫so for the patch version,
‫and then minor new features are for the minor version.
‫Then of course, we have the major version,
‫which is only bumped up whenever it is
‫a huge new release which can have breaking changes.
‫For example, if Slugify 2 comes along.
‫Well our code might no longer work
‫because the slugify function that we have here
‫for example, might have changed its name
‫or maybe the parameter that it expects here are different
‫or the options might have changed,
‫or something might have changed
‫that will break previous version.
‫Be aware that when there is a new version,
‫it might usually affect
‫the code that you already have.
‫Because of that, it is also important
‫to talk about updating packages.
‫In our package.json file,
‫this small symbol here that comes in front
‫of the version number is what specifies
‫which updates we accept for each of the packages.
‫This symbol here, which npm specifies here by default
‫means that we accept patch and minor releases.
‫Now, how do we actually update packages?
‫Well, let's actually quit this process here.
‫The first thing that we can do
‫is to check if there are any outdated packages.
‫We write npm outdated, and that should then give us
‫actually a table with all
‫the packages that are outdated.
‫Well right now, they're all up-to-date,
‫so that didn't really happen.
‫What I want to show you now
‫is that we can actually install
‫a certain package with a certain version number.
‫Let's do that with the Slugify
‫and install it at version 1.0.0.
‫Npm install slugify and then at 1.0.0.
‫Let's try that out.
‫Now indeed, we have one zero zero.
‫When we hover it, it actually says
‫latest version 1.3.4, which is what we had.
‫But if we now run npm outdated,
‫it should then give us that.
‫We see that current is 1.0.0.
‫Wanted is 1.3.4, because that is the one that we accept
‫because remember, that with this here,
‫we accept all the patch and all the minor releases,
‫but of course, we can also change that.
‫For example, we can set it to this symbol here.
‫This will then only accept patch releases.
‫This one is a bit safer.
‫If we run npm outdated now again,
‫let's see what we get.
‫Now the wanted is only 1.0.2,
‫because again, we only accept minor versions.
‫So 1.3.4 is not accepted by us
‫because well, we do not accept
‫any of the minor releases,
‫so again, just patch releases.
‫If you were to do npm update slugify now,
‫let's see what we got then.
‫Now we're at 1.0.2.
‫You see that it changed back
‫for my updating configuration here
‫to accept minor and patch releases.
‫Not just the patch releases like we had before.
‫If we're going to run this now again,
‫it should actually bump us up
‫all the way to 1.3.4, like we had before.
‫Indeed, here we go.
‫All right, that is how we update packages.
‫There are other configurations
‫that we can choose here.
‫We can say, for example, that we want
‫all of the versions, so if at some point,
‫there is a version two and if we didn't update
‫our packages, it will then automatically
‫bump our version up to version two.
‫This one includes all the versions,
‫even ones with breaking changes.
‫But that's not a good idea usually,
‫and so I usually just go with this one
‫that is default, or sometimes even this one here
‫because at some point, even if a minor release
‫should simply introduce new features
‫but no breaking changes, we know that sometimes
‫there can be bugs that developers do not found,
‫and then these bugs, they find their way
‫into our code and might break our code.
‫We do not want that, of course.
‫The safest version is to just
‫use this one for bug fixes.
‫Let's actually just keep it like this here,
‫just for demonstration purposes.
‫This is what you need to know about
‫version numbers and updating.
‫But we can of course also delete packages.
‫Let's now go ahead and install Express,
‫so that we can then go ahead and delete it after that.
‫I'm sure that you can guess how we can do that.
‫That is very easy.
‫Npm uninstall, so it's actually not called delete.
‫It's really uninstalling.
‫We install and we uninstall Express.
‫That will then delete it from
‫our node modules folder, and also from
‫our dependencies in a package.json file.
‫Each time we decide not to use a module anymore,
‫well, we should always go ahead and remove it,
‫or actually uninstall it.
‫Now as a final thing, I want to talk a little bit
‫about the node modules folder.
‫This folder, which contains all
‫the dependencies of our project.
‫Let's say that you want to share your code
‫with someone, or that you, for example,
‫want to start working on one computer
‫and then move to the next one.
‫You will never share this node modules folder
‫because this code, you can easily get it from npm.
‫There's no need to go ahead and copy
‫all of this code here, for example,
‫to a GitHub repository or to a Dropbox folder,
‫or really somewhere that you want to share your code,
‫because this folder here as you see
‫has tons of folders and each of them
‫might have tons of files.
‫All of a sudden, you might end up with
‫tens or hundreds of thousands of files.
‫You should never share this folder
‫and never check it out into your GitHub repository.
‫Let's say that you uploaded this code
‫to your GitHub account without this node modules,
‫or you put it into a Dropbox on one computer
‫and downloaded it at the other one.
‫Let's say we now downloaded this code here,
‫so without node modules.
‫So we delete that one now
‫and end up with just a regular project folder.
‫How do we now get back our dependencies
‫or our node modules folder?
‫Well, it's very easy.
‫All we have to do is npm install.
‫What it did is to read our package.json file,
‫read our dependencies, and then download everything
‫back into this folder, all right.
‫Now one important piece of this puzzle
‫is the package-lock.json file.
‫If we open that up, we get a list of
‫all the versions of all the packages
‫that we're actually using.
‫That includes the dependencies of our dependencies.
‫Let's go to Slugify, for example.
‫Slugify, and so here we see that
‫we're using version 1.3.4.
‫That is very important because
‫if you share your code, you want the other developer
‫or even yourself to be using
‫the exact same package versions,
‫so that your code works the exact same way for you
‫and for the other developer.
‫For that, the exact version numbers
‫are basically set in stone
‫in this package-lock.json file.
‫If you share your code, no matter if you're using
‫GitHub or Dropbox or something like that,
‫always share your package.json file
‫and the package-lock.json file
‫because these two files are necessary
‫for the other developer to then reconstruct
‫basically the node modules folder.
‫Yeah, I think that's all you need to know
‫about package versions, updating,
‫uninstalling, and also sharing code with npm,
‫package.json and package-lock.json.
‫If there's anything more that you want to know,
‫you can again always ask in the course Q and A
‫and then you'll get help there.