8 posts tagged with "Node.js"

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:

• a super informative and customizable prompt
• per-directory prompt customization
• automatic switching of Node.js versions (easily extended to any run-time)
• better auto complete and history
• optional "command done" chime

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.

If you look at the import.meta docs on MDN you'll notice that it says:

The spec doesn't specify any properties to be defined on it, but hosts usually implement the following properties: [url, resolve]

So what is actually in there? MDN is correct in saying url and resolve are usually (always) implemented, but each run-time also sticks some other stuff in there. From my own testing, below are the values that exist for each major runtime.

Node.js now has a built-in test runner, which I've now tried, and it's fantastic! However, it can't be used for frontend testing, or browser testing, obviously. While web-test-runner is the best (imo) test runner for frontend tests, having different runners requires you to learn different libraries and use different imports for each even when doing dead simple environment-agnostic unit tests. In this post I'll talk about how I've unified the experience, and the path that lead to being able to do that.

ESM does not populate the __filename and __dirname variables frequently used in CommonJS. This post shows what to do instead.