Instructor: 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.