Free hosting for open source Node.js packages
Maybe you have come up with a bit of code and you want to share that with the world. Maybe you use the same code time and time again, which you want to store somewhere. Well, the good news is, there are places out on the internet that will allow you to store, build and publish packages for free.
There is a catch though; you do need to make everything you do public. If you want private repos, packages and builds, you are going to have to pay.
In this article, I walk you through how to easily get started with a method that works for me with minimal effort. If you are a busy person and would just like things to be set up for you automatically, you might also want to check out the Yeoman generator, which does a lot of the work for you.
GitHub
First of all, we are going to need to store our code somewhere and set it up for version control. If you are creating an open source Node.js package, then there is no better place than GitHub. There are obviously other choices out there, such as GitLab and BitBucket, but GitHub really is the place to go for open source. This might, of course, change in the future, but for now, we will stick with GitHub.
npm
Next, we need to publish our package and it will be no surprise that we are going to push it to the ‘official’ Node.js repository at npmjs.com. Once you have your package published there, anyone (including you of course) will be able to install it without needing to setup anything else. If you want your packages to be private, then there is a payment option too.
npm install <package name>Travis CI
Ok, so we can store the code and we can publish it using ‘npm publish’, but its a bit of a chore to do this manually every time. It certainly doesn’t follow the pattern of good DevOps or CI/CD. On top of that, we are having to update the version number manually as well. We need a build server!
Enter Travis CI, which not only syncs up with GitHub, but is entirely free for open source projects. This means we can use the full power of our build server to build, test, version and publish our packages; all automatically. You will need to go into Travis, sync your projects and enable builds for your repository before doing anything else.
Travis CI works in a similar way to other build tools, which keeps the build definition as a yml file in the code repository itself. The build definition is essentially just a list of shell commands and here is the one I am currently using for my own projects:
The Build
With a few tweaks, you can use this for your own project (mainly changing the repo name), but let's step through some of the important bits and see what's going on. Obviously, you don’t have to do everything in the build and you can add your own bits too. The important thing is that the ‘.travis.yml’ file is at the root of your directory or Travis won’t work. Notice specifically, that there is a dot at the start of the file name.
script
First, we audit our package to make sure there are no security vulnerabilities:
npm auditNext, we run eslint against it:
npm run lintFinally, we run our tests:
npm testThe final two commands are just shortcuts to a script in our package file. To keep the article short, we won’t go into details about setting up unit tests and linting.
before_deploy
Within the next section, we set up git, so that we can not only pull down the code but also commit the updated package file with the new version number that we generate. To do this we need to set the remote to include our GitHub username and a token, which have the environment variables of:
$GIT_HUB_USER
$GIT_HUB_TOKEN
These are just environment variables I have named myself inside the settings of the Travis project. One downside to Travis, unlike other similar tools, is that there are no global environment variables. This means you are going to have to set the same tokens up with each project.
To get hold of your GitHub token, you will need to head over to GitHub and log in. Then click on your profile picture, hit setting and then go to the Developer settings. Next select Personal access tokens are you will have the ability to create a new token. Make sure to give it a good name, so you can identify what the token is for.
versioning
To version our package, we just use the inbuilt npm command:
npm version patchThis will increase the final number of our semver (1.1.x) and export it into a variable to be used later on to tag out commit. This command will update the package.json with our new version number and later on, we will want to push this to our repo. In terms of versioning packages, I take a fairly simplistic approach. I always update the patch number so that there isn’t a conflict with npm and when I need to update the major or minor number, I will do this myself. There are lots of ways of doing it, but this is what I use for simple packages. You are going to need a more detailed approach when your project grows.
deploy
Travis nicely has a plugin to deploy to npm for us; we just need to specify a couple more environment variables and a token to set this up.
Under no account store your tokens/secrets inside of your code, even if it isn’t public!
To get an npm token, login to npm, hit your profile picture and click on tokens.
Create a new token and then update your environment variables. You will need to set up all your variables before committing your yml file or the build will fail.
after_deploy
If everything has gone well so far, we are safe to push our changes to git and tag it. Viola!; your package will now automatically publish with every commit to the master branch.
GitHub Pages
Finally, a quick mention needs to go to GitHub pages, which allows you to store static sites for free. This is perfect for your api documentation, such as that output by jsdocs.
Please share with all your friends on social media and hit that clap button below to spread the word. Leave a response of your favourite tool and why. 👏
If you liked this post, then please follow me and check out some of my other articles.
About
Matthew Bill is a passionate technical leader and agile enthusiast from the UK. He enjoys disrupting the status quo to bring about transformational change and technical excellence. With a strong technical background (Node.js/.NET), he solves complex problems by using innovative solutions and excels in implementing strong DevOps cultures.
He is an active member of the tech community, writing articles, presenting talks, contributing to open source and co-founding the Norwich Node User Group. If you would like him to speak at one of your conferences or write a piece for your publication, then please get in touch.
Find out more about Matthew and his projects at matthewbill.gihthub.io
Thanks for reading!
