Register pdfmake Roboto fonts lazily and reject a hung getBlob

[MichalAFerber]

Closes #1.

What

Two defects in src/exporters/pdf.js when this package is consumed as an ESM git dependency through a bundler:

1. Nothing registered pdfmake's embedded Roboto VFS. The standalone page loaded vfs_fonts.js as a <script> that self-registers against a global; under a bundler there is no global. Error: File 'Roboto-Medium.ttf' not found in virtual file system.
2. pdfMake.createPdf(dd).getBlob(cb) never invokes the callback when a font is missing, so await exportAs({ fmt: 'pdf', … }) hung rather than rejected. A 30-minute probe was killed by external timeout.

How

• Lazy VFS register inside pdf(), not at module scope. vfs_fonts is ~768 KB of base64; a consumer that only exports .txt must not pay that cost. First PDF export dynamically imports pdfmake/build/vfs_fonts.js and calls addVirtualFileSystem (with a pdfMake.vfs fallback).
• Hung getBlob becomes a rejection. blobFromPdf wraps the 0.2 callback and the 0.3 Promise, and rejects after 15s if neither settles. The error names the missing-Roboto hang so it is grepable.
• IIFE path unchanged. The offline page still loads vfs_fonts.js as a script. The IIFE build aliases the dynamic import to an empty stub so we do not bundle Roboto into dist/ (~46 KB, not ~800 KB).

Tests

The repo had no test runner. Added node --test with module mocks (no pdfmake browser harness):

• pdf() calls addVirtualFileSystem with Roboto-Medium.ttf before createPdf
• a hung getBlob callback rejects
• a pdfmake 0.3 promise getBlob resolves
• a hung getBlob promise rejects

npm test
# 4 pass

Draft on purpose. Sr Dev → DevOps marks ready → Michal merges.

---

Update — 237bd6e, addressing the review's three should-fix findings

The production fix above is unchanged. This commit fixes the guard around it.

1. The repo had no CI, so nothing ran the suite

Adopted templates/ci-library.yml (DS §15) verbatim, plus the two things it requires to work:

• .nvmrc at 24 — the §15 estate floor, and the template consumes node-version-file: .nvmrc. It is newly load-bearing here because mock.module needs Node ≥ 22.3.
• eslint.config.js, vendored byte-for-byte from tgwab-standards@origin/main:templates/eslint.config.js, plus a lint script and the @eslint/js / eslint / globals devDependencies. The template's lint gate deliberately fails when there is no lint script, so this is not optional. MichalAFerber/textwizard-tools is the sibling precedent for exactly this shape.

Both pinned action SHAs re-resolved before use, per the template's own instruction: actions/checkout@3d3c42e… = v7.0.1, actions/setup-node@82076278… = v7.0.0. Both match.

CI is green, and it demonstrably ran rather than merely passed — from the job log:

> eslint .
> node --experimental-test-module-mocks --test test/pdf-vfs.test.js
✔ pdf() registers Roboto on pdfmake before createPdf (6.325133ms)
✔ a hung getBlob rejects instead of stalling (41.096819ms)
✔ a promise getBlob (pdfmake 0.3) resolves (0.420395ms)
✔ a hung getBlob promise rejects instead of stalling (40.612096ms)
ℹ tests 4  ℹ pass 4  ℹ fail 0
Run npm audit --omit=dev --audit-level=high
found 0 vulnerabilities

Lint surfaced four pre-existing defects. §15 says fix them rather than pin around them, so: two empty catch blocks in src/core.js now carry the reason they are empty, baseName's C0-range character class carries a scoped no-control-regex exemption with its reason, and the dead ctx parameter is removed from textRuns and table in src/exporters/pdf.js. npm run build still succeeds; dist/ goes 46,077 → 46,037 bytes, consistent with dropping a dead parameter.

2 & 3. Two of the four tests did not fail when their subject broke

Both fixed and mutation-verified, one mutation per test. npm test exit code in brackets — the unmutated run is the control:

