Today I published a new package on npm: xcfg.

It’s a cross-platform config file management package that’s fairly simple, but pretty useful for those who write Node.js applications such as command-line utilities or desktop software in the form of Electron apps.

Since all the details of the project are on the package page, this entry will just cover the technology I used to create it.

JavaScript (ES2015)

First and foremost, this is a JavaScript package for the Node.js ecosystem, written using the ECMAScript 2015 standard. I had explored Python 3 recently, but ultimately decided to move forward with the Node.js ecosystem. I was momentarily torn between the two, because I think Python 3 is a fantastic language. However, I’m vastly more comfortable in JavaScript, and I’m a big fan of Node’s package manager (npm). Conversely, I really don’t like Python’s distribution story. In fact, I think it’s a nightmare compared to the npm experience.

Case in point: I started writing xcfg yesterday evening and finished up the remaining tests and documentation this evening before finally pushing the project onto GitHub and running npm publish. It’s a small package, so that’s obviously why I was able to finish it in such a short amount of time, but the process of setting up a package.json and publishing to the npm registry was an absolute breeze. Publishing added only a very minimal amount of time and effort on top of coding, writing documentation, and adding unit tests.

Documentation and Testing

As far as documentation goes, I put some basic usage info in the project’s README and used ESDoc for the API docs. ESDoc looks great by default and has a familiar set of tags so it wasn’t difficult to use, despite never having used it previously. The only problem is, out of the box, it doesn’t work for Node.js projects but that was easily fixable with the esdoc-node development package.

For the unit tests, I used a combination of Mocha and Chai and at version 1.0.1, there are 10 unit tests (all passing, of course). I thought Mocha was pretty good but I may explore other assert libraries for my next project because Chai has a strange API and was a little annoying to validate with my chosen style guide, which brings me to my chosen…

JavaScript Style Guide

I personally believe it’s important for a project to follow a style guide. Not only does it make it easier for multiple people to work together on a single codebase, the consistency that a style guide enforces really helps improve programming discipline and ultimately results in less bugs in the final product. Given JavaScript’s dynamic nature, following (and linting with) a style guide is a great—if not essential—way to prevent a whole class of (stupid) bugs.

I recently discovered the JavaScript Standard Style and chose to follow it for xcfg. The project has it as a development dependency and can be linted with a simple npm command: npm run lint. I found that I agreed with all of its rules, even the more controversial decision to disallow extraneous (in other words, most) semicolons.

And that concludes my technical overview of xcfg 1.0.1. If you find any value in this package, please take a moment to star the GitHub repo.

HostGator $3.96

$3.96 for web hosting – used by jonbeebe.net. Get started today.