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).

[hyperpolymath]

Empty-linter is now a concrete Deno→Bun migration case in progress.

The semantic migration removed the Deno lockfile, runtime bindings, workflow,
test APIs, JSR assertions, examples, container metadata, task recipes, and
runtime claims. Its implemented AffineScript detector is bundled to a reviewed
.bun.js artefact; the Bun tests and repository audit run natively.

One upstream blocker was isolated rather than hidden: AffineScript's only
direct exportable ESM switch is still --deno-esm. Empty-linter uses it solely
for an ignored intermediate and immediately runs bun build --target bun,
which removes the unused Deno host shim. Native compiler support is tracked in
hyperpolymath/affinescript#734.

This distinction should be part of the campaign acceptance criteria: renaming a
.deno.js file is not a migration; runtime APIs, tests, locks, workflows,
documentation, host bindings, and executed controls must all be reconciled.

[hyperpolymath]

Re-measured 2026-08-31. Numbers stale — and the shape of the problem changed.

All 6 phantom packages still 404 on npm (affinescript, @affinescript/core, @affinescript/runtime, @affinescript/react, affinescript-tea, cadre-tea-router — exit-code checked, controls resolve). Blocker-1's owner decision (publish / git-path / restore) remains unmade.

But only 2 of the 18 named locations still carry phantom specifiers in a live manifest: ambientops/broad-spectrum/deno.json and civic-connect/indieweb2-bastion/deno.json. The other 16 lost their deno.json by deletion, with no Bun config added anywhere — zero bunfig.toml/bun.lock across all 13 repos; the tool dirs hold .affine+.mjs with no manifest at all. "Unblocked" means the named blocker vanished, not that anything builds — this is the deletion-as-migration pattern (#662) recurring at 16 locations.

Phantoms also persist off the named list: accessibility-everywhere/tools/stale/.../react/package.json, stale deno.lock in 7 repos, and — worst — the examples/web-project-deno.json template ships npm:affinescript@^12.1.0 replicated across ≥12 of these repos, so the scaffold keeps re-propagating the phantom (filed as a new issue).

Corrected scope: 2 live phantom locations + 13 repos needing an actual Bun migration + the template cure.

[hyperpolymath]

This was ruled on 2026-08-27 — recording it here, because it was never written back

The ruling exists but never reached this issue, so #709 still lists it as an
open decision. It is not open.

Owner ruling, 2026-08-27 — #658: switch consumers to git-path.
Nothing under @affinescript resolves on npm or JSR — including
@affinescript/dom, which this issue believed was published. Repoint
dependents at git specifiers so they build, and leave a TODO pointing here.
Owner publishes to a registry later.

What that means for the 18 blocked locations

Blocker 1 above says 18 of 30 deno.json locations depend on npm packages that
do not exist and never did (affinescript@^12.0.0, @affinescript/core,
@affinescript/runtime, @affinescript/react, affinescript-tea,
cadre-tea-router), carrying ReScript's version numbers because the purge
renamed the packages without porting the code — the same manifests still name
.res.js / .res.mjs / .bs.js entry points.

The ruling means the fix is not "wait for npm": repoint at
git+https://github.com/hyperpolymath/affinescript specifiers. That is a
mechanical change and it does not depend on a publish.

What it does NOT settle

• It does not make the code work. A git specifier resolves the package; the
  ReScript-output entry points are a separate defect.
• It does not touch Blocker 1's real premise — that these builds are red
  today under every runtime, so this was never a Deno-vs-Bun problem.
• It is a build-unblock, not a port.

No action taken on this issue; recording the ruling so it stops being re-asked.

[hyperpolymath]

This blocker is row D10 on #787, the single consolidated decision sheet (with #637, #715 and #709).

The three arms as posed there: (a) publish a real affinescript compiler CLI to npm at a real version — the elegance arm · (b) consume the compiler by git/path · (c) restore rescript specifiers until AffineScript can build them.

Standing since 2026-08-28 and holding 18 builds red under every runtime, so it is one of the longest-running effort-unblocked rows on the estate. Two details that constrain the arms: affinescript@^12.0.0 requests a version that has never existed (the 12.x line is ReScript's), and the manifests still name .res.js / .bs.js entry points — so (c) is closer to the current tree than it looks, and (a) has to mint the entry-point names too.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VG5AnnA12E8GikbXZS7NbD