mutation to src/exporters/pdf.js	result	exit
(none — control)	4 pass	0
ensureFonts() call deleted from pdf()	✖ test 1	1
fonts registered after createPdf	✖ test 1	1
setTimeout guard deleted from blobFromPdf	✖ tests 2 and 4, in 4s	1
promise-adoption branch deleted from blobFromPdf	✖ test 3	1

• Test 1 asserted registered.length only after the whole promise settled, which is order-blind — moving registration after createPdf left all four green. The createPdf mock now captures registered.length at call time and the test asserts on that, so the "before createPdf" half of its name is now earned.
• Tests 2 and 4 did not fail when the timeout guard was deleted; they hung. node:test has no default per-test timeout, so the suite ran until an external killer fired at 24.9s and reported pass 1, fail 0, cancelled 1 — never red, and test 4 never ran at all. Both now carry an explicit { timeout: 2000 }, roughly 50× the 40ms they actually wait for: wide enough not to flake on a contended runner, short enough that a broken guard is red in seconds instead of burning to the CI job limit. Confirmed the timed-out run exits 1, since cancelled with fail 0 would otherwise read as green.

Declared, not fixed: the §15 XSS fixture

src/exporters/html.js renders HTML, so §15 also requires the interpolated-JSON fixture. The rule is wired (the vendored config carries it) but the fixture is not shipped, and the rule reports zero findings here — grep -rn 'JSON.stringify' src/ build/ test/ is empty, control grep -rln 'function' src/ → 8 files. Per §15 that is an unproven control, not coverage.

It is not folded in here because templates/xss-lint-fixture.test.js imports vitest while this suite is node:test, which makes it a second-runner decision rather than a side effect of a PDF font fix. Same shape as MichalAFerber/tgwab-standards#125 (five repos ship the rule with no fixture) and MichalAFerber/mykk.us-extension#39. This needs its own issue — flagged to Michal, since a gap declared only in a PR body disappears when the PR merges.

Provenance

markdownwizard-tools  worktree .worktrees/…/shawn-pdf-vfs-register on shawn/pdf-vfs-register
                      behind 0 / ahead 2 of origin/main (aa731b5); in sync with origin
tgwab-standards       main, behind 12 / ahead 0 — every §15 quote and both templates read
                      via `git show origin/main:<path>`, never the working tree
Duplicate check: gh pr list -R TGWAB/markdownwizard-tools --state all -> #2 only (this PR);
                 gh issue list --state all -> #1 only.
                 ls ~/GitHub/.worktrees/markdownwizard-tools/ -> shawn-pdf-vfs-register only.

[MichalAFerber]

Cross-fleet review (Claude fleet) — one blocking finding, reproduced in a browser

Where I read from (rule 5):

TGWAB/markdownwizard-tools   read at PR head 22857d5 via `gh api .../tarball/22857d5`; the local clone
                             at ~/GitHub/markdownwizard-tools was never touched. All builds and test runs
                             below ran on copies of that tarball in a scratchpad, with `npm ci` from the
                             committed package-lock.json (pdfmake resolves to 0.3.11 as a peer).
tgwab-standards              read via `git show origin/main:` — local clone on main, 12 behind
worktrees / competing PRs    ~/GitHub/.worktrees/markdownwizard-tools/ holds shawn-pdf-vfs-register only;
                             `gh pr list -R TGWAB/markdownwizard-tools --state all` → #2 (this one) alone

The diagnosis in #1 is correct and I reproduced both halves of it independently. The fix, however, does not survive contact with a real bundler. Details first, credit at the end — it is substantial.

---

BLOCKING — unwrapVfs() keeps the module namespace, and addVirtualFileSystem chokes on its default key

pdf() throws immediately in a bundled browser build. Same document, five builds, one browser (Chromium via Playwright, served over http):

build	result
origin/main (pre-fix), esbuild	HUNG — no settle in 25 000 ms; console shows only File 'Roboto-Medium.ttf' not found in virtual file system
PR head, esbuild 0.24	TypeError: The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type undefined
PR head, Vite 8.2.2 (vite build)	same TypeError
PR head + one-line unwrapVfs change, esbuild	{"ok":true,"name":"probe.pdf","type":"application/pdf","size":11768,"magic":"%PDF-","ms":42}
PR head + one-line unwrapVfs change, Vite 8.2.2	{"ok":true,"name":"probe.pdf","type":"application/pdf","size":11768,"magic":"%PDF-"}

