Skip to main content

Unified JavaScript Testing

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.

Basic Introduction to Using Web Components

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.

JavaScript Testing Packages

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.

todo.md

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.

How GraphQL Works

This is intended to be a very basic high level overview of GraphQL, explained to a developer that already understands the basics of REST API design. This is not a deep dive into all GraphQL's features or a GraphQL pros/cons list. Also, while GraphQL is backend language agnostic, this guide will be mentioning JavaScript implementations (since that's what I work with).

ESLint Violations as Warnings in VS Code

If you're using TypeScript and ESLint in VS Code, wip files or legacy files can quickly explode into a sea of red squiggles, making it hard to know where to start or track what's going on.

I like to hone in on type errors first, since they're typically more critical (as in, type errors will often completely crash your code). I keep those as scary red squiggles and tone ESLint down a bit by changing all its squiggles to just (orange) warnings.

This is easy to do with a quick edit to your user settings JSON file (accessed via the >Preferences: Open User Settings (JSON) command in VS Code):

"eslint.rules.customizations": [
{ "rule": "*", "severity": "warn" },
]