3 Tips for Efficient Node Module Development
By: Seth Urban
Tags: JavaScript, Webdriverio, Productivity, Test Automation, Nodejs

For the last year, I’ve been working as a Test Architect at Northwestern Mutual. Although I have used Webdriver in the past in C# and Ruby environments, this was my first time working almost exclusively in JavaScript or more precisely NodeJS. Working in Node is a little bit of a different animal than either Ruby or C#, as you might already imagine or know.

When I came into the team, one of the main problems I was experiencing is how to evaluate the changes that I’ll need to make to the test framework in an efficient manner. Changes need to be made, and then tested, and then evaluated in a test project.

In an effort to speed up the development time and learning curve for other engineers getting started building Node modules, I have compiled a small list of tips that may help.

Automate the Node Package Install

The test framework and tools that my team and I have been building for Northwestern, are all built as Node modules. These modules are then hosted on an internal Node repository that other engineers have access to. All they need to do to use the modules we are building is to run npm install. (After they set their .npmrc file of course!) . This is how I primarily verify the changes to the module as well, by installing the module in a test project.

It’s worth noting that when you’re installing a package from a Node repository that packages that are already installed at the same version will not be reinstalled. Conversely packages that are already installed but no longer listed in the package.json file or its dependencies will not be removed. This is a great timesaver if you just want to add a new package, or reinstall updated versions of packages.

If the module you are building uses pre-install or post-install scripts, you may not find problems your users will be experiencing when they install your module. Also if you’ve changed your module dependencies significantly, you may have lingering packages in your test project that could be effecting the functionality of your module. This lingering package problem has tripped me up more times that I want to admit; which is actually the reason I decided to automate this.

The above script is incredibly simple. All it does is remove the node_modules directory from the current project, as well as the package-lock.json if it exists and then re-install everything from the package.json file in the project directory. Although it’s simple, when you add this script to an alias in your ./bash_profile it makes this whole process super easy whenever you need it.

I have my Node Nuker script aliased to nn in my terminal, so a quick reinstall is just two characters away at anytime. You’ll no longer get tripped up with lingering packages or not installing new dependencies again.

File Path for Modules

This simple tip, that surprisingly few people know about, helps out when you want to test changes made to one module, in another test project. You can simply add the file path to the module in the test project’s package.json file.

You can load the module from anywhere on your disk, as a dependency to the test project. This is incredibly handy when you don’t need to worry about evaluating install scripts, or adding or removing dependency modules to your package.

You will still need to run the install process in the project you’re installing your development module into. However, you only need to install it once in this scenario. Any changes you make to the module locally, will be automatically used by the project using the file dependency.

In fact there are tons of different ways to add dependencies that may come in handy, check this out for more information:

https://docs.npmjs.com/files/package.json#dependencies

Local Registry for Everything else

Sometimes you really want or need to test that your module behaves correctly from the second it’s installed into your users project. At Northwestern, we are building modules with a lot of pre and post install scripts, that do a lot of heavy lifting for our test engineers.

For example, one of our framework modules checks to see which operating system the user is on, and installs a series of 3rd party tools onto the machine in specific ways after the module is installed. If the user is trying to install this module on Ubuntu or OSX, the post-install script will execute a bash script to install the 3rd party software. If the user is on Windows, the module needs to trigger a PowerShell script. Of course if the module is installed on our CI environment there is a whole other set of things that need to happen.

Sometimes there is really no substitute for installing the module from a repository. However, you don’t want to submit your module change to Code Review until you know it’s working. That’s when a local registry running on your machine will come in handy.

Personally I like to use Verdaccio since it’s super simple to get started and already has a dockerized version available. Once again, I’ve created a bash script to start up my local Verdaccio registry for me whenever I need it.

Setting this up to another alias in your ~/.bash_profile will let you start up a Verdaccio instance really quickly. Then all you need to do is publish the module you’re developing to the local registry and install it into your test project.

The local registry method is a bit slower than the other methods of course. Since it involves building the module and pushing it up to a registry. Sometimes there’s just no substitute for going through the entire install process.

Did I miss anything?

Hopefully these tips will help you get started tightening up your development cycle of your server side javascript. If I missed anything let me know in the comments below.