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.

element-vir is a package for defining and rendering custom HTML web components. It wraps Lit and aims to dramatically reduce the number of mistakes devs can easily make. This post will talk about how rendering within element-vir works.

Web Components are reusable, native chunks of shared HTML, CSS, and JavaScript. They are the way of reusing HTML and defining tightly-scoped and decoupled blocks of HTML with dedicated styles (CSS) and logic (JavaScript). How do you use them? This post is a high level introductory answer to that question.

• PickDeep is a utility type that expands TypeScript's built-in Pick utility type to pick keys in nested objects.
• PickSelection is a utility type that accomplishes the same thing but with a different interface: using selection sets (similar to GraphQL selection or Prisma's selection interface).

While both are still supported, PickSelection is now the recommended utility type. This blog post will explain why.

There are tons of options for test packages and frameworks within the JavaScript ecosystem, both on the backend and frontend. This is my knowledge dump of them.

Disclaimer: This is only what I know about each package from browsing its docs, my experiences with them, and my, often strong (beware), opinions. I can't possibly hear or know about all available testing packages.

Here's a super simple, low cost pattern for keeping track of multiple solo projects: just add a todo.md file at the root of each repo.