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 833 of the free egghead.io lessons, plus get JavaScript content delivered directly to your inbox!

Existing egghead members will not see this. Sign in.

Just one more step!

Check your inbox for an email from us and click link to unlock your lesson.

Publishing a beta version

3:37 JavaScript lesson by

Sometimes you're not quite ready to release a full on version of your open source library to npm. In this lesson, learn how to publish a beta version so people can try it out without tampering with anyone else using your library.

egghead.io comment guidelines


Sometimes you're not quite ready to release a full on version of your open source library to npm. In this lesson, learn how to publish a beta version so people can try it out without tampering with anyone else using your library.


What is the general approach if you have beta running say 1.4.0-beta.0 and then someone else in the team finish another feature and want to bump the stable version 1.3.0 to 1.4.0 ?

In reply to egghead.io
Kent C.

There are a few approaches to this. Most of the time, my beta releases are short lived. I recommend this in general. So you could add this new feature to the beta and hopefully it would be released officially soon.

If you want to have the new feature, but keep the beta version, then you may consider putting your beta versions in a separate branch, then when there's a new regular version, simply rebase the new feature in your branch, and release a beta version of the latest version.

So, in your example, you'd rebase the new feature, then release a 1.5.0-beta.0

But you have quite a bit of flexibility to do things how you want. AFAIK, there is no "standard" or "accepted" way to do this.

In reply to Nils

Now let's say we want to publish a beta version of our library. The way that we accomplish this is pretty much the same as if we were publishing anything. Let's go ahead and make the change. I'm going to go ahead and add "Kent C. Dodds" here.

I want to push this out as a beta, because I'm not sure if people would be happy to have my name in here. I'd like to have people test it out, but not have it be the default version that's installed.

We'll go into our packaged JSON, and on the version, we're going to bump it just as if it were a normal release. This is a new feature. We'll bump the minor version. Then, we're going to add "-beta.0" to the end of this. We can increment that zero as much as we like. This "beta" in the version, indicates that this is a beta version, so user beware.

Now, let's go ahead and check out the diff. These are the only things that we want to change. We'll add all the changes, and we'll commit those. Adding "Kent C. Dodds." Then, we're going to GetTag that commit with 1.4.0-beta.0. We'll push those commits out to GitHub, then we'll push the tags.

Then we'll still do an npm publish, but we'll add the tag "beta." We push that up, and when that's finished, if we run npm info, we can see all the information about the versions here. We have our beta version there.

Our latest is still pointing to the solid version of 1.3.0, but our beta version, or our beta tag, is pointing to 1.4.0. Now, if we change our directory to the desktop, and if I run npm install Star Wars-names, then we'll see that we install 1.3.0.

If I'm living on the edge and I say, "npm install Star Wars names at beta," then this will give me the 1.4.0-beta. Then, obviously, I can also install the specific version 1.4.0-beta.0. That will allow me to install that specific version. By using the beta, we'll install the latest beta tagged version.

That is how you release a beta version. When we're ready to go with the next version, we simply remove this beta, and we publish the new version without the tag, and we're good to go.

In review, to publish a beta version, you simply make all the changes that you would for a regular release, whatever it is that you want to release in the beta version.

Then instead of a simple version bump, you do the normal version bump that you would, in our case, we bumped the minor version, because it's a new feature. Then you add the -beta.0. This is what you will increment as you iterate on your beta versions.

Then, you commit your changes, you add a tag with the same version, and then you push those up to GitHub, and then you run npm publish--tag, and then beta. That will push it with the beta tag.

Then, when users install, if they aren't aware of your beta versions, or they don't want it, they simply get the latest stable version. Then, users can install the beta version if they so desire.

Joel's Head
Why are we asking?