Logbook of code changes

git · July 8, 2026, 9:58pm

git · July 8, 2026, 9:58pm

git · July 8, 2026, 9:58pm

git · July 8, 2026, 10:18pm

git · July 8, 2026, 10:46pm

git · July 8, 2026, 10:47pm

github.com/panodata/aika

Chore(deps): Update dateparser requirement from <1.3 to <1.5

committed 10:47PM - 08 Jul 26 UTC

dependabot[bot]

+1 -1

Updates the requirements on [dateparser](https://github.com/scrapinghub/datepars…er) to permit the latest version. - [Release notes](https://github.com/scrapinghub/dateparser/releases) - [Changelog](https://github.com/scrapinghub/dateparser/blob/master/HISTORY.rst) - [Commits](https://github.com/scrapinghub/dateparser/compare/v0.1.0...v1.4.1) --- updated-dependencies: - dependency-name: dateparser dependency-version: 1.4.1 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

perf(frontend): use plotly.js-basic-dist-min instead of full dist

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+24 -17

Meteogram, DataViewer, and the Stripes page only ever render `scatter` and `bar`… traces, but shipped the full plotly.js-dist-min bundle (every trace type including 3D/geo/mapbox). Swapping to the basic distribution drops the lazily-loaded Plotly chunk from ~4.8 MB to ~1.1 MB minified (~1.45 MB to ~0.37 MB gzipped). Verified: typecheck passes, and a real-Chromium render check confirms both scatter and bar traces still render correctly with the basic bundle. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

git · July 9, 2026, 5:32pm

git · July 9, 2026, 5:32pm

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

fix(frontend): run e2e tests against the production build in CI

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+5 -2

Playwright's webServer ran `npm run dev`, so e2e tests only ever exercised the u…noptimized Nuxt dev server -- a bundling/build regression (e.g. broken code-splitting, a chunk that fails to load) could pass e2e entirely undetected. In CI, build the app and serve it via `nuxt preview` instead; local runs keep the fast dev-server loop. Verified locally: with CI=true, the webServer step ran a full production build (46 chunks emitted), served it on port 4000, passed the backend health check, and Playwright began executing tests against it (the run only failed on a pre-existing local gap -- Firefox isn't installed in this dev environment -- which CI already covers via `playwright install --with-deps firefox`). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

git · July 9, 2026, 5:32pm

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

ci(frontend): build linux/arm64 natively instead of under QEMU

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+107 -23

The multi-arch Docker publish job (docker_frontend) took ~18.6 minutes, almost e…ntirely from a single step: `pnpm run build` on linux/arm64 under QEMU emulation took 817.6s (13.6 min) -- confirmed from the raw logs of the last scheduled run. Bundling/minification is CPU-bound and emulates very poorly, unlike the install step. amd64 was already ~free (full cache hit from build_and_test_frontend). GitHub now provides free native arm64-hosted runners for public repos (ubuntu-24.04-arm, GA since 2025-08-07), so split the single multi-platform build into Docker's standard cross-runner pattern: - docker_meta: computes tags/labels/version once (unchanged logic, extracted from the old docker_frontend job) - docker_frontend_build: matrix over {amd64 on ubuntu-latest, arm64 on ubuntu-24.04-arm}, each building natively (no QEMU) and pushing an untagged image by digest, with a per-arch GHA cache scope to avoid concurrent-write races between the two parallel jobs - docker_frontend_merge: downloads both digests and combines them into the real tagged multi-arch manifest via `docker buildx imagetools create`, then deploys to Coolify (unchanged) Also passes step outputs used in shell scripts via `env:` rather than direct `${{ }}` interpolation (template-injection hardening) -- verified clean with zizmor (0 findings) and validated YAML syntax. Cannot be dry-run locally (needs real GHCR push + native arm64 runner); the actual multi-arch build/push/merge/deploy behavior needs verifying against a live run before this is fully trusted. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

git · July 9, 2026, 5:32pm

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

chore(frontend): bump @antfu/eslint-config from 6.7.3 to 9.1.0

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+629 -325

Three majors (7/8/9), but all listed breaking changes are React-plugin specific …(this project only enables vue+typescript, no react) plus a perfectionist v5 bump. Ran lint --fix to apply the new rules: - perfectionist/sort-imports: reordered a few type/value imports (external before internal) in explorer.vue and two test files - e18e/prefer-array-some (stripes.vue): !arr.find(x) -> !arr.some(x), behaviorally identical, avoids constructing the found element - e18e/prefer-array-fill (stripes.vue): Array.from({length}, () => 1) -> Array.from({length}).fill(1); the autofix dropped the mapping callback TS was using to infer `number[]`, silently widening to `unknown[]` and breaking typecheck against Plotly's Datum[] type. Fixed with an explicit Array.from<number>(...) type argument rather than reverting the fix. Verified: typecheck, lint, all 115 unit tests, and a production build all pass clean. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

chore(frontend): bump eslint from 9.39.4 to 10.6.0

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+245 -275

