deno

related: #5701 Experimental: enable it with .** Local font loading It loads system fonts by using with permission. Example AI Disclosure generated by Claude Code and Grok Build

Closes #35530 Problem The bootstrap desktop window was created visible up front and only navigated to after the in-process server bound (polled up to 15s). Between those, the user stared at an empty webview. The bug is platform-independent, but on Wayland the compositor only presents committed buffers, so the empty pre-load frame shows as solid black — the symptom in #35530. (X11 masks it with the theme background; macOS with white — much less noticeable.) Fix Reveal the window only once content has painted (the Electron model), using two new laufey capabilities (littledivy/laufey#29): creates the bootstrap window hidden () and reveals it from its handler — guarded by an so later in-app navigations don't re-show a window the app has hidden. keeps a single call plus a 10s fallback ** so a load that never finishes (e.g. the initial navigation errors) can't leave the user with no window at all. is idempotent. So the window's first visible frame already has content — no empty/black frame on any backend. Test plan clean (against a local laufey 0.5.0 patch) Manual: on Wayland, the startup black frame should be gone; window appears already painted. Needs verification on the reporter's setup.

_Disclaimer: this report was researched and drafted with the assistance of an LLM (Anthropic's Claude). The measurements are real and independently reproducible via the scripts/commands referenced herein; the LLM assisted with the benchmarking, isolation, and write-up._ Update for Deno 2.9.0 (leads; the original 2.8.3 report is retained as a baseline at the bottom). The original report (Deno 2.8.3, follow-up to [#28107]) showed retaining / Node-compat module graphs per reload — an all- stack (Hono + Drizzle + … + Clerk) climbed +530 MB/reload → OOM in ~6 saves. On 2.9.0 the homogeneous- case is fixed: that same all-npm stack now plateaus ~295 MB and reclaims, and bare plateaus too (was +19/reload on 2.8.3). But is not fully fixed — long soaks plus a fresh single-variable isolation on 2.9 pin a remaining unbounded ramp to when it is an island in an otherwise-JSR module graph: + Clerk climbs +51 MB/reload, dead-linear → OOM* (133 → 2.4 GB in 45 saves), while the same Clerk in an all- graph plateaus, and a light npm dep (postgres.js) never triggers it. This is exactly our app's shape: a JSR-native framework (, ) plus the one npm dep that has no JSR build — Clerk. TL;DR — what changed 2.8.3 → 2.9.0 On 2.9 the npm-compat retention is fixed for homogeneous- graphs — they reclaim and plateau. What remains is a heavy npm dependency (Clerk; Drizzle was the 2.8.3 example) whose node-compat module graph is retained linearly per reload when it sits as a minority island in a JSR-dominant graph — unbounded to OOM. A light npm dep (postgres.js) doesn't trigger it, and the same heavy dep in a homogeneous-npm graph plateaus. So the axis is npm-dep node-compat weight × graph composition, not the loader per se. 2.9.0 evidence — two long soaks Method (both): no load; reload = append a comment to the watched entry file (each restart verified via the watcher log); after , warm the feed once, then read of the (stable) PID. Loop stops at a 3 GB loop-level cap (a hard cgroup cap is avoided — it would force reclamation and fake a plateau). Deno 2.9.0, Postgres 16 over loopback, server pinned to 4 cores. A. all- (Drizzle) — PLATEAUS. , 32 reloads: . Last 10 reloads: net −7 MB (reclaiming). Overall +4 MB/reload and falling. Bounded ~295 MB. B. Full JSR-native app stack (jsr / + + the floor) — RAMPS. , 52 reloads to the 3 GB cap: . +54 MB/reload, dead-linear (last-8 slope = first-8 slope; no plateau). Would OOM. The isolation below pins the cause to the island — not the JSR modules or the DB driver. Cross-stack, first 6 reloads (2.9, median of 3 rounds), for context: A 6-reload window cannot distinguish plateau from ramp: Drizzle looks like +18/reload early, then decelerates and caps ~295 MB; the JSR/pg-driver stacks look similar early (+63–65) but stay linear to OOM. A short window overestimates the long-run rate for plateau-ers and hides the unbounded ones — long soaks are required. The 2.9 isolation — culprit: a heavy dep as an island in a JSR graph We re-ran the original report's same-library control with long soaks (5 reloads can't tell plateau from ramp), then added one dependency at a time on a bare Hono base (no load; same soak/cap method, ~45 reloads): The loader is not the axis. Bare and both plateau on 2.9 (~225 vs ~201) — the 2.8.3 +19/reload retention is fixed. The polarity didn't "flip"; homogeneous-npm graphs simply reclaim now. The DB driver is not the ramp. + and + both plateau (postgres.js was already the near-free +2 dep on 2.8.3; still is). The culprit is — but only as an island in a JSR-dominant graph. + Clerk ramps linearly to OOM (+51/reload, dead straight, would hit 3 GB ~reload 58); the same Clerk in an all- graph plateaus ( + Clerk ~265 MB; the all-npm Drizzle stack ~295 MB). So retention scales with an npm dep's node-compat weight × graph composition: a heavy npm package whose node-compat graph isn't reclaimed per reload when it's the minority in a JSR graph. This is exactly our real-world shape — a JSR-native stack (, ) plus the one npm dep with no JSR equivalent, Clerk — which is why every JSR-based stack in the app (, , ) ramps while the all-npm Drizzle stack plateaus. The earlier "Kysely anomaly" dissolves: its +10 was a 6-reload artifact; Kysely also imports + , so a long soak ramps like the rest. Short windows are unreliable — long soaks mandatory. Related Deno changes (2.8.3 → 2.9.0) We traced this against the Deno repo. The shift is 2.9.0-scoped — there are no patch releases between the 2.8.3 tag (2026-06-11) and 2.9.0 (2026-06-25). We did not find a changelog line that names " module-graph retention under ," but three things are directly relevant: [#28107] "Memory leak with file watcher" was closed COMPLETED (2026-06-04) as "not a per-run leak — it plateaus." A maintainer re-ran the original repro (, 8 restarts) and got — "grows during the first couple of restarts and then plateaus ~1.45 GB … consistent with allocator fragmentation and module/npm caches rather than a per-run leak." That plateau matches our 2.9 all-npm (Drizzle) result (grows, then caps ~295 MB). Two caveats in that comment matter here: it was tested on aarch64-macOS (we're on x86_64/glibc — allocator behavior differs, and our plateau-vs-ramp split is environment-sensitive), and it exercised the WASM backend, with the explicit note that native N-API addons are "the one path that can survive isolate teardown." Our ramper uses no native addon and no DB — isolated to bare + . What survives teardown here is the /node-compat module graph of a heavy npm dep embedded in a JSR graph — a path the WASM/npm repro on macOS never exercised. ([#35136], merged 2026-06-13 → ships in 2.9.0) is the same class of bug: "a watcher restart only dropped the future, but the previous generation of workers kept running … the leaked main worker task eventually crashed the process." But it fixes [#26052] = — a different entry point from our + , which that change does not cover. Lower-confidence 2.9.0 entries in the same area: and . So Deno currently treats watcher memory as resolved/plateauing, and fixed watcher-restart worker cleanup only for — yet a minimal, reproducible + + case ramps linearly to OOM (133 → 2.4 GB in 45 saves, no plateau), neither covered by #35136 nor consistent with the "it plateaus now" close of #28107. The homogeneous-npm plateau the maintainer observed is real (we confirm it); the uncovered case is a heavy dep as a minority island in a JSR graph. Reproduction (2.9.0) The ask (reframed) 1. Please reopen [#28107] (or track this as a new issue). Its "resolved — it plateaus" close holds for the homogeneous-npm path on 2.9 (we confirm the plateau, ~295 MB), but is directly contradicted by a minimal, isolated + + case that ramps linearly to OOM (133 MB → 2.4 GB in 45 reloads, no plateau, no reclamation) on x86_64/glibc — no DB, no native addon. The #28107 repro exercised only the WASM path on macOS; a heavy dep as a minority island in a JSR graph wasn't covered. 2. Why does a heavy dep reclaim in a homogeneous-npm graph but not as an island in a JSR graph? Same : with it plateaus (~265 MB); with it ramps to OOM. The 2.9 reclamation that fixed the all-npm case appears not to cover the npm-compat module graph of a lone npm dep in an otherwise-JSR module graph. A light npm dep (postgres.js) doesn't trigger it, so it scales with the dep's node-compat weight. 3. Does [#35136] ("shut down old workers on watcher restart") apply to + , or only ? The mechanism it fixes (old workers/isolate state not cancelled on restart) is the same class, but #26052/#35136 are scoped to . If doesn't get the same cancellation-on-restart, that gap is a prime suspect. 4. Failing a fix: release the previous run's retained /node-compat module graph on restart (the isolate itself is reclaimed — bare hono, and the driver stacks, all plateau), or a flag to fork a fresh process per reload (the fresh-process control is flat), plus a way to report what a process retains across reloads. Note for Clerk users specifically: since Clerk is -only (no JSR build), a JSR-native Deno app can't avoid this by going full-JSR — the one required import is itself the trigger. A JSR distribution of would sidestep it entirely (tracked in our ). Environment (2.9 update) Appendix — 2.8.3 baseline (the original report, retained for history + isolation methodology) Everything in this appendix was measured on Deno 2.8.3 and is superseded by the 2.9 update above for the all-npm case. It is kept because (a) it documents the same-library vs control and per-dep methodology — which we did re-run on 2.9 (see The 2.9 isolation above; culprit = a heavy npm dep as an island in a JSR graph, i.e. Clerk), and (b) it records the npm-compat mechanism that 2.9 fixed for homogeneous-npm graphs. Same library, two resolution paths (the 2.8.3 isolation). from retained ~+19 MB/reload; from ~+2 MB/reload (×2, stable) — identical library/code, only the /Node-compat loader differs, and the JSR build has more modules. So on 2.8.3 it was not library, byte size, or module count; the retained RSS tracked the /Node-compat module path. Module count didn't explain it (reversed on 2.8.3): a 327-module JSR graph stayed flat (~+7 MB/reload) while a 10-module npm graph ballooned (~+549 MB/reload). Per- dependency, alone on a base (2.8.3): On a real app + DB (2.8.3), replacing Drizzle (via raw ) and moving the rest to JSR took retention +552 → +64 MB/reload and warm RSS 496 → 152 MB, at ~equal throughput. Localization (2.8.3): unchanged (not glibc-arena); RSS climbed GBs past (not V8 old-space → code-space/npm-compat native suspect); per reload gave no point-in-time drop (deferred reclamation). Reproduced in (Debian, stock glibc). Fresh process per reload (external watcher / ) stayed flat. 2.9 outcome of this control (done — see The 2.9 isolation above): on 2.8.3 (+19) ≫ (+2); on 2.9 both plateau (~225 vs ~201) — the retention is fixed. The per-dep sweep no longer shows a broad npm penalty: and plateau on a base; only on ramps (+51/reload → OOM), while the same Clerk on plateaus. So it is not* a loader-polarity flip — it's a heavy npm dep left un-reclaimed as an island in a JSR graph. [#28107]: https://github.com/denoland/deno/issues/28107 [#35136]: https://github.com/denoland/deno/pull/35136 [#26052]: https://github.com/denoland/deno/issues/26052