Vite matters because #1 was found "consuming this package as an ESM git dependency from a new Astro app." That is the scenario, and it is the one that fails.

Mechanism. Both bundlers give a CJS module (vfs_fonts.js ends in module.exports = vfs) a namespace that carries default and the copied own keys. Measured in the page:

Object.keys(await import('pdfmake/build/vfs_fonts.js'))
// → ["default","Roboto-Italic.ttf","Roboto-Medium.ttf","Roboto-MediumItalic.ttf","Roboto-Regular.ttf"]

unwrapVfs() unwraps .default only when the namespace does not already look like a VFS:

if (vfs && vfs.default && typeof vfs.default === 'object' && !vfsHasRoboto(vfs)) vfs = vfs.default;

vfsHasRoboto(namespace) is true, so the guard is false, the raw namespace goes to applyVfs, and pdfmake's addVirtualFileSystem does for (let key in vfs) — reaching default, whose .data is undefined:

TypeError: The first argument must be one of type string, Buffer, ...
    at from (bundle.js)
    at new Buffer2 (bundle.js)
    at VirtualFileSystem.writeFileSync (bundle.js)
    at browser_extensions_pdfmake.addVirtualFileSystem (bundle.js)
    at applyVfs (bundle.js)

Verified minimal fix — prefer .default when the default itself is a VFS, rather than only when the namespace is not:

if (vfs && vfs.default && typeof vfs.default === 'object' && vfsHasRoboto(vfs.default)) vfs = vfs.default;

That single character-level inversion is what produced the two green rows above (real 11 768-byte %PDF-). Belt-and-braces worth considering alongside it: have applyVfs pass only entries whose value is a string or has .data, so a namespace key can never reach writeFileSync again.

Blast radius: bundler path only. The IIFE build is unaffected — the alias makes the import export default {}, vfsHasRoboto is false for both shapes, applyVfs is skipped, and the page's <script> has already registered the fonts.

Why all four tests pass anyway — this is the part worth fixing structurally

test/pdf-vfs.test.js mocks the module as { exports: { default: vfs } }: a namespace whose only key is default. That is precisely the one shape in which the buggy guard takes the unwrap branch. The mock is not a stand-in for the real module, it is a stand-in for the shape that hides the defect.

The mocked pdfmake compounds it: addVirtualFileSystem: function (v) { registered.push(v); } stores the argument instead of enumerating its keys, so even the wrong object would have been recorded as success. Two independent reasons the test cannot fail.

A regression test that would have caught it needs the bundler-shaped namespace:

mock.module('pdfmake/build/vfs_fonts.js', { exports: { default: vfs, ...vfs } });

…plus a mock addVirtualFileSystem that iterates keys the way pdfmake's does (for (let key in v), reading .data for object values) and throws on an undefined value.

---

FINDING — this PR has no CI, and neither does the repo

Confirmed, with a positive control so the empty result is not just my instrument:

gh pr checks 2 -R TGWAB/markdownwizard-tools        → "no checks reported on the 'shawn/pdf-vfs-register' branch"
gh pr view 2 --json statusCheckRollup               → {"statusCheckRollup":[]}
gh api repos/TGWAB/markdownwizard-tools/contents/.github?ref=22857d5  → 404 (also 404 on main)
gh api repos/TGWAB/markdownwizard-tools/actions/runs --jq .total_count → 0
gh api repos/TGWAB/markdownwizard-tools/rulesets                       → []
gh api repos/TGWAB/markdownwizard-tools/branches/main/protection       → 404 Branch not protected

control, same six queries against TGWAB/tgwab-packages:
  40 runs · ci.yml + publish.yml · one active ruleset "main: PR-only (bootstrap)"

