Dev Log: August 25 Wrap-up

Overview

Today was mostly about portability. I spent my time figuring out how to package one of our internal utility tools into a standalone executable so people don't have to mess around with node_modules just to run a simple local server.

What I Worked On

Making Node.js Portable

I started working on a project to bundle a standard Express server into a single binary. The goal is to have a tool that just works when you double-click it. It’s much cleaner than asking non-technical users (or even other devs who are busy) to ensure they have the right version of Node.js installed globally.

I’m using pkg for this. It’s pretty straightforward, but you have to be careful about how you path your assets. Since the executable has its own internal file system, I had to make sure the HTML and CSS files were explicitly included in the build config so they wouldn't get left behind.

Multi-Platform Support

Initially, I was just thinking about my own environment, but I realized quickly that this needs to be usable across the whole team. I updated the build targets to generate binaries for Windows, Linux, and macOS simultaneously.

Being able to spit out three different OS binaries with a single build command felt like a solid win. It saves me from the 'well, it works on my machine' headache later on.

Here’s a look at how I structured the build config in the project file (sanitized, of course):

{
  "bin": "main_entry.js",
  "pkg": {
    "assets": [
      "static_files/**/*"
    ],
    "targets": [
      "node18-win-x64",
      "node18-linux-x64",
      "node18-macos-x64"
    ],
    "outputPath": "dist"
  }
}

Wrapping Up

The core server is up and serving a basic UI from within the executable now. It's a small start, but it sets the foundation for a few other internal tools I've been meaning to build. Tomorrow I'll probably look into how to handle environment-specific configs without breaking the 'standalone' nature of the binary.