Going down the path of node package creator - guide to create npm package and publish it to npm repository.
NVM to the rescue
Before diving into the package creation I’d like to recommend nvm, a tool for managing separate node versions/environments on your local computer. I especially like it for storing my global npm packages like yeoman or even npm itself under
~/.nvm/... directories and not under
/usr/lib/node_modules which I like to keep simple and su-rights-protected.
Ok, nvm is installed let’s dive into package creation.
Creating package from scratch? No. Yo!
require? And what’s this badge ? Automated building? Cool, how do I configure it? And how about test framework? And mocks?! Wait and what license should i choose?!
You got it. Creating a npm package is a process of overwhelming amount of decisions. Decisions someone else must’ve already undertaken. And luckily some of them shared their effort in a form of yeoman generator.
So let’s generate the package
At the time of starting my package the generator-np seemed promising, though it is a bit out of date today: . It solved most of the questions above for me. As written in the description of the generator:
kub1x/rodnecislo cloned in
rodnecislo directory and start the generator as follows:
The generator-np still asks some questions, which need to be answered. Following are my answers and the reasoning behind them.
What is the URL of your website?
https://kub1x.github.io/rodnecislo/ Go to github pages, scroll under the video tutorial, click “Project page” and follow the instructions. Your url will have this form:
Do you need .travis.yml?Yes. Got to Travis-ci. Create an account. Enable for your github repository. Get emails whenever you push to master something, that breaks your build, lint or tests.
Do you need setup for coveralls?Yes. You don’t need to do anything (except writing your tests…) to see beautiful visualisation of your test coverage on your coveralls page.
Do you need setup for commitizen?Yes. It feels really neat to have standardized format of commit messages. Better for cooperation, readability, confidence, automated tools… simply better. Using commitizen you basically do
git cz and follow a short wizard instead of doing
git commit -m “some messy message”. The resulting message looks like this:
build(travis): Add node version 7 to .travis.yml. See commitizen page on how the system actually works. It defaults to angular commit standard, that is described here. Tough I find it much more helpful to get the notion from the actual commit messages in the angular repo.
Do you need automatic github releases?Yes. This gives us a great benefit of generated releases. The tool for it,
conventional-github-releaser, tells you exactly what to do to, which itself helps so much, that I can’t resist repeating it here (just a little more specific). Going from version
- Make a change
npm run verify
git czthe change
- Make sure Travis CI turns green
- Repeat until enough changes to call it a version ;P
npm loginwith your npmjs.org account. I failed to do this and accidentally published my package as a wrong user ;)
npm run majorOR
patch- does all the following for you:
- Run tests, verifications, etc.
- Bump version in package.json, commit, create git tag and push it
npm publishto npmjs repo
npm run github-release- creates the nice release report on github mentioned earlier
- Celebrate… and maintain.
Do you need CLI?No. As I’m writing npm library rather than console tool, I don’t expect it being used from command line. But for the sake of completeness the
cli option of the generator creates this file in your package’s
src directory and adds
meow to your deps. That’s it.
Aaaand we’re done… Almost
After the generation process finishes the whole project is automatically being set up. The template itself takes care of
npm install, running your first build, lint, tests, and checking for outdated dependencies using npm outdated. I recommend reading the output of the generation process as there is practically everything you need to know about your newly generated package, especially the npm scripts being called. At the time of writing, some of the packages are outdated downright after the generation due to inactivity of the maintainer (perhaps someone could offer him a hand ;)). To fix this use npm-check-updates tool:
Now this is just the beginning. Even the first version of the module took quite some time on research, programming and writing. I’m kinda wondering how maintaining of it will go, so about it later.
npm install rodnecislo and go opensource.