Forem: Hauke T.

Today, Google search AI hallucinated a new HTML-Entity to display a double left arrow (⇐): `&larrarr;`. In fact it should be `⇐` html.spec.whatwg.org/#entity-lArr

Hauke T. — Mon, 24 Nov 2025 09:30:56 +0000

html.spec.whatwg.org

Updating to Jest 30 is Frustrating (it's JSDOM)

Hauke T. — Mon, 10 Nov 2025 11:09:13 +0000

It's time to update from Jest 29 to 30 for me.
Except I can't. At least not completely.

The Easy Part

They changed the snapshot files: the link in the header changed. I find short-links disturbing anyway.

- // Jest Snapshot v1, https://goo.gl/fbAQLP
+ // Jest Snapshot v1, https://jestjs.io/docs/snapshot-testing

Then they removed some deprecated matcher aliases. (~~expect(fn).toBeCalled()~~ → expect(fn).toHaveBeenCalled()) It took a while but was manageable.

Then I got really confused when I found out some modules are not mocked anymore. As it turns out jest.mock("./path/to/module") is case-sensitive now.

The Hard Part

Jest updated JSDOM from Version 20 to 26.

It added show-stopping CSS-bugs for me (el.style.boxShadow = undefined became el.style.boxShadow === "undefined" instead of the expected el.style.boxShadow === ""), fixed them in Version 27 and introduced new show-stopping CSS-bugs for me.

While this is manageable, my tests regarding navigation began to fail...

The impossible Part

JSDOM does not implement window.location which is fine.
Up until now it was possible to mock window.location, but this stopped working in JSDOM v21.

// does not work anymore
delete window.location;
Object.defineProperty(window, 'location', { // TypeError: Cannot redefine property: location
  writable: true,
  value: { search: '' },
});

Possible workarounds are discussed, but none are satisfactory.

JSDOM does not plan to do anything about this.
Using reconfigure({url: "..."}) does not help me, because I want to know if the location was changed to the desired value.
Some even suggest to patch the jsdom package. I really don't want to do this. (But it may help for a while).
I wanted to be clever and thought we might manipulate the JSDOM Window Object with Proxies and apply them using @jest/environment-jsdom-abstract - but I was wrong....

The "Solution"

So at this point its Jest 30 with JSDOM 20 (from Jest 29). 🤮

// package.json
{
    // ...
    "devDependencies": {
        "jest": "^30.2.0",
        "jest-environment-jsdom": "^29.7.0",
    }
}

Uh and on the End-To-End test side, things became complicated since chrome complains when websites try to connect to localhost and local ip-adresses.

Testing is a nightmare right now.

Testing is hard these days: Jest 30 with JSDOM 21 won't let me mock `window.location` and Chrome 141 broke TestCafe with its new "LocalNetworkAccessChecks". 🤮

Hauke T. — Mon, 10 Nov 2025 10:34:29 +0000

Thought of the Day: Most companies are not willing to pay developers to maintain OSS-Software. OSS-Developers may introduce breaking changes as they see fit. Companies have to pay the price, when they have to upgrade their dependencies regularly.

Hauke T. — Tue, 16 Sep 2025 09:19:17 +0000

David Gilbertson Warned us About The Latest NPM Attack

Hauke T. — Tue, 09 Sep 2025 15:15:31 +0000

In the light of the latest Supply-Chain Attack on npm, which (among others) hit chalk, I can't help but smile a little, because of the irony.
David Gilbertson imagined an attack like this 7 years ago: I’m harvesting credit card numbers and passwords from your site. Here’s how..
It's a nice read and it aged better than we would have hoped.

In his article he wrote the malicious Package himself:

People love pretty colours — it’s what separates us from dogs — so I wrote a package that lets you log to the console in any colour.

It's basically what chalk does - isn't it?

Something is Odd About MDN These Days - And Googles AI is Gaslighting me About it...

Hauke T. — Mon, 25 Aug 2025 11:28:25 +0000

I went to MDN today and thought "something is odd about the font...".
So I went to google and asked: "did they change the font on mozilla developer network".

But Googles AI said:

No, Mozilla Developer Network (MDN) hasn't changed its font; any perceived changes are likely due to your browser's font rendering, the specific fonts used on a page, or a local Firefox update affecting font handling, rather than a change on the MDN website itself. To change the fonts you see, you can adjust the font settings in your Firefox browser's preferences under the "Language and Appearance" section.

I revisited MDN, spun up the devtools... and I never heard about the "JetBrains Mono" font.

Maybe it was always there, and it was not installed on my machine. When did I install it? I don't know. Am I crazy? (What about my Phone? Web-Fonts?)

Before completely losing my mind I rephrased my question:

"did they change the mdn font"

Yes, the MDN Web Docs site launched a significant front-end redesign in August 2025 that included improved typography for readability, along with a new code font for better code rendering across platforms, and updated icons and search features.

Well...

I should disable those AI responses - or find an extension that does it.

Here is the Article on MDN about the redesign: Launching MDN's new front end

TIL: Synchronous import in ES-Modules using module.createRequire (Node)

Hauke T. — Fri, 07 Feb 2025 06:55:09 +0000

I've been looking for a way to inject a configuration file like process.cwd()+"/my-config.js" into a configuration file in a node package I work on. The problem with dynamic import(process.cwd()+"/my-config.js") is, that is async. But the underlying tools need my config file to be sync.

Searching for "node synchronous dynamic import" I found the answer on stackoverflow: "Convert import() to synchronous".

There is a functionality in Node for that: module.createRequire(filename) (see the docs)

// node_modules/my-package/config.js

import { createRequire } from 'node:module';
const require = createRequire(import.meta.url);

const userConfig = require(`${process.cwd()}/my-config.js`);

export const config = {
    property1: "fallback-value",

    ...userConfig.config,
};

Editing-Notes: 1. IRL I'd use path.join(process.cwd(), "my-config.js"). 2. I was not able to nest \` in order to show inline code for template strings.

Jest Recap: Safely Mock Properties and Methods of Global Objects

Hauke T. — Thu, 18 Jul 2024 10:26:32 +0000

TL;DR:

You want to avoid that overridden/mocked properties/methods affect other tests.
For local objects (created and owned by this test) you can (and should) use
- localObject.theAnswer = 42 and
- localObject.calcTheAnswer = jest.fn(() => 42).
For global objects you should use
- jest.replaceProperty(globalObject, "theAnswer", 42) and
- jest.spyOn(globalObject, "calcTheAnswer").mockReturnValue(42).
Make sure jest.restoreAllMocks() is called in an afterEach() hook.

What?

In a perfect ~~world~~ codebase there is no need to manipulate global objects, but ~~the world~~ codebases are messy - and so is testing.

What you want to avoid at all costs, is for one test to affect the other. Tests should be meaningful regardless of their order or if some tests are skipped.

Mocking Properties

A naive approach to mock values is to just set the properties to whatever value you need in your test.
This is fine as long as you change values in local objects owned (created by) this specific test:

describe("override properties of local objects", () => {
    it("works and is harmless", () => {
        const myArray = [1];
        myArray.length = 0;
        expect(myArray).toHaveLength(0);
    });
    it("does not affect the next test", () => {
        const myArray = [1];
        expect(myArray).toHaveLength(1);
    });
});

If you do that for global objects, it gets messy:

describe("don't override properties of global objects", () => {
    it("works before the property is overridden", () => {
        expect(window.innerWidth).toBeGreaterThan(0);
    });
    it("works, but is evil", () => {
        window.innerWidth = 0;
        expect(window.innerWidth).toBe(0);
    });
    it("fails in the test after the property was overridden", () => {
        expect(() => {
            expect(window.innerWidth).toBeGreaterThan(0); // <-- ERROR: expect(received).toBeGreaterThan(expected)
        }).toThrow(Error);
    });
});

This is what jest.replaceProperty() was made for:

describe("use jest.replaceProperty() to override properties of global objects", () => {
    afterEach(() => {
        jest.restoreAllMocks();
    });
    it("works before the property is overridden", () => {
        expect(window.innerWidth).toBeGreaterThan(0);
    });
    it("works and is harmless", () => {
        jest.replaceProperty(window, "innerWidth", 0);
        expect(window.innerWidth).toBe(0);
    });
    it("does not affect the next test", () => {
        expect(window.innerWidth).toBeGreaterThan(0);
    });
});

Mocking Methods

Methods can be mocked similar to properties.

describe("override methods of local objects using jest.fn()", () => {
    it("works and is harmless", () => {
        const mySet = new Set([1]);
        mySet.has = jest.fn().mockReturnValue(false);
        expect(mySet.has(1)).toBeFalsy();
    });
    it("does not affect the next test", () => {
        const mySet = new Set([1]);
        expect(mySet.has(1)).toBeTruthy();
    });
});

If you use myObject.someFunction = jest.fn() on global objects, your tests may depend on each other and loose their meaning:

describe("don't override methods of global objects using jest.fn()", () => {
    it("works before the method is overridden", () => {
        expect(document.getElementById("foo")).toBeNull();
    });
    it("works, but is evil", () => {
        const el = document.createElement("div");
        document.getElementById = jest.fn().mockReturnValue(el);

        expect(document.getElementById("foo")).toBe(el);
    });
    it("fails in the test after the property was overridden", () => {
        expect(() => {
            expect(document.getElementById("foo")).toBeNull(); // <-- ERROR: expect(received).toBeNull()
        }).toThrow(Error);
    });
});

How should we mock methods in global objects? That is what jest.spyOn() is good for:

describe("use jest.spyOn() to override methods of global objects", () => {
    afterEach(() => {
        jest.restoreAllMocks();
    });
    it("works before the method is overridden", () => {
        expect(document.getElementById("foo")).toBeNull();
    });
    it("works and is harmless", () => {
        const el = document.createElement("div");
        jest.spyOn(document, "getElementById").mockReturnValue(el);

        expect(document.getElementById("foo")).toBe(el);
    });
    it("does not affect the next test", () => {
        expect(document.getElementById("foo")).toBeNull();
    });
});

You Must Clean up

If you want to be sure all tests find the system in the same (fresh, clean) state, you need to restore the state of mocks after each test.

The simplest solution is to set the restoreMocks configuration property.

The most straight forward option is to call jest.restoreAllMocks() in the afterEach()

How to Mock Something for all Tests

Sometimes you want to Mock things for all tests in a file. If you use jest.spyOn() and jest.replaceProperty() on the top-level or in a describe() block, all Mocks will be reset after the first test is executed.

On the top-level you can safely override properties and methods, without jest.spyOn() and jest.replaceProperty().

If you want to Mock things only for a describe() block, you need to make these calls in a beforeEach() hook.

Jest Recap: What Runs When?

Hauke T. — Thu, 18 Jul 2024 10:24:44 +0000

TL;DR: Execution Order

Everything on the top-level and in describe() blocks (where describe() blocks are basically IIFEs)
beforeAll()
1. top-level
2. 1st level describe()
3. Nth level describe()
beforeEach()
1. top-level
2. 1st level describe()
3. Nth level describe()
test()
afterEach()
1. Nth level describe()
2. 1st level describe()
3. top-level
afterAll()
1. Nth level describe()
2. 1st level describe()
3. top-level

Disclaimer

I assume you have a basic understanding of jest and unit-testing. I will not explain the meaning of the hooks. This is more of cheat-sheet/reference type of post.

There are Rules

At first jest seems to do stuff magically. What gets executed when? But if you think about it for a minute it gets ~~obvious~~ less confusing.

Maybe these simple "rules" help:

Each file is executed independently: nothing you do in A.test.js affects B.test.js. (unless you start to access external resources)
describe() callbacks are executed immediately.
hooks (beforeAll/afterAll, beforeEach/afterEach) are executed from outer scope (top-level/module) to inner scope (describe).

Basic Example

console.log("./<start>");

beforeAll(() => {
    console.log("./beforeAll");
})
beforeEach(() => {
    console.log("./beforeEach");
})
afterAll(() => {
    console.log("./afterAll");
})
afterEach(() => {
    console.log("./afterEach");
})

describe("foo", () => {
    console.log("./describe(foo)/<start>");

    beforeAll(() => {
        console.log("./describe(foo)/beforeAll");
    })
    beforeEach(() => {
        console.log("./describe(foo)/beforeEach");
    })
    afterAll(() => {
        console.log("./describe(foo)/afterAll");
    })
    afterEach(() => {
        console.log("./describe(foo)/afterEach");
    })

    test("testFoo", () => {
        console.log("./describe(foo)/test(testFoo)");
    })

    console.log("./describe(foo)/<end>");
})

describe("bar", () => {
    console.log("./describe(bar)/<start>");

    beforeAll(() => {
        console.log("./describe(bar)/beforeAll");
    })
    beforeEach(() => {
        console.log("./describe(bar)/beforeEach");
    })
    afterAll(() => {
        console.log("./describe(bar)/afterAll");
    })
    afterEach(() => {
        console.log("./describe(bar)/afterEach");
    })

    test("testBar", () => {
        console.log("./describe(bar)/test(testBar)");
    })
    test("testOtherBar", () => {
        console.log("./describe(bar)/test(testOtherBar)");
    })

    console.log("./describe(bar)/<end>");
})

console.log("./<end>");

This is the result (after I removed other output):

./<start>
./describe(foo)/<start>
./describe(foo)/<end>
./describe(bar)/<start>
./describe(bar)/<end>
./<end>

./beforeAll

./describe(foo)/beforeAll
./beforeEach
./describe(foo)/beforeEach
./describe(foo)/test(testFoo)
./describe(foo)/afterEach
./afterEach
./describe(foo)/afterAll

./describe(bar)/beforeAll
./beforeEach
./describe(bar)/beforeEach
./describe(bar)/test(testBar)
./describe(bar)/afterEach
./afterEach

./beforeEach
./describe(bar)/beforeEach
./describe(bar)/test(testOtherBar)
./describe(bar)/afterEach
./afterEach
./describe(bar)/afterAll

./afterAll

What happens?

Everything on the top-level and in describe callbacks is executed immediately:

./<start>
./describe(foo)/<start>
./describe(foo)/<end>
./describe(bar)/<start>
./describe(bar)/<end>
./<end>
[...]

beforeAll and afterAll on the top-level are a "brace" around all tests. Each executed only once.

[...]

./beforeAll

[...]

./afterAll

./describe(*)/beforeAll and ./describe(*)/afterAll are a brace around all tests in that describe callback. Each executed only once.

[...]

./describe(foo)/beforeAll
[...]
./describe(foo)/afterAll

./describe(bar)/beforeAll
[...]
./describe(bar)/afterAll

[...]

beforeEach and afterEach are a braces around each test. The top-level is the outer brace. The describe level is the inner brace.

[...]
./beforeEach
./describe(*)/beforeEach
[...]
./describe(*)/afterEach
./afterEach
[...]

Advanced Version

This is an advanced example with a nested describe block. It produces XMLish results to emphasize the hierarchical nature of the execution steps.

console.log("<top-level>");

beforeAll(() => {
    console.log("<all>");
})
beforeEach(() => {
    console.log("<each>");
})
afterAll(() => {
    console.log("</all>");
})
afterEach(() => {
    console.log("</each>");
})

describe("foo", () => {
    console.log("<describe id=\"foo\">");

    beforeAll(() => {
        console.log("<all in=\"foo\">");
    })
    beforeEach(() => {
        console.log("<each in=\"foo\">");
    })
    afterAll(() => {
        console.log("</all>  <!-- in=\"foo\" -->");
    })
    afterEach(() => {
        console.log("</each>  <!-- in=\"foo\" -->");
    })

    test("testFoo", () => {
        console.log("<test in=\"foo\" id=\"testFoo\" />");
    })

    console.log("</describe> <!-- id=\"foo\" -->");
})

describe("bar", () => {
    describe("barinner", () => {
        console.log("<describe id=\"barinner\">");

        beforeAll(() => {
            console.log("<all in=\"barinner\">");
        })
        beforeEach(() => {
            console.log("<each in=\"barinner\">");
        })
        afterAll(() => {
            console.log("</all> <!-- in=\"barinner\" -->");
        })
        afterEach(() => {
            console.log("</each> <!-- in=\"barinner\" -->");
        })

        test("testBarInner", () => {
            console.log("<test in=\"barinner\" id=\"testBarInner\" />");
        })

        console.log("</describe> <!-- id=\"barinner\" -->");
    })

    console.log("<describe id=\"bar\">");

    beforeAll(() => {
        console.log("<all in=\"bar\">");
    })
    beforeEach(() => {
        console.log("<each in=\"bar\">");
    })
    afterAll(() => {
        console.log("</all> <!-- in=\"bar\" -->");
    })
    afterEach(() => {
        console.log("</each> <!-- in=\"bar\" -->");
    })

    test("testBar", () => {
        console.log("<test in=\"bar\" id=\"testBar\" />");
    })
    test("testOtherBar", () => {
        console.log("<test in=\"bar\" id=\"testOtherBar\" />");
    })

    console.log("</describe> <!-- id=\"bar\" -->");
})

console.log("</top-level>");

This is the output after some cleanup and formatting:

<top-level>
    <describe id="foo">
    </describe> <!-- id="foo" -->

    <describe id="barinner">
    </describe> <!-- id="barinner" -->

    <describe id="bar">
    </describe> <!-- id="bar" -->
</top-level>

<all>
    <all in="foo">
        <each>
            <each in="foo">
                <test in="foo" id="testFoo" />
            </each>  <!-- in="foo" -->
        </each>
    </all>  <!-- in="foo" -->
    <all in="bar">
        <all in="barinner">
            <each>
                <each in="bar">
                    <each in="barinner">
                        <test in="barinner" id="testBarInner" />
                    </each> <!-- in="barinner" -->
                </each> <!-- in="bar" -->
            </each>
        </all> <!-- in="barinner" -->
        <each>
            <each in="bar">
                <test in="bar" id="testBar" />
            </each> <!-- in="bar" -->
        </each>
        <each>
            <each in="bar">
                <test in="bar" id="otherBar" />
            </each> <!-- in="bar" -->
        </each>
    </all> <!-- in="bar" -->
</all>

That's all there is to know about the execution order.

Wibbles - W(eb) (N)ibbles - Recreating "The Worm", Snake, Nibbles and the like

Hauke T. — Wed, 30 Nov 2022 19:03:24 +0000

Do you remember NIBBLES.BAS from your old DOS Computer? Well I do. But I also remember "Der Wurm"/"The Worm" by "Digital Nightmares". I spent days playing it as a child. Also the multi player mode was a lot of fun.

Wibbles (Nibbles on the Web) is a Snake variant that takes the concept of "Der Wurm"/"The Worm" and ports it to the web.

Why?

In a nostalgic moment I remembered The Worm and found it on archive.org. It was unplayable, mainly because the animation between levels was too slooooow. Also the graphics are unproportional and the longer the worm got, the slower it moved.

I often browsed https://opengameart.org and wished I had a good idea for a side project game, where I could use some of these sprites.

Since I wanted to practice clean code and TDD I was looking for a side project anyway. (Spoiler: Clean Code is a work in progress. I failed at TDD.)

Side Projects!

Jul 27 '18 Author: abhimanyusaxena

See Full Post

Since side projects are something that never gets done (I got side-tracked by the multiplayer part). I defined an MVP and hoped to release it, before the next thing got interesting.

This is it - The MVP of Wibbles:

Play it on https://htho.github.io/wibbles/

See the source on https://github.com/htho/wibbles/

State

Of course its in an early alpha state, but already playable.

There are only two maps which are quickly played. But it is easy to add more maps.

A lot of stuff is missing. Like an UI with information about the game, level, points and the like.

I'd like to implement a multi-player mode and share my experiences doing that.

The tiles have a border in Firefox.

A Series?

This is a series of articles because I want to share valueable insights I got when I created the game. These are some topics I'd like to write about:

I use the Dispose Pattern to make sure EventListeners are removed when I don't need them anymore.
For the multiplayer mode I prototyped a signaling server for WebRTC in php. As I am used to JavaScript/TypeScript tooling, writing php only using free tooling feels like editing in notepad again.
I reverse engineered some aspects of the original game digging through the binaries. Although I don't use any of them, I think some people might find that interesting.
Rendering/Algorithms: NIBBLES.BAS and Snake are very simple because they move one tile at a time. For wibbles stuff gets complicated because movement is not time dependent but frame dependent.
More Patterns...

And Now?

Please give the game a try. I am looking forward to get your feedback. I even take contributions on GitHub.

Have Fun!

Jest Recap: Access `private` Members in TypeScript Unit Tests

Hauke T. — Wed, 14 Sep 2022 18:09:34 +0000

TL;DR: Use bracket notation to Access `private` properties

expect(inst["_somePrivateProp"]).toBe("foo"); // OK

Disclaimer

This is not a lengthy discussion. But a small reference type post. There are other (lengthy) posts that go into the details. I like it short.

Introduction

There is some ongoing debate about testing private members (methods, fields, properties, ...). In my opinion there are occasions where it is useful to do that.

It is not possible to directly inspect/test private members in languages like C#. But there is a common inheritance based workround, where private members are made protected.

In your test code you extend those classes and write wrappers/accessors to access these members. Then you actually test your derived class.

This is cumbersome and also changes the semantics of the class you want to test. private members appear to be intended to be accessed in derived classes. Which is not the case!

JavaScript/TypeScript

JavaScript/TypeScript does not require you to do that (at least for TypeScript private members, not for ES private (#) class fields).

// mod.ts
export class SomeClass {
    private _somePrivateProp = "foo";
}

JavaScript does not care if your member is marked private by TypeScript.
The TypeScript compiler enforces that you don't access private members from outside the class using dot notation (inst.prop).
But it is possible to access the property using bracket notation (inst["prop"]).

// mod.test.ts
import {SomeClass} from "./mod.ts";
test("privatePropIsFoo", () => {
    const inst = new SomeClass();
    expect(inst._somePrivateProp).toBe("foo"); // TS2341: Property '_somePrivateProp' is private and only accessible within class 'SomeClass'.

    expect(inst["_somePrivateProp"]).toBe("foo"); // OK
})

This is great because refactoring tools still work. And it saves a lot of redundant code.

A caveat

jest.spy(inst, "_privateMethod") will not work, because TypeScript enforces that only public methods are spied on. The simplest workaround is to cast inst as any. Until there is a Utility Type that treats all members as public (as already suggested).

Forem: Hauke T.

Today, Google search AI hallucinated a new HTML-Entity to display a double left arrow (⇐): `&larrarr;`. In fact it should be `&lArr;` html.spec.whatwg.org/#entity-lArr

Updating to Jest 30 is Frustrating (it's JSDOM)

The Easy Part

The Hard Part

The impossible Part

The "Solution"

Testing is hard these days: Jest 30 with JSDOM 21 won't let me mock `window.location` and Chrome 141 broke TestCafe with its new "LocalNetworkAccessChecks". 🤮

Thought of the Day: Most companies are not willing to pay developers to maintain OSS-Software. OSS-Developers may introduce breaking changes as they see fit. Companies have to pay the price, when they have to upgrade their dependencies regularly.

David Gilbertson Warned us About The Latest NPM Attack

Something is Odd About MDN These Days - And Googles AI is Gaslighting me About it...

TIL: Synchronous import in ES-Modules using module.createRequire (Node)

Jest Recap: Safely Mock Properties and Methods of Global Objects

TL;DR:

What?

Mocking Properties

Mocking Methods

You Must Clean up

How to Mock Something for all Tests

Jest Recap: What Runs When?

TL;DR: Execution Order

Disclaimer

There are Rules

Basic Example

What happens?

Advanced Version

Wibbles - W(eb) (N)ibbles - Recreating "The Worm", Snake, Nibbles and the like

Why?

Side Projects!

State

A Series?

And Now?

Jest Recap: Access `private` Members in TypeScript Unit Tests

TL;DR: Use bracket notation to Access private properties

Disclaimer

Introduction

JavaScript/TypeScript

A caveat

Today, Google search AI hallucinated a new HTML-Entity to display a double left arrow (⇐): `&larrarr;`. In fact it should be `⇐` html.spec.whatwg.org/#entity-lArr

TL;DR: Use bracket notation to Access `private` properties