Skip to content

Give the frontend tests, and fix what they found - #267

Merged
ramonski merged 1 commit into
masterfrom
test/frontend-harness-and-two-fixes
Sep 15, 2026
Merged

ramonski merged 1 commit into
masterfrom
test/frontend-harness-and-two-fixes

Conversation

@ramonski

Copy link
Copy Markdown
Member

The frontend had no automated check beyond tsc, which is strict and already clean. This adds vitest and starts where reading cannot settle the question: pure functions whose output depends on a locale or a clock.

Two bugs, both found by the first tests written against them.

Org timestamps with a non-English weekday lost their time.

relativeDate matched the weekday with \w{3}. Kaisho writes an English three-letter abbreviation on purpose — _EN_WEEKDAYS in kaisho/org/clock.py, with a comment explaining that it keeps the file locale-independent — but these org files are edited in Emacs too, and Emacs writes the weekday in the running locale. German gives Mo, Di, Mi: two letters.

Those failed the pattern, then failed new Date(), and fell through to the date-only branch, which drops the time:

"2026-06-15 Mon 09:00"    regex: yes    -> "3 hours ago"
"2026-06-15 Mo 09:00"     regex: no     -> "12 hours ago"   (midnight)
"2026-06-15 Monday 09:00" regex: no     -> "12 hours ago"

The Python parser takes \S+ for exactly this reason. Now so does this one.

The clock widget heading was always English.

formatDateHeading hardcoded "en-US". ClockWidget renders either the translated word for today or this, so a German user saw "Heute" one day and "Apr 12" the next. formatDateLabel in dateLabel.ts has always used i18n.language; this is the same rule.

en: Apr 12    de: 12. Apr.    es: 12 abr    ru: 12 апр.

Setup note. src/test/setup.ts restores jsdom's localStorage. Node 22+ ships an experimental built-in that is undefined without --localstorage-file, and it shadows jsdom's — so window exists while localStorage does not, which reads like a broken jsdom and is not. Anything importing i18n needs it, since detectLanguage() reads the stored language at import time.

pnpm test runs it. 15 tests. tsc clean, build clean.

The pnpm-workspace.yaml approves esbuild's install script; pnpm blocks build scripts by default, which is the right default, and vitest will not start without the binary it puts in place.

The frontend had no automated check beyond tsc, which is
strict and already clean. This adds vitest and starts
where reading cannot settle the question: pure functions
whose output depends on a locale or a clock.

Two bugs, both found by the first tests written against
them.

Org timestamps with a non-English weekday lost their time.
relativeDate matched the weekday with \w{3}. Kaisho writes
an English three-letter abbreviation on purpose
(_EN_WEEKDAYS in kaisho/org/clock.py, with a comment
explaining that it keeps the file locale-independent), but
these files are edited in Emacs too, and Emacs writes the
weekday in the running locale: German gives Mo, Di, Mi.
Those failed the pattern, then failed new Date(), and fell
through to the date-only branch, which drops the time --
so a 09:00 entry rendered as midnight. The Python parser
takes \S+ for exactly this reason.

The clock widget heading was always English.
formatDateHeading hardcoded en-US, and ClockWidget renders
either the translated word for today or this, so a German
user saw Heute one day and Apr 12 the next.
formatDateLabel has always used i18n.language.

src/test/setup.ts restores jsdom's localStorage: Node 22+
ships an experimental built-in that is undefined without
--localstorage-file and shadows jsdom's, so window exists
while localStorage does not. Anything importing i18n needs
it.

pnpm-workspace.yaml approves esbuild's install script.
pnpm blocks build scripts by default, which is the right
default, and vitest will not start without the binary.
@ramonski
ramonski merged commit 719a13b into master Sep 15, 2026
@ramonski
ramonski deleted the test/frontend-harness-and-two-fixes branch September 15, 2026 07:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant