Forem: Bosco Domingo

JavaScript imports guide (Everything you need to know, in 5 minutes)

Bosco Domingo — Wed, 27 Aug 2025 14:22:18 +0000

Default import

import process from "node:process";

process.env.MY_VAR

Imports the module’s default export (if one exists).
Shorthand for import { default as X } from "Y".
If the default export is an object (for example the process object in Node.js), calling methods via that object (e.g., process.on(...)) uses the correct object as the this context.
Use this when the module exports a stateful object or one “main” entity.

Named import

import { env } from "node:process";

env.MY_VAR

Brings only the explicitly exported property as a raw, static reference.
If you import a function or method via named import and then call it without its owning object, you may lose the original this binding (so this may be undefined).
Reduces bundle size (although tree-shakers are quite good at this, it will make compilation faster).
Still runs code in the imported module.
Usage: pure or stateless functions and constants, reducing import size.

Namespace import

import * as process from "node:process";

process.env.MY_VAR // undefined
process.default.env.MY_VAR // "All good!"

Collects all exports into a single frozen module namespace object (properties are immutable).
Renames the default export to default. All others are kept the same.
Methods called via namespace.method() will still have namespace as the calling object (so this inside the method will refer to namespace, assuming the method uses this).
Usage: accessing all exports from a module without having to import each one.

Side-effect import

import "node:process"; // Add a comment to explain why that import is there

Runs the module’s top-level code but imports nothing.
Usage: polyfills, patches, or setup code.

Mixed imports

import process, { env } from "node:process";

Combine default and named imports in one statement.
Handy when you want both the live object and specific named bindings.

Type-only import (TypeScript)

import type { MyComponent } from "./MyComponent.tsx";

/** @see MyComponent */
const MyComponentLazy = React.lazy(() => import("./MyComponent.tsx"));

Imports only type information, erased at runtime.
Guarantees no runtime code is included.
Usage: bringing type info, linking to lazily imported modules

JSON import (with import assertions)

import config from "./config.json" with { type: "json" };

Imports a JSON file directly as a parsed object.
Errors if assertion is not passed
You get type-checking and autocomplete for free!
Used to be asserts instead of with, you may see that some places. The correct one is with

Rule of thumb:

Use default import for live objects that have methods with this.
Use named import when you need just a piece of the module.
Use namespace import only for modules with pure functions/values.
Use type import to keep type dependencies clean (TS only).
Use JSON import for configs/data files that should be parsed automatically.
Use side-effect import very sparingly, for things that must run once globally, and make sure to document it.

TL;DR CSS measurement units

Bosco Domingo — Sun, 24 Aug 2025 16:37:12 +0000

A simple reference to check when in doubt about which unit to use.

Summary Table

Unit	Relative To	Best For
`px`	Device Screen	Fixed-size elements, `border`, `box-shadow`.
`rem`	Root (`<html>`) font-size	Modern standard. `font-size`, `margin`, `padding`, most layout values.
`em`	Parent element's font-size	Sizing elements relative to their own font-size (e.g., `padding` on a button).
`vh`/`vw`	Viewport height/width	Full-screen sections, elements sized relative to window height/width.
`%`	Parent element's size	Responsive layouts, sizing elements inside a container.

Simple takeaway (rule-of-thumb)

For most projects, a good strategy is:

Use rem for font sizes and spacing (margin, padding).
Use px for tiny, non-scalable values like border widths.
Use %, vw, or vh for high-level layout containers.

    <div style="font-size: 1.2em;"> <!-- Computes to 1.2 * 16px = 19.2px -->
      <div style="font-size: 1.2em;"> <!-- Computes to 1.2 * 19.2px = 23.04px -->
        Some text.
      </div>
    </div>

Table of Contents
1. 1. Absolute Units
  1. px (Pixels)
2. 2. Relative Units
  1. rem (Root em)
  2. em
  3. vh (Viewport Height) and vw (Viewport Width)
  4. % (Percentage)

1. Absolute Units

Absolute units are fixed and do not change based on any other element's size or screen settings. The most common absolute unit is the pixel (px).

`px` (Pixels)

