Lucas Holmquist

Sr. Software Engineer at Red Hat. Formerly of the Mobile team, where he focused on the mobile web and front-end development, he is now mostly focused on the Node.js developer experience on Openshift. While I am not a Node expert, I do pretend to be one at work

Recent Posts

Use Node.js 12 on Red Hat OpenShift today

Use Node.js 12 on Red Hat OpenShift today

On April 23, Node.js released its latest major version with Node.js 12. Because this is an even-numbered release, it will become a Long Term Support (LTS) release in October, code-named Erbium.

This release brings a host of improvements and features, which this blog post isn’t going to cover. Instead, I will focus on how to start using this new release today on Red Hat OpenShift. If you’re interested in more about the various improvements and new features, check out the articles listed at the end of this post.

Continue reading “Use Node.js 12 on Red Hat OpenShift today”

Share
Modern web applications on OpenShift: Part 3 — Openshift as a development environment

Modern web applications on OpenShift: Part 3 — Openshift as a development environment

Welcome back to the final part of this multipart series about deploying modern web applications on Red Hat OpenShift. In the first post, we took a look at how to deploy a modern web application using the fewest commands.

In the second part, we took a deeper look into how the new source-to-image (S2I) web app builder works and how to use it as part of a chained build.

This third and final part will take a look at how you can run your app’s “development workflow” on OpenShift.

Continue reading “Modern web applications on OpenShift: Part 3 — Openshift as a development environment”

Share
Modern web applications on OpenShift: Part 2 — Using chained builds

Modern web applications on OpenShift: Part 2 — Using chained builds

In the previous article, we took a quick look at a new source-to-image (S2I) builder image designed for building and deploying modern web applications on OpenShift. While the last article was focused on getting your app deployed quickly, this article will look at how to use the S2I image as a “pure” builder image and combine it with an OpenShift chained build.

Continue reading “Modern web applications on OpenShift: Part 2 — Using chained builds”

Share
Modern web applications on OpenShift: Part 1 — Web apps in two commands

Modern web applications on OpenShift: Part 1 — Web apps in two commands

In this multi-part series, we will take a look at how to deploy modern web applications, like React and Angular apps, to Red Hat OpenShift using a new source-to-image (S2I) builder image.

Series overview:

Continue reading “Modern web applications on OpenShift: Part 1 — Web apps in two commands”

Share
How to Debug Your Node.js Application on OpenShift with Chrome DevTools

How to Debug Your Node.js Application on OpenShift with Chrome DevTools

Recently, I wrote a post called Zero to Express on OpenShift in Three Commands, which shows how to get started using Node.js, Express, and OpenShift together as fast as possible using the Node.js s2i (source-to-image) images that were recently released as part of Red Hat OpenShift Application Runtimes (RHOAR).

This post will add to the last one and show how we can start to debug and inspect our running code using the Chrome Developer Tools (DevTools) inspector.

Continue reading “How to Debug Your Node.js Application on OpenShift with Chrome DevTools”

Share
Node, S2I and Docker

Node, S2I and Docker

Intro

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”

Share

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)”

Share

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”

Share

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:

coolModule.doCoolStuff();

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.”

Share