Enter Your Email Address to Watch This Lesson

Your link to unlock this lesson will be sent to this email address.

Unlock this lesson and all 986 of the free egghead.io lessons, plus get JavaScript content delivered directly to your inbox!



Existing egghead members will not see this. Sign in.

Releasing a new version to npm

3:24 JavaScript lesson by

When you want to add a new feature, fix a bug, or push out a breaking API change, you need to take Semantic Versioning into account. In this lesson, learn what each number means as well as how to push out a new version of your library.


egghead.io comment guidelines

Avatar
egghead.io

When you want to add a new feature, fix a bug, or push out a breaking API change, you need to take Semantic Versioning into account. In this lesson, learn what each number means as well as how to push out a new version of your library.

Avatar
Jasper Moelker

The npm version (in this case npm version minor) would simplify this workflow. See https://docs.npmjs.com/cli/version .

Avatar
Kent C.

Hi Jasper, you're correct. However, you'll find in future lessons that we wont need to manage the version ourself at all πŸ˜€ πŸ‘

In reply to Jasper Moelker

In this lesson we're going to talk about pushing an update to our library. Let's say that in our Star Wars names JSON, we want to add Anakin's mother's name.

Her name is "Shmi Skywalker." We need to publish this out so people will start getting Shmi Skywalker as they get random Star Wars names. To accomplish this, we need to update our package JSON. We need to bump up the version.

If you read into SemVer you'll learn that each one of these numbers has a very important meaning to computers. The first number represents a major version. That is bumped whenever you have a major release, being a breaking change of some kind.

For example, if we were to change the name of this from all to get all, that would be a breaking change. Therefore it would require a major version change, so that we would change that to two. But our API is saying the same, so we don't need to bump that one.

The second number represents a minor release. Minor releases are associated to new features, but no breaking API changes. Our APIs remain the same. We are adding a new feature being a new person in our list of names. In our case, we would bump this version. We'll bump it up to one.

The last number is for a patch release. This is a bug fix. Let's say that for some reason we had a problem in our unique random array implementation. There was something wrong there. If we fixed a bug there, that would be grounds for updating the patch version. We're adding a new feature, so we'll bump that version.

Let's do a get status, make sure we've changed the things that we're expecting, and get diff. We see those are the only two things that we've changed. If we get add, everything that we have modified and we check our status, we have those two things staged. Now we'll go ahead and do a get commit with the message updating Star Wars names, adding Shmi Skywalker.

Let's go ahead and we'll do our tag for the get hub portion of this, so 1.1.0. We'll do get push. We'll push up the change commits. We'll get push our tags to push up the tag, then we'll run MPM publish. We'll publish the new version. As soon as that's finished, we can run MPM info Star Wars names.

If we look at the available versions here we see 1.1.0, and that is the latest. That is how you push an update. In review you simply make the update, then you update the version according to semantic versioning. We updated the minor version because we're adding a new feature, a new name.

You commit that code. You add a tag to that commit. You push that to get hub. You push the tags to get hub, and then you run MPM publish, and that will publish the new version. That is how you push a new version to your library.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?