What it is: A single pixel on the screen. 1px is one dot on your display.
Relative to: The device's screen resolution.
Use Case: Use px when you need a fixed size that should not scale. It's great for things like borders (border: 1px solid black;) or box-shadows where you want a crisp, consistent line.
Downside: Using px for everything, especially for font sizes and spacing, can harm accessibility. Users who have set a larger default font size in their browser will not see px-based text scale up, making it harder to read.

2. Relative Units

Relative units are flexible because they are measured in relation to another value. This makes them ideal for building responsive and accessible websites.

`rem` (Root `em`)

What it is: A unit relative to the font size of the root element (the <html> tag).
Relative to: The font-size of the <html> element. The browser default is typically 16px, so by default, 1rem = 16px.
Use Case: This is the most recommended unit for modern web development. Use it for font-size, margin, padding, width, height—almost everything. If a user changes their browser's default font size for better accessibility, your entire layout will scale proportionally.
Example: If the root font size is 16px, then font-size: 1.5rem; computes to 24px.

`em`

What it is: A unit relative to the font size of its direct parent element.
Relative to: The font-size of the parent element.
Use Case: Useful when you want an element's size to be based on its parent's font size. For example, setting the padding of a button in ems will make the padding scale with the button's text size.
Downside (The "Compounding" Effect): If you nest elements with em units, the sizes can compound in unexpected ways. For example:
```
<div style="font-size: 1.2em;"> 
  <div style="font-size: 1.2em;"> 
    Some text.
  </div>
</div>
```
This is why rem is often preferred, as it always relates back to a single, predictable source (<html>).

`vh` (Viewport Height) and `vw` (Viewport Width)

What it is: A percentage of the browser window's (viewport's) height or width.
Relative to: The viewport (the visible area of the web page). 1vh is 1% of the viewport height, and 1vw is 1% of the viewport width.
Use Case: Perfect for creating elements that should take up the full screen or a specific portion of it, regardless of the screen size. A common example is a hero banner that fills the entire screen.
Example: height: 100vh; will make an element exactly as tall as the current browser window.

`%` (Percentage)

What it is: A percentage of the parent element's corresponding property.
Relative to: The parent element.
Use Case: Mostly used for layout and sizing elements within a container. For example, setting width: 50%; on an element will make it half the width of its parent.
Difference from vw: width: 100% makes an element fill its parent container, while width: 100vw makes it fill the entire browser window's width, which can cause horizontal scrolling if the parent has padding.

Notion - Create a date range for current week (Mon-Sun)

Bosco Domingo — Wed, 16 Jul 2025 11:13:26 +0000

To create a dynamic date range in Notion that spans the current week (Mon-Sun) at the time of use, you can use the following formula (substitute <Today> for the actual Today() function):

dateRange(dateSubtract(<Today>, <Today>.day()-1, "days"), dateAdd(<Today>, 7-<Today>.day(), "days"))

What it does is simply to take the current date and find the difference to that week's Monday (by subtracting days) and to Sunday (by adding days).

To use it, simply chuck it into any formula input (such as in a Button that performs actions, or in Automations).

I personally suggest you create a variable (such as thisWeek) and reference that:

Shameless plug: this comes from my Weekly Learning page, where I write about what I learn as I go. It's how I create new pages without having to manually set the weekly range. Quite convenient!

Go string concatenation benchmark

Bosco Domingo — Thu, 01 May 2025 18:51:23 +0000

TL;DR

strings.Builder is the fastest and takes least memory.
+ is tied in memory but slightly less performant (although much more convenient).
strings.Join is not a bad alternative for arrays.
fmt.Sprintf is trash.

Check the repo in which I share the benchmarks so you can test them too!

Have you ever wondered what the fastest way to concatenate strings is?

Well I did today, so I whipped up a quick benchmark (since a Google search was not yielding me any conclusive results) and as of today, 1st of May 2025, these are the results:

