Summary
test/workers/documents.test.ts runs under real workerd via @cloudflare/vitest-pool-workers,
which is great — but it deliberately excludes the PDF read/write paths. wrangler.jsonc's own
comment says so:
this suite deliberately exercises only PDF-bypassing paths (markdownToDocx and the docx content
reader/decoder) -- proving those code paths execute inside a workerd isolate with no Node-only API
usage, without pulling PDF reading/writing into the actual test calls.
So the formats with their own layout engine and the whole pdf-codec dependency — the heaviest and
most intricate part of the package — have no Workers coverage at all.
Why this is the gap worth closing
For a Workers consumer, PDF → Markdown / PDF → docx is often the only reason to reach for this
package: it is the conversion no pure-XML library can do. That makes the untested path the one most
likely to be depended on in that runtime.
Static inspection is encouraging — I grepped every published dist/ for node: specifiers and found
them only in bin.js / bin.cjs (the CLI), never in the library graph. So there is no known
incompatibility. But "no Node imports" is weaker than "executes correctly in an isolate", especially
for code doing large typed-array work, and the exclusion is currently deliberate rather than
incidental.
Ask
Extend test/workers/** to cover at least one PDF read and one PDF write inside a workerd isolate:
pdfToMarkdown on a small fixture — the read path, pdf-codec's lexer/objects/content-read.markdownToPdf on a small fixture — the write path, which additionally exercises font resolution
and embedding.
Two tests would convert "no Node imports, so probably fine" into "proven". If the bundle-size issues
land first, the read-only entry point is the natural thing for the read test to import, so the same
test also guards that the narrow graph keeps working.
Note on cost
If pulling pdf-codec into the Workers suite is what the exclusion was avoiding — build time, or the
isolate's own memory ceiling — that is worth stating in the issue thread, since it would itself be
useful information for anyone evaluating the package for Workers.
Summary
test/workers/documents.test.tsruns under realworkerdvia@cloudflare/vitest-pool-workers,which is great — but it deliberately excludes the PDF read/write paths.
wrangler.jsonc's owncomment says so:
So the formats with their own layout engine and the whole
pdf-codecdependency — the heaviest andmost intricate part of the package — have no Workers coverage at all.
Why this is the gap worth closing
For a Workers consumer, PDF → Markdown / PDF → docx is often the only reason to reach for this
package: it is the conversion no pure-XML library can do. That makes the untested path the one most
likely to be depended on in that runtime.
Static inspection is encouraging — I grepped every published
dist/fornode:specifiers and foundthem only in
bin.js/bin.cjs(the CLI), never in the library graph. So there is no knownincompatibility. But "no Node imports" is weaker than "executes correctly in an isolate", especially
for code doing large typed-array work, and the exclusion is currently deliberate rather than
incidental.
Ask
Extend
test/workers/**to cover at least one PDF read and one PDF write inside aworkerdisolate:pdfToMarkdownon a small fixture — the read path,pdf-codec's lexer/objects/content-read.markdownToPdfon a small fixture — the write path, which additionally exercises font resolutionand embedding.
Two tests would convert "no Node imports, so probably fine" into "proven". If the bundle-size issues
land first, the read-only entry point is the natural thing for the read test to import, so the same
test also guards that the narrow graph keeps working.
Note on cost
If pulling
pdf-codecinto the Workers suite is what the exclusion was avoiding — build time, or theisolate's own memory ceiling — that is worth stating in the issue thread, since it would itself be
useful information for anyone evaluating the package for Workers.