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



Existing egghead members will not see this. Sign in.

Publish npm packages using npm publish

1:29 JavaScript lesson by

In this lesson we will publish our package. We will first add a prepublish script that runs our build script; this will ensure the built folder gets added to npm when published. We will also add a .npmignore so that only our built files get installed. We need to run npm adduser to log in to an npm account. We can then run npm publish to publish our package and view it on npm.

Note: if you want to actually publish the package from this course, you'll need to rename it since sensitive-words is already taken. You can use a scoped package name for this as well.

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

In this lesson we will publish our package. We will first add a prepublish script that runs our build script; this will ensure the built folder gets added to npm when published. We will also add a .npmignore so that only our built files get installed. We need to run npm adduser to log in to an npm account. We can then run npm publish to publish our package and view it on npm.

Avatar
Brent

Maybe obvious to everyone, but you may want to mention that they need to change the name of their package since there already is a "sensitive-words" package.

In reply to egghead.io
Avatar
Trevor

Thanks Brent, I'll add that to the lesson description. I feel the error message when you run npm publish should be helpful as well as it tells you what the problem is and that you need to rename the package :)

In reply to Brent
Avatar
magnus anderssen

I'm sad to see the there is no discussion around the dependencies versioning. I believe the '^' is a bad practice in the npm community as it may result in broken builds in you project because of a bad "upgrade" of a dependency of dependency. It also completely destroys the possibility of obtaining the exact same build as the one in production in order to reproduce production issues locally (e.g. with instrumented for debugging code).

Avatar
Trevor

Hey Magnus, I agree with you which is why I use Yarn in my personal projects with a yarn.lock. I would imagine you are already familiar with this, but if not here is an egghead lesson on it: https://egghead.io/lessons/javascript-yarn-a-javascript-package-manager

In reply to magnus anderssen

Let's open our package.json in our code editor and inside of our scripts, let's add a new script called pre-publish. Let's have this run npm run build. We need to make sure we add a comma above. Now what this will do is whenever we run the npm publish command it says, "before that's run, run this," which npm run build will run our build script.

This command is going to ensure that when we publish a package it has our latest build. Next, let's create an npm ignore file. Inside that file let's add the source directory. This tells npm to install everything except for what's listed in the gitignore and the npm ignore.

If we didn't have this source here, every time someone npm-installed our package in their node modules inside of their project they would also get all of our source files. Now let's save and close this file and go back to our terminal. Now let's run npm-adduser.

We type in our username and our password, our email. Now it says that we've been logged in to the npm registry. Now we can run npm publish. We can see that our build script was run and we can open up npm and view our package.

It shows our package name, description from our package.json as well as the example from our readme document. Now other programmers can run this command and use our package.

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