Node, S2I and Docker


I like Node.js and I like Docker. While I am not an expert on either, I do pretend to be one at work.

Lately, I’ve been looking at Openshift CDK and how I can develop Node.js apps against it. Specifically, I was looking at the MSA Hello World Demo and the Bonjour microservice.

I also recently wrote about setting up a CDK environment on a freshly re-installed MacBook Pro.  I would check it out; it’s some good writing.

My initial goal was to figure out how to “containerize” a Node.js application and then put it on my local openshift VM, but when I started to look at it little deeper, I found a few different ways of doing it. Hopefully, this post will go into the different ways.

Continue reading “Node, S2I and Docker”


Node Package Manager 4 — Changes to Prepublish (NPM)

NPM 4 was released recently, about 2 weeks ago, and with it came some major changes. Some breaking, some not, but there is an interesting deprecation that happened with regards to the prepublish script.

Currently, if you had a prepublish entry in your package.json:

  scripts: {
    prepublish: "nsp check"

This would be run whenever you performed a npm publish. Which is probably what you would expect with a name like prepublish.

Another thing was also happening though. When you ran npm install with no arguments, the prepublish step would still be run — this is not what you would expect.

Continue reading “Node Package Manager 4 — Changes to Prepublish (NPM)”


Node 7 and Promise Rejections – Please Handle them

Node.js 7.0.0 was released just last week, and the announcement dropped a bombshell. I’m guessing the following announcement might freak some people out:

DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

While the UnhandledPromiseRejectionWarning has been in node since 6.6.0, this deprecation warning is new — basically, it means you’ve rejected a promise in your code, but you are not handling it, and eventually, future of releases of Node.js will make your currently usable code stop being useable.

Continue reading “Node 7 and Promise Rejections – Please Handle them”


Checking node.js dependencies with SZero – Never lose track again.

Node.js is a JavaScript runtime built on top of Chrome’s V8 JavaScript engine. It is highly event-driven, and leverages non-blocking I/O model that makes it lightweight, efficient, and incredibly productive to use. It’s that last bit, “productive”, that I want to focus on today.

One of the things that i feel makes Node(and NPM) so great is the ease in which you can add and use third-party modules. As most node.js developers know, to start using an external module, you first install it:

npm install cool-module --save

Then we require it:

const coolModule = require('cool-module');

Then we use it:


Yup, pretty easy.

However, as most node.js developers know, our dependency list in our pacakge.json can grow pretty quickly. And sometimes we lose track of where in our code we are using these dependencies. Sometimes, dare I say it, we have modules in our package.json that we don’t actually use. GASP!!!

Ok, so if you’ve made it this far, then you probably realize this next paragraph is going to talk about how Szero fits into what i wrote above. Productivity, package installation, and dependency management/location.

Continue reading “Checking node.js dependencies with SZero – Never lose track again.”