DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for How To Publish an NPM Package in 2020
Dorin
Dorin

Posted on • Originally published at fodor.org

How To Publish an NPM Package in 2020

Introduction

In essence, publishing an npm package is just one command, but there are some things that you have to take care of before doing that.

Step-by-Step

Here are the steps I followed before publishing my first package:

  1. Create a free account on https://www.npmjs.com/.
  2. Log into the npm CLI by running npm login.
  3. Create a folder for your new package which would normally have the same name.
  4. Make sure that you ran npm init and have all the right values filled-in in the package.json file.
  5. Carefully choose the name, as that is going to be the name that everyone is going to use to install your package.
  6. Set the version number using the semantic versioning format. It should look something like this: β€œv1.2.3”. The first number is the major version and should be incremented every time you deploy a breaking change. The second number is the minor version and should go up with every new non-breaking feature. And, lastly, we have the patch/fix number. Also, at the same time, create a new release in GitHub (or your other VCS) with a matching version. (Read more)
  7. Add a types field which will point to your types definition file. You don’t have to do this step but with the rapid increase of TypeScript and better IDEs, you are doing the developer a big favor. The types file will be a *.ts file written in TypeScript and describing the types, interfaces, etc. of your package. (Read more)
  8. Specify the place where your code is hosted by filling in the repository field. (Read more)
  9. Have a think about how you want to license your package and set the correct license value. If you are not sure, go to this website https://choosealicense.com/ which will make this very easy for you.
  10. Check your .gitignore file and verify that you are not including any personal or unnecessary files in your repository.
  11. Add an .npmignore file which will exclude specific files from your npm package. I personally have added the test files in here, as we don’t need to have them in the package.
  12. Take your time to write a nice README.md file, where you explain to your future users how to install the package, how to use it, and maybe give some examples. The contents of this file will also appear on this website.
  13. Now you’re almost ready to publish, but before you do so, run npm pack, which will generate a *.tgz file containing all the files exactly how they will end up in your npm package. This will let you double-check that everything has been set up correctly and you are going to publish the right thing.
  14. Just before publishing, you are going to run a quick test locally. Create a new folder, initialize npm (npm init) and install your package with npm install -S ./path/to/your/package. This will install the package from your local directory and you can try to use it as if it was already published.
  15. Assuming that you have done all the steps above and it all worked as expected, you can now publish your package with npm publish.

Conclusion

Congratulations, you now have a brand new npm package.

You can see your package on npm like so: https://www.npmjs.com/package/inline-webassembly

Top comments (11)

Collapse
 
joshuatz profile image
Joshua Tzucker

Great post! I like posts like this that get straight to the nitty-gritty of how to get things done.

Just a word of warning though, since you have both .gitignore and .npmignore as steps: these actually can conflict with each-other, and NPM will let .npmignore completely overwrite rules in .gitignore.

For example, if you ignore a password file in .gitignore, but then add a completely empty .npmignore file, the passwords will still end up in your published package (but not on Github).

Collapse
 
dorin profile image
Dorin

You're right, this could potentially lead to confusion, but I think that this is intended behaviour.
The .gitignore file is only for choosing what doesn't get commited to your git repository and .npmignore lets you specify what shouldn't get published to npm.

Collapse
 
joshuatz profile image
Joshua Tzucker

πŸ‘ Yeah, I like that description of the differences!

Collapse
 
alextremp profile image
Alex Castells

Good post πŸ‘Œ
Also for mention, it would be preferable to don't publish from a local repository, but from a CI platform instead.
For (my) open-source libs I've automatized some steps by using another open-source lib I've created for publishing via GH release tags πŸ™‚
Take a look and feel free to contribute
npmjs.com/package/versiona

Collapse
 
dorin profile image
Dorin

Great work! I'll check it out :)

Collapse
 
mbrtn profile image
Ruslan Shashkov

Too much overhead for now, unfortunately. Hope in 2021 it would be much easier.

Collapse
 
dorin profile image
Dorin

Let us know in 2021 :)

Collapse
 
mbrtn profile image
Ruslan Shashkov

With pleasure :-)

Collapse
 
portenez profile image
Victor Garcia

I wrote a pretty comprehensive post of how to automate this in gitlab ci.

vgarcia.dev/blog/2019-11-06--publi...

In case anyone's interested.

It covers typescript, testing, and using semantic release.

Collapse
 
ben profile image
Ben Halpern

I love posts like this

Collapse
 
jjjimenez100 profile image
Joshua Jimenez

Good post. Direct and concise. Thanks a lot! :)

Stop sifting through your feed.

Find the content you want to see.

Change your feed algorithm by adjusting your experience level and give weights to the tags you follow.