Confirmed all dev-dependency peer ranges already declare eslint 10 support (@ant…fu/eslint-config, @nuxt/eslint, @intlify/eslint-plugin-vue-i18n all list ^9.10.0 || ^10.0.0 or similar). The main breaking changes in v10 (eslintrc removal, Node >=20.19 requirement) don't affect this project: it's already on flat config, and both local and CI Node versions clear the floor. Verified: typecheck, lint, all 115 unit tests, and a production build all pass clean. `pnpm peers check` shows some unmet peers (@typescript-eslint/parser, vitest, @tiptap/core) but confirmed these are pre-existing and unrelated to eslint. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

perf(frontend): stop eagerly bundling leaflet on every page

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+5 -8

app/plugins/leaflet.client.ts eagerly imported `leaflet` and `leaflet.markerclus…ter` (~450 KB) as a global Nuxt plugin, so it was always part of the initial bundle regardless of route -- even pages like /impressum or /api that never render a map. `<LMap use-global-leaflet>` (from @vue-leaflet) already lazily imports leaflet itself on mount and assigns it to window.L when not already set, and useLMarkerCluster() reads window.L only after the map fires its `ready` event. The plugin was redundant; deleting it lets Vite code-split leaflet into its own chunk that's only fetched on pages that actually render a map. Verified against the live backend with real-Chromium network capture: - /impressum and /api never fetch the heavy leaflet chunks, zero console errors - /history (station map) still renders a real Leaflet map with tiles loaded, window.L correctly populated, zero console errors Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

fix(frontend): bump CI Node.js from 20 to 24, fixing a real lint crash

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+4 -4

The PR's "Lint Frontend" CI job failed with: TypeError: roleStyles.keys(...).m…ap is not a function at eslint-plugin-unicorn/rules/consistent-function-style.js:332:54 eslint-plugin-unicorn@68.0.0 (pulled in transitively by the recent @antfu/eslint-config@9.1.0 bump) calls Map.prototype.keys().map(...) directly on the iterator, relying on native Iterator Helpers -- a feature that landed unflagged in Node 22, not Node 20. CI pinned node-version: '20', which doesn't have it; local dev machines running newer Node never hit this. Verified in isolated Docker containers with the exact same lockfile and pnpm version: `pnpm run lint` throws this exact error under node:20, and passes cleanly (exit 0) under node:24. Also aligns CI closer to the project's own Docker image, which already runs node:25-alpine. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

ci(frontend): run typecheck, lint, and unit tests in parallel

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+1 -3

These three jobs were needlessly chained (typecheck -> lint -> unit-tests -> e2e…-tests) even though none of them consumes another's output -- each just checks out and installs independently. Running them in parallel and only gating the expensive e2e job behind all three cuts PR feedback latency roughly to the length of the slowest of the three, instead of their sum. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

docs(frontend): document why the semver/undici-types overrides exist

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+10 -0

Investigated whether these could be dropped. Neither is a vulnerability fix (und…ici-types is pure .d.ts with zero runtime code and can't carry one; semver's only historical CVE was patched years before the override's ^7.8.2 floor, and no app code imports it directly -- it's build-tooling-only). But empirically, removing either breaks `pnpm install` outright: trustPolicy: no-downgrade rejects semver@6.3.1 (pulled in via nuxt-security -> unplugin-remove -> @babel/core@7.x, which has depended on semver ^6.3.1 for years) and undici-types@6.21.0 (pulled in via @duckdb/duckdb-wasm -> apache-arrow -> an older, separately- resolved @types/node@20.19.42) because those specific releases lack provenance attestation that earlier versions had. Confirmed no upstream fix is available yet: nuxt-security and unplugin-remove are both already at latest, and unplugin-remove still targets babel 7.x (babel 8, which moved to semver ^7.x, is too fresh to have been picked up). So both overrides stay, now with comments explaining why -- this is answering "is this safe to remove" for the next person who wonders, not a functional change. Lockfile resolution is byte-identical. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

git · July 9, 2026, 5:32pm

github.com/earthobservations/wetterdienst

fix(frontend): bump suncalc to v2, fixing a real polar-latitude crash

committed 05:32PM - 09 Jul 26 UTC

gutzbenj

+11 -19

v2 is a precision-focused rewrite (Meeus algorithms, ~5-20x better accuracy). It…s breaking changes (degrees instead of radians, north- based azimuth, apparent altitude) only affect getPosition/ getMoonPosition/getMoonIllumination -- Meteogram.vue only calls getTimes(), which is unaffected apart from one relevant change: missing sun events are now `null` instead of `Invalid Date`. That change fixes a real, currently-live bug: verified with suncalc@1 side-by-side that `times.sunrise` is an `Invalid Date` object (truthy, not caught by `??`) for polar-day/polar-night latitudes, so `sunrise.toISOString()` throws `RangeError: Invalid time value`. v2 returns `null` instead, which the existing `??` fallback chain already handles correctly. Also dropped `@types/suncalc` (v2 ships its own bundled TypeScript declarations) and replaced the `as any` escape hatch in Meteogram.vue with the real `SunTimes` type now that it's available. Verified: typecheck, lint, all 115 unit tests, and a production build all pass. Also drove a real browser against the live backend for station 01001 (Jan Mayen, 70.93degN) during actual polar-day conditions -- the meteogram renders correctly with day-shading spanning nearly the full 24h per day, zero console errors, confirming the fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>