Creating a NodeJs package for NPM

NodeJS and npm are among the fastest growing development platforms and communities. This is primarliy because NodeJs as its name implies is a javascript-based development ecosystem, which takes advantage of the fact that javascript is one of the most widely used languages today. While I don't have any links, I wouldn't be surprised if some metrics show javascript as the most widely understood programming language. Almost every developer learns javascript because almost every developer at least attempts to build a javascript-enhanced webpage at some point. For this reason, I thought it would be a good idea to make some npm packages so that I could gain some mastery over the NodeJS ecosystem. I had worked with NodeJS in the past to setup a integration test system and to use various common or custom command line tools, but I had never created a package.

Wikipedia says the "Node.js was originally written in 2009 by Ryan Dahl", but as I recall it probably wasn't until about 2012-2014 that the tech started getting more mainstream press and blog posts. Because Node.js was built to work on Google's V8 engine which allowed Node.Js to be used whether Google's V8 engine has an implementation, which I guess is most major OSes and platforms. Now not only can a developer use javascript outside a client-side web site, but also NodeJs has a web server implementation. This means that javascript could be used in a web-app both on in the client-side and server-side code. While that's not that important to me, it does open up the possibility that some of the repitition between client-side and server-side code could be eliminated.

NPM is node's package manager system, its like NuGet for .net or RubyGems. This type of package manager allows developers to easily publish software packages and libraries, and for consumers of those libraries to easily install them. Npm was created initially by Isaac Schlueter and it's first release was in January 2010The only bad thing I can say about npm is that there logo policy is so defensive, I'm not even sure if I can put an image of the npm logo in this article without getting an angry email.

To practice using NodeJs and npm's packaging system I wanted to choose some functionality that would actually be helpful to someone. When I'm reading a stack exchange article and I notice a plain text link, sometimes I will replace that plain text link with a linked text title. So an article with the plain text link '' in it would become 'Google' or perhaps a full referenence like "'Google',". Unfortunately I learned that because Stack Exchange is hesistent to allow public automated editing, in order for a stack exchange app to update an article a full website login is needed, making automated editing less desirable or possible. Therefore I narrowed the scope of my learning engagement to performing all of the actions of stackexchange link replacement with the exception of the actual update to the article. I broke the task down into 4 separate packages to maximize the potential that someone will actual find one of the packages useful and download it. Each of the 4 packages is configured with a package.json file.

Package.json is the backbone of any npm package, its the base-level config file. If your familiar with the .net package system, the package.json file is like a combination of a visual studio project file, and a nuget spec file. One the primary functions of the package.json file is management dependencies. The nice thing about npm packages is that its incredibly easy to include references to other projects and to have those references automatically installed when your package is install, so that it automagically works every time. There are different string parameters that can be used to specify whether to be specific about the version of the dependency or allow newer or different versions to be installed instead of the specified version. Package.json can also be configured to install some dependencies only for development, in case you want to setup some special dev tools.

Testing is built-in to the design of npm packages. A script or series of commands can be configured to run when the test command: npm test is executed. This also allows people to chain a series of test commands together so that a series of testing systems can be activated. In this manner, I not only wired up tests but also a vulnerability scanner and style checker, among other widgets. These are run whenever I make a new commit by the free TravisCI server, or can run them at the command-line with a simple 'npm test'. The vulnerability scanner I have configured to run during check-in and test, snyk, has already altered me to 2 new vulnerabilities in the request package, which is the goto package for web requests. Sadly, in my stack-exchange-markdown-retriever project, I have a dependency on the stackexchange and I have haven't been able to the package owner to update his request version, even though I created a pull request to help him. The package owner may not have an interest in their stack-exchange package project anymore, so I may have to replace his package with direct calls to the stack exchange API.

Publishing a npm package is fairly straightforward and like NuGet is open to submission from any registered user. You simply have to register with the npm website to receive an API key used to publish one's package on the NPM network. Unlike NuGet however, npm doesn't allow duplicate package names to be used, I'm looking at you people who stole the name "Random Name Generator" for my NuGet package. My package was registered first so I feel certain ownership for what that's worth, which isn't much. The documentation for publishing to npm is fairly well written and presented which is a hallmark of a framework that's going to be around for awhile.

Likewise updating an npm package is fairly easy. The npm version command is used to update the version number in the package. The cool thing about many of the npm commands, like 'version', is that if one's project is in the GIT repository many npm commands will automatically execute commits and tagging. So the npm version will actually create a commit and a tag for the version automatically when its called. There are other examples of GIT integration but yet another reason why the npm/nodeJs platform is both powerful and modern.

Here's some lines to the npm packages I've created:

So creating a nodejs npm package is not that tough, nor is maintaining one. NodeJs is a technology that turns javascript into an all-ecompassing server-side and browser-side languages. In some ways Javascripts it the only language for which is the possible, because its the only programming language that it explicitly implemented in all modern browsers. Javascript while not the most web designed language ever created, at least takes advantage of some of the C++/Java idioms that make it understandable to even first-year computer science students. I expect that the NodeJs platform will likely be a powerful slice of the web development market for at least a decade or more, so learning more about it has a fair chancee to be useful in some way for one's self.


First posted on 8/11/2016 7:47:30 PM