Follow-up to #263. That issue named two native addons and #264/#266 removed them, published as 0.53.42 / 0.53.43. A Worker consumer still cannot run on 0.53.x — the bundle now links, and the Worker then throws at module evaluation:
TypeError: Cannot set property close of #<Object> which has only a getter
at Object.fetch (miniflare/dist/src/workers/core/entry.worker.js)
That is graceful-fs patching fs.close, bundled into legal-agent's Worker from the integrations catalog chunk.
The real surface
Walking the published 0.53.43 graph from dist/catalog.js + dist/specs.js — 11 files — the external imports it reaches are:
net · tls · dns/promises · fs · path · url · crypto
pg · mysql2/promise · mongodb · redis · amqplib · kafkajs
read-excel-file/node · write-excel-file/node · csv-parse/sync · csv-stringify/sync
hyparquet · hyparquet-writer · ipaddr.js · jose
Two native addons were the loudest symptom, not the disease. The cause is structural and unchanged: specs/registry → bundled-manifests → import * as bundledAdapters from './adapters/index.js' re-exports every adapter so their static manifests can be read, and each adapter carries its own client.
Measured
| legal-agent (Cloudflare Workers) |
bundle |
GET /api/health |
agent-integrations@0.52.0 |
✅ 33,813 KiB raw |
✅ HTTP 200 |
agent-integrations@0.53.43 |
✅ builds (40,429 KiB raw) |
❌ TypeError at module evaluation |
legal-agent stays pinned at ^0.52.0; the bump is reverted rather than shipped green-looking.
What would actually fix it
The manifest is data. bundled-manifests reads a static shape off each adapter by instantiating it, which is why the implementations have to be imported at all. Emitting those manifests to a generated data module at build time — and having /catalog and /specs read that — would cut the Worker-facing entries off from every client at once, rather than one native dep at a time.
The guard added in #264 (src/worker-safe-subpaths.test.ts) already walks these two entries; widening its list from "native clients" to "any Node-only module" turns this issue into a failing test whenever it regresses.
Follow-up to #263. That issue named two native addons and #264/#266 removed them, published as 0.53.42 / 0.53.43. A Worker consumer still cannot run on 0.53.x — the bundle now links, and the Worker then throws at module evaluation:
That is
graceful-fspatchingfs.close, bundled into legal-agent's Worker from the integrations catalog chunk.The real surface
Walking the published 0.53.43 graph from
dist/catalog.js+dist/specs.js— 11 files — the external imports it reaches are:Two native addons were the loudest symptom, not the disease. The cause is structural and unchanged:
specs/registry→bundled-manifests→import * as bundledAdapters from './adapters/index.js're-exports every adapter so their static manifests can be read, and each adapter carries its own client.Measured
GET /api/healthagent-integrations@0.52.0agent-integrations@0.53.43legal-agent stays pinned at
^0.52.0; the bump is reverted rather than shipped green-looking.What would actually fix it
The manifest is data.
bundled-manifestsreads a static shape off each adapter by instantiating it, which is why the implementations have to be imported at all. Emitting those manifests to a generated data module at build time — and having/catalogand/specsread that — would cut the Worker-facing entries off from every client at once, rather than one native dep at a time.The guard added in #264 (
src/worker-safe-subpaths.test.ts) already walks these two entries; widening its list from "native clients" to "any Node-only module" turns this issue into a failing test whenever it regresses.