A while ago I had began building an Node application to be a dynamically reconfigurable front end proxy. I spent my programming time yesterday looking at the code. Some of the code should be merged with the junk-bucket since both share common ancestry with projects I have not release code for.

Productivity steps first: updating the .gitignore file to ignore the .idea directory. I generally disapprove of IDE specific directories being included due to a long history of IDEs not respecting a developer’s control over the SCM and randomly changing settings. This probably does not occur as often any more however I have a lot of expierence where it did matter.

Next up: Updating the Travis build descriptors to use newer versions of NodeJS. It was configured to use 7-9 which is not too bad. I am currently using the 10 series in much of my own work so I would like to verify it works under that series too.

Installing the junk-bucket dependency issued complaints about vulnerable packages which is unsurprising. This project has not been modified in a while. Nearly 11 months. The only real downside to pinning dependencies. Needing to update all the packages anyway the command npm outdated gives a good list of what needs to change. As a rule I rarely update all of the dependencies at once to reduce troubleshooting. Couple an update with npm install && npm test to verify.

Most dependencies updated without a problem. The mocha dependency did not. Since this was moving from the 3 series to the 5 series that is not very surprising. The test suite hangs after completing. I am guessing the underlying problem is the test service is not torn down on completion. Should be simple enough to fix. How the test are structured are definitely not my best work. Removing q to use native promises coupled with async/await will make things a lot simpler here.

My initial approach to close the test service did not work as well as I had hoped. I am wondering if there is a faster method to provide a list of refs still into the application. A quick search failed to provide a simple way to figure out what resources are holding the application open. A better architecture would be to use my dependnecy injection framework to manage contexts which need to be cleaned up. A task for another day.

Turns out the underlying issue was the ingress sockets not being closed properly. When I was initially building out the application I punted on building that out since the tests exited without an issue. Luckily with the changes to the mocha packages they do not for a process exit. Personally I prefer this so issue like this do not creep into the application lifecycle.

Pubilshing and changing the name

Unsurprisingly the package name delta is already taken on NPM. I didn’t really care at the time since I was worried about building out a functional prototype. Now it is time to see if I can think of an unused name to publish it under. Or perhaps I can publish it under my own namespac on NPM. Turns out irrigation is available. Since the idea is we want to saturate the application with incoming requests this works. I’ll go with that. Worst case scenario I unpublish the pacakge in favour of a new name.

I had to go lookup the instructions to publish again. Looks like NPM had a breech this last week…like 2 days ago. They destroyed all tokens. Fun times needing to login again. Yay! Published!.