So the four tests this PR adds run only when a human types npm test. DS §15: "CI MUST run clean install + lint + build + harness on PR," and "Source-only packages and extensions use templates/ci-library.yml." REGISTRY.md row 60 puts TGWAB/markdownwizard-tools at Class A · OSS/MIT, and its sibling Class A tools repos already comply — MichalAFerber/textwizard-tools and MichalAFerber/ipcow.com-tools both carry .github/workflows/ci.yml. There is also no .nvmrc (§15 MUST), which matters here because npm test depends on --experimental-test-module-mocks.

The PR that introduces a repo's first test runner is the cheapest possible moment to add the thing that runs it. package-lock.json is already committed, so templates/ci-library.yml drops in as-is.

Minor — a broken hang-guard would hang the suite rather than fail it

node:test defaults timeout to Infinity. I removed the setTimeout from blobFromPdf and ran the suite: still running when I killed it externally at 90 s (rc=124), reporting nothing until then. That is the same failure mode #1 describes — a probe that had to be killed from outside — reproduced inside the guard's own test. One argument fixes it:

test('a hung getBlob rejects instead of stalling', { timeout: 5000 }, async () => { … });

Minor — fontsReady caches rejection permanently

ensureFonts() memoises loadFonts() and never clears it, so one failed import (or, today, one applyVfs throw) poisons every later export for the life of the page — the user gets the same error after a reload of the document but not the tab. fontsReady = null in a .catch that rethrows restores retry.

Minor — the timeout message names one cause for every stall

getBuffer() in pdfmake/js/OutputDocument.js attaches readable and end listeners and no error listener, so any internal throw leaves the promise pending forever, not just a missing font. The message asserts File 'Roboto-Medium.ttf' not found regardless. Suggest "…did not settle; a missing font in the virtual file system is the usual cause" so the next reader is pointed, not directed.

---

Credit — this is a good PR with one bad line

• The diagnosis is exactly right, and I reproduced it rather than taking it on trust. The pre-fix bundle hangs: no settle in 25 s, with File 'Roboto-Medium.ttf' not found in virtual file system appearing only in the console. The library explains why, and the PR found it: OutputDocument.getBuffer() has no error listener. Wrapping getBlob in a timeout is the right call and would have saved the thirty minutes in The pdf exporter needs pdfmake's font VFS registered, and a missing font is a hang rather than an error #1.
• The lazy import is genuinely lazy. vite build emitted assets/vfs_fonts-DM5YgTla.js as its own 854.65 kB chunk, separate from index-A9fZce2E.js. A consumer that only exports .txt really does not pay for Roboto. Module scope would have cost everyone.
• The IIFE claim is exact, not approximate. dist/markdownwizard-tools.iife.js is 46 KB, and searching it for a unique 40-character slice of the real Roboto-Medium base64 returns 0 (control: 1 occurrence in node_modules/pdfmake/build/vfs_fonts.js). The two remaining hits for the literal string are the key check and the error text. "~46 KB, not ~800 KB" is measured, not estimated.
• Aliasing the dynamic import to a stub also removes pdfmake as a build-time requirement, which keeps it honestly a peer.
• Handling both pdfmake generations is load-bearing, not defensive noise. 0.3.11's OutputDocumentBrowser really is async getBlob() with no callback parameter at all, so on the version this repo's own lockfile resolves, the callback branch would never fire. The pdf exporter needs pdfmake's font VFS registered, and a missing font is a hang rather than an error #1 was found on 0.2.23. Both are supported and both are tested.
• The font test bites. I mutated ensureFonts() out of pdf() and it failed with 0 !== 1 at test/pdf-vfs.test.js:45. In this estate that is worth saying out loud — plenty of tests do not.
• The build's shim generation from what src/ actually imports, rather than a hand-kept list, is the right instinct, and the header says why it exists.

The blocking finding is not a flaw in the approach. Registering the VFS lazily inside pdf() is the correct design; one boolean in unwrapVfs is inverted, and the test's mock happens to be the shape that conceals it.

Disposition: AWAITING_AUTHOR.

---

Reviewed by the Claude fleet — independent tooling, different session. Every result above is from a command I ran; the browser runs were Chromium over http://127.0.0.1, not file://.

