I thought this would be easy (because it's easy to stream from a backend to a frontend and vice versa) but it was not. Let's look at how to stream a file from an S3 connection on a server to another server in Node.js.
I recently had to figure out client-side mTLS certificates. I've never had to deal with them before, and it was quite annoying, so I documented what I learned.
If you set --prefer-offline to true in npm, naively thinking (like I did) that this will speed up your npm installs, you will be disappointed (like I was). Annoyingly, this setting causes npm to also cache which packages and versions don't exist. Thus, updating a dependency to a newly published version causes npm to think it doesn't exist and, instead of doing anything about it, npm will simply error out.
It's really hard to get new Worker() from node:worker_threads to work when running code via tsx. I finally got an example working. Here's how to do it:
import {Worker} from 'node:worker_threads';
const workerPath = import.meta.resolve('./sample-worker.js');
const worker = import.meta.filename.endsWith('.ts')
? new Worker(
`import('tsx/esm/api').then(({ register }) => { register(); import('${workerPath}') })`,
{
eval: true,
},
)
: new Worker(workerPath);
CJS Node.js scripts have always been able to detect if they're running directly through the CLI or imported from another JS script through various means (the most recent being require.main === module).
However, ESM scripts have not been so lucky. For years the answer to this in ESM has simply been no.
Now it's in Node.js v24! You use it like this:
if (import.meta.main) {
// executed from CLI
} else {
// imported into another JS module
}
I couldn't find a single consolidated place that explains how to setup pm2 from scratch (assuming you've already installed Node.js), and their own "quick start" didn't help. I was finally able to piece together how to get it working.
There are currently two main module formats in the JavaScript ecosystem: ECMAScript Modules (ESM) and CommonJS (CJS). CJS was first, but ESM is now the JavaScript standard and is the future. The main difference between the two is how they import files.
The tools we use as developers make us more effective (or at least hopefully faster) developers. So why not spend some time to make one of the most common dev tools much more useful? Here's a way to give any terminal app a personalized and awesome experience (fwiw I use the default app included with macOS). Features covered will be the following:
c8 is my preferred package for calculating code coverage in Node.js testing and it is also apparently used by web-test-runner. However, c8 supports a lot more ignore comments then they document. Below I've listed all the supported comments from my own personal testing and some other notes about ignoring lines for code coverage.
Here's an example of an existing production application's database testing setup in a TypeScript, Node.js backend. It's not perfect, but it works well enough.