goos: linux
goarch: amd64
pkg: scratchpad-go
cpu: AMD Ryzen 5 5600X 6-Core Processor             
BenchmarkConcatStrings_Plus-12                      51331621            21.97 ns/op        8 B/op          1 allocs/op
BenchmarkConcatStrings_Sprintf-12                   11596424           102.9 ns/op        40 B/op          3 allocs/op
BenchmarkConcatStrings_StringsBuilder-12            64022565            18.46 ns/op        8 B/op          1 allocs/op
BenchmarkConcatStrings_Join-12                      42522718            27.70 ns/op        8 B/op          1 allocs/op
BenchmarkConcatStringAndInt_Plus-12                 51975021            22.21 ns/op        5 B/op          1 allocs/op
BenchmarkConcatStringAndInt_Sprintf-12              12212780            98.96 ns/op       21 B/op          2 allocs/op
BenchmarkConcatStringAndInt_StringsBuilder-12       56754538            20.43 ns/op        8 B/op          1 allocs/op
BenchmarkConcatStringAndInt_Join-12                 38538142            28.96 ns/op        8 B/op          1 allocs/op

Why `response.json()` must be awaited

Bosco Domingo — Tue, 05 Nov 2024 15:17:18 +0000

Credit to the source, I'm just putting it in writing for easier access!

It turns out json() must be awaited because fetch() will resolve or reject when it receives the response headers, regardless of what the body is! The body is likely to be much larger in size, and may even take a long time to arrive and/or might do so in chunks, thus it has to be awaited even after fetch() has finished.

