3. Download it locally, add a package.json and publish it to npm

[filipedeschamps]

I recommend you to do this before start coding to ensure that you will have the same name in Github and npm.

Clone your repository locally

You need to download this brand new repository to your machine. To do this, click in the Copy to clipboard button to copy the address of it.

In your terminal, type this (replacing my repository address with yours):

$ git clone git@github.com:filipedeschamps/repository-demo.git

Add a package.json file

This is a manifest of what is your module about to the Node.js community. Also, it will tell which dependencies your module needs to be able to run (third party modules) and handy scripts to automate some testing and building routines.

So, the easiest way to do this is to use npm to create the file for you. Inside your repository, type:

$ npm init

It will guide you (press enter to use the default value suggested by npm):

Great, now there's a new file called package.json inside our repository. It will be very sane of your part to commit and push it to Github.

Publish to npm

To be able to publish modules, you have to be authenticated in npm. To do so, type this in your terminal:

$ npm adduser

It will ask for a username, password and email:

If everything is ok, you will be logged, type npm whoami to double check:

Now, to publish your module, simply type this:

$ npm publish

And it's done :+1:

Just notice that I had to change the repository name to repository-demo-tutorial inside my package.json file because repository-demo was already taken in npm

Next step

4. Scratch the public interface of your module

[rafaelrinaldi]

@filipedeschamps Great guide, Fillipe! However, I disagree on this particular topic. Releasing a module under v0.0.1 to the registry just to make sure your module name is yours? That's just bad advice. There are plenty of abandoned packages named as canary modules rotting in the registry simply because the author did exactly what you're suggesting here.

I would recommend only publishing after you at least have a working version of your module (first version of the API is somewhat working).

If by the time you want to publish your module that name is already taken in the registry, you can publish it publicly as a private npm module. If you don't like to publish it under your user name, use an org name.

Cheers and keep the good work!

[filipedeschamps]

@rafaelrinaldi it's an honor to receive a comment from you.

You have a great point, but I believe the name and matching urls are a really important part of your project, for me it's as important as a regular domain name.

About abandoned modules, I think the spectrum of reasons behind it are big and rotting modules will always be a part of the nature of open source development. If this is a real problem to the public namespace, I find having a cleaning mechanism a better solution then relying on human behavior. For example, if you have a module for more than a year, without nothing more than a package.json, no downloads, no commits, no nothing, your have to active claim it yours somehow, otherwise it will be cleaned from the registry.

Or any other idea that you don't need to control the input relying on human behavior :+1: