Node.js behind my build scripts

When someone asks what I use Node for, they automatically picture a server with Express listening for requests. In my day to day, most of my Node.js scripts don’t serve any request — they run once, do their job, and exit. Nobody sees them. But if they fail, it shows.

What actually runs in my projects

In framework-based projects (SvelteKit, Astro) this is already handled by the build itself. But on smaller clients, without that framework, I still keep a handful of standalone Node scripts: one that walks a folder of images uploaded by the client and converts them to WebP before uploading them to the server, another that generates a sitemap.xml from the project’s Markdown files, and one I always run before a big deploy: it checks that no internal link points to a page that no longer exists.

That last one has saved me from more than one embarrassing deploy. Before automating it, it depended on me remembering to check by hand, and the times I forgot were always the times something had moved without me noticing.

Why not bash

I could do a good chunk of this with shell scripts, and I’ve done it a few times. But as soon as I need to read a file, transform data, or do anything remotely complex with strings, I’d rather stay in a language I already know well and with access to the npm ecosystem — an image-processing library like sharp saves me from reinventing something that in bash would be much more fragile.

How boring it is, and why that’s a good thing

None of these scripts is interesting to show off. There’s no elegant architecture or design pattern worth mentioning. They’re short functions, with no weird dependencies, each doing one thing. And that’s exactly why they’ve kept working for years without me having to touch them again: the more boring and straightforward the infrastructure code, the fewer surprises it gives when you run it half-asleep before a deploy.