I had no idea why this behaviour existed until now (and it comes from HTTP btw, it's not JS-specific), so it feels great understanding why.

Again, watch the video for a better and more visual explanation! (it's 6 minutes long, worth every second)

Set up Go with mise (version management) and the VS Code/Cursor extension

Bosco Domingo — Fri, 06 Sep 2024 15:29:56 +0000

2025 update: Go is natively supported by mise so the asdf plugin is no longer needed. The bug I mention below was fixed too, so it's even easier now!

This comes from my answer in the official Go - VS Code Extension repo:

For mise the solution is to point to wherever mise where go points to (or which go, but the former is preferred), which should be the mise folder.

Resulting settings.json:

"go.alternateTools": {
    "go": "~/.local/share/mise/installs/go/latest/go/bin/go"
},

However, this will pin it to one specific version due to what seems like a bug (in my case mise install go@latest installed 1.23.0 instead of 1.23.1 as of writing, and saved it to ~/.local/share/mise/installs/go/1.23.0).

To fix this, use the asdf-golang plugin (mise p i https://github.com/asdf-community/asdf-golang) which will install it correctly to ~/.local/share/mise/installs/go/latest/go/bin/go which you can then add to your settings.json:

On Agile Development (ft. Dr. John Ousterhout)

Bosco Domingo — Mon, 05 Aug 2024 17:26:56 +0000

Talking about how modern Agile Development interacts with the advice he gives in his (awesome) book A Philosophy of Software Design, Dr John Ousterhout wrote:

"Developing incrementally is generally a good idea, but the increments of development should be abstractions, not features"

I deeply resonate with this quote. So much so, I had to share it in a blog post.

Far too many times I've seen the quick-and-dirty, "make it work now" style of programming - what the author calls tactical - just evolve into a massive, unmaintainable piece of garbage that most likely had to be rewritten, costing more time and effort than doing it right in the first place and slowly iterating towards better design would've (not to mention the cost of sanity and burnout from the developers).

Please develop with the future in mind. Making it work now is important, yes. Making sure it doesn't crumble in 6-12 months even more so. Your future self will thank you.

Note: Apply this advice pragmatically. Do not over-engineer every piece of software you build from now on, but do apply best practices, and please, if you have to revisit software, then make it better, not worse. If you're building what it supposed to be a core product, build it over a strong foundation, not on sand, hopes and wishes. Take pride in your work. That's it.

The best Design Patterns repository

Bosco Domingo — Mon, 05 Aug 2024 08:13:04 +0000

Quick one today: the other day I got an RSS notification that Martin Fowler had published a new article to quickly mention that he'd updated his Catalog of Patterns of Enterprise Application Architecture.

I had never heard of said catalogue, but decided to pop in for a look, and boy was I happy I did. This is a fantastic repository of some of the best Design Patterns, complete with examples, diagrams and use cases, organised by topic. I highly recommend you check it out if you're at all interested in bettering your Software Design/Architecture skills. Link here again for ease

TypeScript Enums are more than ok

Bosco Domingo — Fri, 14 Jun 2024 12:21:01 +0000

Update 2025-08-24: I've started to favour objects + as const over Enums mostly to be able to easily use their keys and to avoid TypeScript magic (better JS compatibility), but the takeaways from this article still stand and Enums are still quite ok!

As long as you use text-based ones.

In TypeScript, enums by default assign numbers as the values in the order the keys are defined. This means that changing existing enums can lead to unwanted changes:

enum Enum {
    key0, // 0
    key1 // 1
}

// Later commit, disaster strikes
enum Enum {
    key0, // 0
    key2, // 1 - this was taken over
    key1, // 2
    key3 // 3
}

// And again, at a later commit just mayhem
enum Enum {
    key2, // 0
    key1, // 1
    key3 // 2
}

We definitely want to avoid that. That's why you should assign values to your enums' keys, the best option being text (numbers still do weird things, watch the videos below to understand more).

`as const` objects

The biggest opponent to enums is the controversial as const object. The implementation goes something like this:

const ENUM = {
    key0: "0",
    key1: "1"
} as const;

type EnumKeys = keyof typeof ENUM; // "key0" | "key1"
type EnumValues = typeof ENUM[EnumKeys]; // "0" | "1"

// Which allows for
function example(key: EnumKeys, value: EnumValues): void {
    // ...
}

// Both have intellisense
example("key0", ENUM.key0); // Just like regular enums
example("key1", "1"); // But values are accepted too

But the thing is string-based enums can already do that:

enum Enum2 {
    key0 = "0",
    key1 = "1"
}

// Which allows for
type Enum2Keys = keyof typeof Enum2 // "key0" | "key1"
type Enum2Values = `${Enum2}` // "0" | "1"

function example(key: Enum2Keys, value: Enum2Values): void {
    //...
}

// Both have intellisense
example("key0", Enum2.key0);
example("key1", "1"); // Now values are accepted too

No need for extra convoluted code that people unfamiliar with TypeScript won't even understand. A much simpler and nicer way to achieve the same goal, using vanilla TS and string interpolation.

And this article doesn't even cover computed values and other awesome features enums have. I genuinely think they are a great addition, and hope the TC39 proposal to implement them in base JS goes through. They are present in almost any modern language for a reason, folks.

Sources:

The difference between Promise.all() vs Promise.allSettled() vs Promise.any() vs Promise.race() in 30 seconds

Bosco Domingo — Fri, 26 Apr 2024 17:45:26 +0000

If you're writing code in JavaScript or TypeScript (or CoffeeScript for whatever reason!) you'll come across Promises. One of the best features they provide is concurrency, which is usually achieved with Promise.all(). That being said, I'd like to quickly explore the differences between the available methods: all(), allSettled(), any() and race() (this last one I hadn't even heard of until researching for this article!).

At a glance

All of them start the Promises concurrently (not necessarily in parallel!). They all ignore non-promises.

all(): Resolves only if all promises resolve. Early reject if any one promise rejects. Returns an array of the settled values in the order they were inserted, not settled. Promise.all() resolves synchronously if and only if the iterable passed is []. Even if you pass [1, 'abc', {}], it will resolve asynchronously.
allSettled(): Resolves only if all promises resolve. Reject if any one promise rejects (just like all() so far) BUT WAITS FOR ALL OTHERS TO FINISH. Returns an array of the settled status and values in the order they were inserted, not settled.
any(): Resolves if any promise resolves. Rejects only if all the promises reject (opposite to all()). Returns the first resolved value.
race(): Rejects or resolves according to whatever the first settled promise does. Returns the first resolved value.

Don't forget to check out all my other content for more guides like this one!

Here is some code you can test yourself to check the results. Feel free to test it out and comment any findings you may have!

Here is the GitHub repo too. Give it a star ⭐ while you're at it!

/* All of them start the Promises concurrently (not in parallel necessarily!). They all ignore non-promises.

- all(): Resolves only if all promises resolve. Early reject if any one promise rejects.
    Returns an array of the settled values in the order they were inserted, not settled.
    Promise.all() resolves synchronously if and only if the iterable passed is []. Even if you pass [1,'abc',{}], it will resolve asynchronously.

- allSettled(): Resolves only if all promises resolve. Reject if any one promise rejects BUT WAITS FOR ALL OTHERS TO FINISH.
    Returns an array of the settled stati and values in the order they were inserted, not settled.

- any(): Resolves if any promise resolves. Rejects only if all the promises reject (opposite to all()).
    Returns the first resolved value.

- race(): Rejects or resolves according to whatever the first settled promise does.
    Returns the first settled value.
*/
let immediateResolve: Promise<number>,
  nonPromise: number,
  timeoutPromise: Promise<string>;

function setPromises() {
  immediateResolve = Promise.resolve(3);
  nonPromise = 42;
  timeoutPromise = new Promise((resolve, _) => {
    setTimeout(resolve, 1000, "Resolved after timeout");
  });
}

async function tryPromiseAll() {
  setPromises();
  const result = await Promise.all([
    immediateResolve,
    nonPromise,
    timeoutPromise,
  ]);
  console.log("Promise.all 1: ", result); // Expected output (after at least 1000ms): Array [3, 42, "foo"]

  setPromises();
  try {
    const resultWithRejection = await Promise.all([
      immediateResolve,
      nonPromise,
      timeoutPromise,
      Promise.reject("Immediate reject"),
    ]);
    console.log("Promise.all 2: ", resultWithRejection); // Never reached, rejection causes interruption
  } catch (error) {
    console.error("Error:", error);
  }

  setPromises();
  try {
    const resultWithCaughtRejection = await Promise.all([
      immediateResolve,
      nonPromise,
      timeoutPromise,
      Promise.reject("Immediate reject").catch(() => {}),
    ]);
    console.log("Promise.all 3: ", resultWithCaughtRejection); // Expected: [ 3, 42, 'Resolved after timeout', undefined ]. Rejection is never bubbled up
  } catch (error) {
    console.error("Error:", error);
  }
}

async function tryPromiseAllSettled() {
  setPromises();
  const result = await Promise.allSettled([
    immediateResolve,
    nonPromise,
    timeoutPromise,
  ]);
  console.log("Promise.allSettled 1: ", result);
  // Expected output: [{ status: 'fulfilled', value: 3 }, { status: 'fulfilled', value: 42 }, { status: 'fulfilled', value: 'Resolved after timeout' }]

  setPromises();

  try {
    const resultWithRejection = await Promise.allSettled([
      immediateResolve,
      nonPromise,
      timeoutPromise,
      Promise.reject("Immediate reject"),
    ]);
    console.log("Promise.allSettled 2: ", resultWithRejection);
    // Expected output: [{ status: 'fulfilled', value: 3 }, { status: 'fulfilled', value: 42 }, { status: 'fulfilled', value: 'Resolved after timeout' }, { status: 'rejected', reason: 'Immediate reject' }]
  } catch (error) {
    console.error("Error:", error);
  }
}

async function tryPromiseAny() {
  setPromises();
  const result = await Promise.any([
    immediateResolve,
    nonPromise,
    timeoutPromise,
  ]);
  console.log("Promise.any 1: ", result); // Expected output: 3, not 2, as it doesn't come from a promise

  setPromises();

  try {
    const resultWithRejection = await Promise.any([
      immediateResolve,
      nonPromise,
      timeoutPromise,
      Promise.reject("Immediate reject"),
    ]);
    console.log("Promise.any 2: ", resultWithRejection); // Always reached unless they all rejected
  } catch (error) {
    console.error("Error:", error);
  }
}

async function tryPromiseRace() {
  setPromises();
  const result = await Promise.any([
    immediateResolve,
    nonPromise,
    timeoutPromise,
  ]);
  console.log("Promise.race 1: ", result); // Expected output: 3

  setPromises();

  try {
    const resultWithRejection = await Promise.any([
      immediateResolve,
      nonPromise,
      timeoutPromise,
      Promise.reject("Immediate reject"),
    ]);
    console.log("Promise.race 2: ", resultWithRejection); // Never reached
  } catch (error) {
    console.error("Error:", error);
  }
}

export default async function main(): Promise<void> {
  console.log("Starting test:\n");
  console.time("Promise.all");
  await tryPromiseAll();
  console.timeEnd("Promise.all");
  console.log("");

  console.time("Promise.allSettled");
  await tryPromiseAllSettled();
  console.timeEnd("Promise.allSettled");
  console.log("");

  console.time("Promise.any");
  await tryPromiseAny();
  console.timeEnd("Promise.any");
  console.log("");

  console.time("Promise.race");
  await tryPromiseRace();
  console.timeEnd("Promise.race");
}

main()
  .then(() => {
    process.exit(0);
  })
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

Sources: all(), allSettled(), any(), race()

Node Test Runner vs Bun Test Runner (with TypeScript and ESM)

Bosco Domingo — Fri, 26 Apr 2024 17:01:51 +0000

I've recently gotten the chance to play with both of these while looking for a long-term testing framework at my job.
I also considered Node-TAP, Vitest, Jest and Mocha, but none truly convinced me as much as these two for a multitude of reasons (annoying config, lack of ESM support, speed, etc), so I'll focus on them.

Node Test Runner

The good

Built-in. That's it, so simple, so nice. Plus it works with ESM too!

Use

It has everything you'd expect (describe/it, mock, test, beforeEach, etc...) and uses assert instead of the usual expect.

assert.equal(id.value, expectedId);

The bad

No TS support out-of-the-box. So much so, that you need to do a hacky workaround in your package.json scripts:

"test" "glob -c \"tsx --test --test-reporter spec \" \"./test/**/*.test.ts\""

You need both a loader (tsx or similar) and a way to tell it where your tests are (in this case, glob).

This snippet comes from the guide I made on setting up Node Test Runner for TypeScript, so check it out if you want more info!

Bun Test Runner

The good

It's fast. Like twice as fast as Node's runner, which was already faster than Jest and Vitest. It also is as easy to set up as Node's Test Runner, and includes TS support as well!

Use

It has a decent compatibility with both Jest and Vitest's APIs (you can track progress here) so you can use it as almost a drop-in replacement for either.
Just as Node's, it has describe/it, mock, test and others, but with the expect syntax (which I find more readable). For example:

expect(id.value).toEqual(expectedId);

The bad

Iffy debugging support. It requires the VS Code extension if you use VS Code, and I'm not sure how well other IDEs are supported. It also requires installing Bun as a dependency in package.json if you still use npm/pnpm/yarn to pin the right version.

Verdict

If you already use Bun, or don't mind having to use additional tools for debugging, then Bun is definitely the choice to make. It's easier to use and faster, and has about the same functionality if not more than Node's.

If on the other hand you care about "native" experience, want the best CI installation times, or just want to use all-Node, then the good news is that Node's Test Runner is not far behind, and you won't feel like you're being left out for not using the most blazingly fast™ tool.

In any case, either one should be a good choice as they are seeing active development (Node just released version 22, and Bun announced v1.1 three weeks ago as of the time of writing) and aim to be easy-to-use, fast tools.

Hope this article was of use in helping you decide which one to go for, and don't forget to check all my other stuff for more posts like this one!

The ultimate Node Test Runner + TypeScript + ENV variables guide

Bosco Domingo — Thu, 25 Apr 2024 13:38:39 +0000

TL;DR

Check the GitHub Gist I made

Introduction

This also works in a monorepo ;). If you're working on a single project, adapt the paths accordingly. The expected folder structure is the following:

ts-project/
├── tsconfig.json
└── apps/
    └── app-1/
        ├── tsconfig.json
        ├── package.json
        └── test/
            └── tsconfig.json

This allows modern IDEs to detect the different configs per folder and correctly adapt to them. It also allows for shared/common TS options + custom ones per app.

Dependencies

First install tsx and glob:

# Use whatever package manager you prefer
pnpm add -D tsx glob

# For a single app in a monorepo
# pnpm add -F your-app -D tsx glob

# For the global package.json in a monorepo
# pnpm add -wD tsx glob

Environment variables

Assuming you want environment variable control, create a .env and a .env.test at the root of the app you want to configure (optional, since Node throws an error if they don't exist, ~~although I'm working on it~~ and you can use --env-file-if-exists from Node 22.9.0 onwards in such cases).

Scripts

Add this to your app's package.json:

Node >=22.9.0 (if you want optionality for the .env files)

"scripts": {
    //...
    "test": "glob -c \"tsx --env-file-if-exists .env --env-file-if-exists .env.test --test --test-reporter spec \" \"./test/**/*.test.ts\"",
    //...
}

Node < 22.9.0:

"scripts": {
    //...
    "test": "glob -c \"tsx --env-file .env --env-file .env.test --test --test-reporter spec \" \"./test/**/*.test.ts\"",
    //...
}

What that test script does is:

load your .env and .env.test files (the latter overwrites the former in case of conflict),
asks glob to process the "./test/**/*.test.ts\" (which will load all Typescript files in the ./test folder ending in .test.ts),
runs the tests via tsx with a human-readable output (--test-reporter spec). This last step is equivalent to node --import tsx --test.

TS Configs

Finally, adapt your tsconfig.jsons to include your tests if you want imports, linting and others:

// app-1/tsconfig.json
// Needed because VS Code and other IDEs
// use it to decide which files to
// apply the base config's rules
{
    "extends": "../../tsconfig.json", // Base monorepo tsconfig
    "compilerOptions": {
//      If "outDir": "${configDir}/dist", not already present
//      in the base config. Otherwise you can delete `compilerOptions`
        "outDir": "./dist"
    },
    "include": ["./src/**/*"],
}

// app-1/test/tsconfig.json
{
    "extends": "../tsconfig.json", // Your app's tsconfig (file above). Can also be the base monorepo tsconfig
    "compilerOptions": {
        "noEmit": true,
        "allowImportingTsExtensions": true
        // These don't work with Node Test Runner, but do with Bun. Purely optional QoL
        // "baseUrl": ".", 
        // "paths": {
        //  "@src/*": ["../src/*"]
        //},
    },
    "include": ["./**/*"]
}

Final words

And that should be it, really. Hope it is of help when setting up your TypeScript testing environment!

For more information on setup and other user's info, check this GitHub issue.

I also made a GitHub Gist to go along with this guide which will probably be more up-to-date than this article. Check it out just in case!

Changelog

Update 2024-09-18: My PR adding --env-file-if-exists landed and was released in Node 22.9.0, so if you are using any version equal or higher, you can use that new flag for the env files! I've updated the post accordingly

Update 2024-09-23: Updated the tsconfig.jsons to use a better structure based on my own experience:

Note: I have come up with a better way for tsconfig.jsons setup, find it in the aforementioned Gist. The reason for this is having the baseUrl and paths set up in your tsconfig.json will also affect imports in the source code, which doesn't work with Node (but does with Bun) plus it works better to have a base app/tsconfig.json and a app/test/tsconfig.json (at least with VS Code).

Forem: Bosco Domingo

JavaScript imports guide (Everything you need to know, in 5 minutes)

Default import

Named import

Namespace import

Side-effect import

Mixed imports

Type-only import (TypeScript)

JSON import (with import assertions)

Rule of thumb:

TL;DR CSS measurement units

Summary Table

Simple takeaway (rule-of-thumb)

Table of Contents

1. Absolute Units

px (Pixels)

2. Relative Units

rem (Root em)

em

vh (Viewport Height) and vw (Viewport Width)

% (Percentage)

Notion - Create a date range for current week (Mon-Sun)

Go string concatenation benchmark

TL;DR

Why `response.json()` must be awaited

Set up Go with mise (version management) and the VS Code/Cursor extension

On Agile Development (ft. Dr. John Ousterhout)

The best Design Patterns repository

TypeScript Enums are *more than ok*

as const objects

The difference between Promise.all() vs Promise.allSettled() vs Promise.any() vs Promise.race() in 30 seconds

At a glance

Node Test Runner vs Bun Test Runner (with TypeScript and ESM)

Node Test Runner

The good

Use

The bad

Bun Test Runner

The good

Use

The bad

Verdict

The ultimate Node Test Runner + TypeScript + ENV variables guide

TL;DR

Introduction

Dependencies

Environment variables

Scripts

TS Configs

Final words

Changelog

`px` (Pixels)

`rem` (Root `em`)

`em`

`vh` (Viewport Height) and `vw` (Viewport Width)

`%` (Percentage)

TypeScript Enums are more than ok

`as const` objects