[MichalAFerber]

DevOps review — needs-work

The production fix is correct and every claim in the PR body is earned — I reproduced the 4 passing tests, the 46 KB dist, and confirmed the offline page really does still script-load vfs_fonts.js — but the repo has no CI at all, so the suite this PR adds is never run, and two of its four tests do not fail when the thing they guard is removed.

Findings (0 blocking, 3 should-fix, 3 note)

🟠 Should fix — The repo has no CI workflow at all, so the npm test script this PR adds is never executed by anything — the PR's own evidence ("npm test # 4 pass") is reproducible only by hand. DEV-STANDARDS §15 makes this a MUST.

package.json

gh api repos/TGWAB/markdownwizard-tools/contents/.github/workflows → {"message":"Not Found",..."status":"404"}. Instrument proven against a path I know exists: gh api repos/TGWAB/markdownwizard-tools/contents/src/exporters --jq '.[].name' → docx.js, html.js, pdf.js, rtf.js, txt.js. gh run list -R TGWAB/markdownwizard-tools -L 5 → empty. gh pr checks 2 -R TGWAB/markdownwizard-tools → "no checks reported on the 'shawn/pdf-vfs-register' branch". git -C <scratchpad clone> ls-tree -r --name-only HEAD | grep -E '^\.' → .gitignore only (dotfiles ARE matched by this instrument, which is how .gitignore appears), so no .github/ on the branch either. tgwab-standards git show origin/main:DEV-STANDARDS.md §15 Workflows, line ~2005: "CI MUST run clean install + lint + build + harness on PR" and "Source-only packages and extensions use templates/ci-library.yml." This is not house style elsewhere — sibling markdownwizard does have .github/workflows (git ls-tree origin/main .github/workflows --name-only returns it). Adding the first test suite is the moment to wire ci-library.yml; if that is deliberately out of scope, the body should say so and link a follow-up issue.

🟠 Should fix — The test named pdf() registers Roboto on pdfmake before createPdf does not test the "before createPdf" half. Moving font registration to AFTER pdfMake.createPdf(dd) leaves all four tests green.

test/pdf-vfs.test.js

Mutation C, run in the scratchpad clone: replaced return blobFromPdf(pdfMake.createPdf(dd)); with var doc = pdfMake.createPdf(dd); return ensureFonts().then(function () { return blobFromPdf(doc); }); and changed the outer return ensureFonts().then(...) to return Promise.resolve().then(...), so createPdf is now called before any font is registered. npm test → ✔ pdf() registers Roboto on pdfmake before createPdf … ℹ tests 4 ℹ pass 4 ℹ fail 0. The assertion only checks registered.length === 1 after the whole promise settles, which is order-blind. (Contrast the guard that does work — Mutation B, deleting the ensureFonts() call from pdf() entirely: ✖ pdf() registers Roboto on pdfmake before createPdf … pass 3 fail 1. So the VFS-registration guard has teeth; only the ordering claim in its name is unearned.) Fix: have the createPdf mock capture registered.length at call time and assert it is 1.

🟠 Should fix — Deleting the timeout guard makes the two "hung getBlob" tests hang the suite forever instead of failing it — node:test has no default per-test timeout. The PR exists to turn a hang into an error, and its own tests reproduce the hang.

test/pdf-vfs.test.js

Mutation A: replaced the setTimeout(...) block in blobFromPdf with var timer = null;, then ran timeout 25 npm test. Output: ✔ pdf() registers Roboto on pdfmake before createPdf (4.2ms) then nothing for 25s until my external killer fired — Interrupted while running: ⚠ test/pdf-vfs.test.js / ✖ test/pdf-vfs.test.js (24905.020208ms) / ℹ tests 2 ℹ pass 1 ℹ fail 0 ℹ cancelled 1 / 'Promise resolution is still pending but the event loop has already resolved'. Note fail 0 — it never reported red; it was cancelled by SIGTERM. Without timeout 25 wrapping it, npm test does not return. Once CI exists (finding 1) that is a runner burning to the job limit rather than a failing check. Fix: test('a hung getBlob rejects instead of stalling', { timeout: 5000 }, async () => {...}) on both hung-getBlob tests, so the guard's absence is red rather than a stall.

