Deno→Bun: all 30 deno.json locations assessed — 18 blocked on npm packages that do not exist

[hyperpolymath]

Owner ruling, 2026-08-26:

"deno is to go and bun is the way we are going, put it first everywhere unless not possible and explain why if not"

The governing document is corrected in #655, and the ~372 per-repo CLAUDE.md copies are being corrected repo-by-repo. This issue is the "explain why if not" half: I assessed all 30 live deno.json locations across 21 repos and none of them can be migrated to Bun and verified today. Four distinct blockers, in descending severity.

---

🚨 Blocker 1 — 18 of 30 depend on npm packages that do not exist (and never did)

This is not a Deno problem. These builds are red right now, under every runtime.

Measured against the live npm registry, with controls:

package	npm	note
affinescript	404	requested as ^12.0.0
@affinescript/core	404	requested as ^1.6.1
@affinescript/runtime	404	requested as 12.2.0
@affinescript/react	404
affinescript-tea	404
cadre-tea-router	404
rescript	✅ 12.3.1	control
@rescript/core	✅ 1.6.1	control
zod	✅ 4.4.3	registry-reachable control

JSR @affinescript/core → 404 as well.

The mechanism: the purge renamed packages and kept ReScript's version numbers

Comparing a purged manifest with one the purge missed:

purged — dicti0nary-attack/deno.json	unpurged — burble/client/web/deno.json
affinescript@^12.0.0	rescript@12.2.0
@affinescript/core@^1.6.1	@rescript/core@1.6.1
@affinescript/runtime@12.2.0	@rescript/runtime@12.2.0

The versions are ReScript's. hyperpolymath/affinescript publishes @affinescript/dom at 0.1.0 and an editor extension named affinescript at 0.1.0 — there is no @affinescript/core, no @affinescript/runtime, and no compiler CLI at v12. affinescript@^12.0.0 asks for a version that has never existed.

And the code was never ported: the same manifests still name .res.js / .res.mjs / .bs.js entry points — ReScript compiler output.

Migrating deno run -A npm:affinescript → bunx affinescript swaps one broken command for another. The blocker is the missing package, not the runtime.

Affected (18): accessibility-everywhere ×6 (tools/{cli,github-action,monitoring-api,safe-dom,stale/packages/core,stale/packages/scanner}), aerie/src/ui, ambientops/broad-spectrum, avow-protocol, candy-crash/frontend, civic-connect/indieweb2-bastion, dicti0nary-attack, docmatrix/ui, dotmatrix-fileprinter, excel-economic-numbers-tool, fireflag, flatracoon/netstack/interface, formatrix-docs/ui

Needs an owner decision — three options, none of which I should pick unilaterally:

1. publish a real affinescript compiler CLI to npm at a real version;
2. consume the compiler by git/path rather than by registry;
3. restore rescript specifiers in these manifests until AffineScript can build them (reintroduces a banned language, deliberately and temporarily).

---

Blocker 2 — 8 locations use HTTP imports Bun cannot resolve

Bun has no HTTP-import support; deno.land/std and esm.sh URLs must become npm specifiers first. This is real porting work, not a task-runner rename.

location	real HTTP imports
social-media-tools/polygraph/frontend	5 (esm.sh: react, react-dom, graphql, @apollo/client)
fireflag	4 (deno.land/std@0.220.0, esm.sh/@affinescript/runtime)
dipstick/services/{agent-swarm,publisher-deno,gateway-rescript,analyzer-rescript,pestle-observatory}	1 each (deno.land/std@0.208.0)
burble/admin	1

Blocker 3 — Deno runtime APIs in the sources

Deno.* calls do not exist under Bun, and deno test ≠ bun test (Deno.test() vs bun:test). Files using Deno.*: burble/client/web 11, fireflag 7, civic-connect/indieweb2-bastion 7, dotmatrix-fileprinter 5, accessibility-everywhere/tools/monitoring-api 4, plus singles in avow-protocol, ambientops/contracts, agent-swarm, publisher-deno, proven/bindings/deno.

Blocker 4 — one legitimate, permanent exception

proven/bindings/deno must stay on Deno. The estate policy already carves it out:

**/bindings/deno/**, **/bindings/typescript/** — interop target … We expose work to TS/Deno consumers without authoring TS as primary code path. Exemplar: proven/bindings/deno/ (72 files — Idris2 ABI exposed as Deno-native module). Never — these are consumer-facing bindings.

Its purpose is to be Deno-native. Migrating it would delete the deliverable. This is the ruling's "not possible", and the reason is recorded here.

---

Recommended order

1. Resolve Blocker 1 (owner decision above) — it is the largest and it is a live outage, independent of Deno/Bun.
2. Convert HTTP imports → npm specifiers (Blocker 2). Mechanical once decided, and it is a prerequisite for Bun.
3. Port Deno.* call sites and tests (Blocker 3), per repo.
4. Leave proven/bindings/deno on Deno permanently; keep the carve-out documented.

What I did not do, deliberately

I did not rewrite deno run → bun run anywhere. Every such change would have been unverifiable — the dependency graph does not resolve — and would have converted a visibly-red build into a differently-red build while looking like a completed migration. Given the estate's recent history of checks that report success without doing the work, a batch of unverifiable "migrated" PRs is the wrong artefact.

Related: #655 (governing document), ubicity#107 (the missing-manifest case), wordpress-tools#62 (rm -rf /lib — same purge, different failure mode).