• Mark Eschbach
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
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.
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
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
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.