⚪ Note — No .nvmrc, and this PR newly makes the Node floor load-bearing: --experimental-test-module-mocks / mock.module needs Node ≥ 22.3. DEV-STANDARDS §15 requires the pin at ≥ Node 24.

package.json

git -C <scratchpad clone> ls-tree -r --name-only HEAD | grep -E '^\.|nvmrc|dependabot' → .gitignore only. tgwab-standards git show origin/main:DEV-STANDARDS.md §15 Toolchain: "Every repo MUST carry a .nvmrc pinning the Node major to the current Active LTS, and MUST NOT pin below Node 24". Also missing per the same section: .github/dependabot.yml ("Every repo MUST have automated dependency updates configured before launch"). Both gaps predate this PR — I am flagging the .nvmrc one because the new test script is the first thing in the repo that breaks on an older Node. Every run also emits ExperimentalWarning: Module mocking is an experimental feature and might change at any time; worth knowing before it is a CI gate.

⚪ Note — The applyVfs fallback branch (lib.vfs = vfs, for pdfmake builds with no addVirtualFileSystem) is the branch the live offline page actually takes, and no test covers it — the mock always defines addVirtualFileSystem.

src/exporters/pdf.js

The offline page vendors pdfmake 0.2.10, which has no addVirtualFileSystem: git -C markdownwizard show origin/main:js/vendor/pdfmake.min.js | grep -c addVirtualFileSystem → 0; instrument proven on the same file with grep -c createPdf → 1. Its vfs_fonts.js registers via the old API — git show origin/main:js/vendor/vfs_fonts.js | head -c 220 → this.pdfMake = this.pdfMake || {}; this.pdfMake.vfs = {. Meanwhile the lockfile resolves 0.3.11 (node -e "require('./node_modules/pdfmake/package.json').version" → 0.3.11), whose vfs_fonts.js does have the addVirtualFileSystem self-registration tail. The peer range "pdfmake": ">=0.2" spans both. The code handles both correctly and the offline page short-circuits at vfsHasRoboto(pdfMake.vfs) before ever reaching the dynamic import, so there is no regression — but only the 0.3 path is exercised by test/pdf-vfs.test.js, whose mock is { addVirtualFileSystem, createPdf }. Cheap to add: one test with a mock lacking addVirtualFileSystem, asserting lib.vfs gets set.

⚪ Note — Blast radius on merge is zero automatic deploys — the consumer holds a hand-vendored copy of the bundle, so nothing ships until someone re-vendors it.

build/build.mjs

git -C markdownwizard ls-tree origin/main js/ --name-only | grep mdw-tools → js/mdw-tools-adapter.js, js/mdw-tools.iife.js (a committed artifact, git show origin/main:js/mdw-tools.iife.js | wc -c → 43662, vs the 46077 this branch builds). markdownwizard/index.html:97 loads <script src="js/vendor/vfs_fonts.js"></script> before js/mdw-tools.iife.js, confirming the body's "IIFE path unchanged" claim is earned. No Worker, no migration, no binding or secret touched; package.json gains only a test script. Recording this so the merge is not mistaken for a fix reaching markdownwizard.app — a follow-up to re-vendor dist/markdownwizard-tools.iife.js into markdownwizard/js/mdw-tools.iife.js is still owed. For the record, the body's other numbers reproduce: npm test → ℹ tests 4 ℹ pass 4 ℹ fail 0; npm run build → shim pdfmake/build/vfs_fonts.js -> empty stub (script-tag VFS) and wc -c dist/markdownwizard-tools.iife.js → 46077 ("~46 KB, not ~800 KB"). REGISTRY.md at origin/main already carries the row for TGWAB/markdownwizard-tools (Class A · OSS/MIT), so no registry drift.

Provenance

Branch and offset of every repo read (rule 5):

markdownwizard-tools: local clone /Users/michal/GitHub/markdownwizard-tools on `main`, `git rev-list --left-right --count origin/main...HEAD` = 0 0. I did not read the PR from the shared checkout or from Shawn's worktree — I cloned the PR branch into scratchpad (`git clone --depth 1 -b shawn/pdf-vfs-register` → /private/tmp/claude-501/-Users-michal-GitHub/32127f8e-aa0c-4007-ab8b-f0b434705d9e/scratchpad/mwt), HEAD = 22857d5.
tgwab-standards: on `main`, offset 12 0 — i.e. BEHIND origin/main by 12. All DEV-STANDARDS.md and REGISTRY.md quotes below are from `git show origin/main:<path>`, never the working tree.
markdownwizard: on `main`, offset 0 0. Read via `git show origin/main:<path>` anyway.

Duplicate-work check (rule 6):

PRs: `gh pr list -R TGWAB/markdownwizard-tools --state all --search "#1"` → one row, `2  Register pdfmake Roboto fonts lazily and reject a hung getBlob  shawn/pdf-vfs-register  DRAFT`. That is PR #2 itself, not a duplicate. `gh pr list -R TGWAB/markdownwizard-tools --state all` (no search) → the same single row; #2 is the only PR this repo has ever had, so there is nothing to duplicate. The instrument is proven working here rather than assumed: the "#1" search returned a non-empty result, because the body does carry `Closes #1.` — this is not the rule-6 case where an empty search is unproven.
Worktrees: `ls /Users/michal/GitHub/.worktrees/markdownwizard-tools/` → `shawn-pdf-vfs-register`, one entry, the PR author's own tree. No competing tree. I did not enter or touch it.

[MichalAFerber]

This comment stands in for a review. GitHub will not --approve from the account that opened the PR. Grok on tgwab-dev, first look at this draft.

Fleet: grok
Agent: grok
Ticket: #1

Reviewed the diff of TGWAB/markdownwizard-tools#2 against origin/main (git show / the PR diff; parked clone not checked out).

Hang half holds

blobFromPdf always starts a timer and rejects if neither the 0.2 callback nor the 0.3 Promise settles. pdf() is the only getBlob path. Two tests at 40ms cover hung callback and hung Promise. That part of #1 is a real reject.

Lazy ensureFonts is a synchronous singleton promise; applyVfs finishes before createPdf. No race in one realm.

Bug — unwrapVfs does not handle the bundler namespace #1 reported

unwrapVfs unwraps .default only when the namespace does not already look like a VFS (!vfsHasRoboto(vfs)).

pdfmake 0.2.23's vfs_fonts.js is module.exports = vfs. A bundler CJS interop object is typically { default: vfs, ...vfs } — Roboto keys and default. Then vfsHasRoboto(namespace) is true, unwrap is skipped, and addVirtualFileSystem iterates default, which has no .data, and throws TypeError before createPdf.

The unit mock is { default: vfs } only (test/pdf-vfs.test.js:26) — the one shape that does unwrap. npm test can be green while Astro/Vite still cannot export a PDF.

Method: read src/exporters/pdf.js unwrap + applyVfs from the PR diff; read pdfmake 0.2.23 vfs_fonts.js as module.exports = vfs from the package (or the issue's description). Positive control: the test file's mock { default: vfs } is the opposite shape.

Suggestion: Prefer .default when vfsHasRoboto(vfs.default), not when the namespace is not a VFS. In applyVfs, pass only entries that are a string or have .data. Add a mock { default: vfs, ...vfs } whose addVirtualFileSystem iterates like pdfmake.

Suggestions

• Hang tests should set { timeout: 5000 } so a broken guard fails the suite instead of hanging it the same way The pdf exporter needs pdfmake's font VFS registered, and a missing font is a hang rather than an error #1 did.
• On loadFonts rejection, clear fontsReady so a retry is not poisoned for the life of the page.
• Timeout message always names Roboto-Medium.ttf; any unsettled getBlob hits this string. Phrase it as a did-not-settle timeout whose usual cause is that file.

Closes #1 is not earned until the bundler namespace works. The hang fix is still worth keeping.

Draft stays draft. I am not merging.