TypeScript retirement: measured — 308 of 613 .ts files were never exempt, and the largest exempt class is upstream forks

[hyperpolymath]

Owner ruling, 2026-08-27: "no typescript … that should not exist at all", and — asked directly about the carve-outs — "Literally none — retire every exemption."

I measured the estate before acting. The ruling is achievable, but the exemptions are not where the TypeScript is.

Census — 613 .ts/.tsx files (excluding node_modules)

class	files	can it be retired?
NOT EXEMPT — estate-authored, already policy-violating	308	✅ this is the real target
upstream forks (rescript/, servers/, repos-monorepo/, linguist/)	174	❌ not our code
consumer-facing bindings (bindings/{deno,typescript,ts}/)	71	⚠️ retiring = dropping TS interop as a product
declaration files (*.d.ts)	39	⚠️ these are the FFI boundary, not implementation
bootstrap shims (affinescript-deno-test/, affinescript-cli/)	18	⚠️ they bootstrap the compiler that would replace them
build tooling configs (vite/vitest/tsup.config.ts)	2	✅ trivial
VS Code extension host	1	⚠️ @vscode/test-electron has no non-TS equivalent
telegram bot · archived repos · vendored deps/	0	— (nothing present)

The finding that matters

Half the estate's TypeScript was never exempt at all. 308 files — the largest class by far — are estate-authored .ts sitting outside every carve-out, grandfathered under "existing pre-2026-04-30 .ts/.tsx … while in-flight migration proceeds".

Concentration: developer-ecosystem 92, rescript-ecosystem 87, bulk_update_oikos 51, metadatastician 10, proven 7.

So retiring every exemption would remove at most 305 files and would not touch the 308 that are actually the debt. If the goal is "no TypeScript exists", the exemption table is the wrong lever — porting the 308 is the lever.

Three classes cannot be retired, structurally

1. Upstream forks — 174 files, the single largest exempt class. This is third-party code we vendor, not author: the ReScript compiler, third-party MCP servers, and GitHub linguist (whose samples/TypeScript/*.ts are machine-learning fixtures — deleting them breaks language detection). Removing TypeScript here means editing someone else's project inside our fork.
2. Declaration files — 39. *.d.ts files are type headers for FFI boundaries, not implementation. There is no runtime TypeScript in them.
3. Bootstrap shims — 18. They exist to bootstrap the AffineScript toolchain. Retiring them before AffineScript self-hosts removes the thing that builds the replacement.

I have implemented nothing here. These are reported, not resolved.

Recommended sequencing

1. Trivial now: the 2 build-tooling configs.
2. The actual work: port the 308 non-exempt estate-authored files, worst-first (developer-ecosystem, rescript-ecosystem). ⚠ Note hyperpolymath/affinescript's own doctrine — "The Cardinal Rule: Re-decompose. Do not transliterate." — this is per-file human rewriting, and tools/res-to-affine output is explicitly "not compilable … a starting point for the human."
3. Needs a product decision, not a migration: the 71 consumer bindings. Retiring them removes the estate's ability to expose work to TypeScript consumers.
4. Blocked on the toolchain: the 18 bootstrap shims and the 1 VS Code host — retire when AffineScript self-hosts (affinescript#446).
5. Recommend keeping exempt: the 174 upstream-fork files and the 39 .d.ts, on the grounds above.

Related: #655 (the ruling), #658, #661 (drift gate, which already fails any policy file advertising TypeScript).

[hyperpolymath]

Retraction — "structurally impossible" was wrong

Owner, 2026-08-27: "I do not accept the impossibility argument, if the worst comes to the worst, we need to build a library of possibility to extend to such problems and resolve them."

Correct, and the framing above is withdrawn. Nothing in that table is a law of nature. Each blocked class is a missing capability, and a missing capability is a thing you build. Restating each as what would have to exist:

The library of possibility

1. Upstream forks — 174 files. Mostly deletable, and one is embarrassing.

Broken down, the largest single group is 93 files: the vendored ReScript compiler, living in a directory named _OPM (other peoples repos) _SET/rescript.

ReScript is banned estate-wide. The estate is vendoring the compiler of a language it forbids. That is not an exemption to preserve — it is a deletion nobody proposed. No capability needs building; it needs removing.

For the genuine remainder:

• linguist — its samples/TypeScript/*.ts are ML fixtures for language detection. Capability: consume linguist as a pinned binary/data release rather than vendoring its source tree. Detection keeps working; no TypeScript enters the estate.
• third-party MCP servers — Capability: AffineScript MCP bindings (affinescript#446). Already the documented unblock condition; it just was never treated as the route to deleting the fork.

2. Declaration files — 39 *.d.ts. Generate, don't author.

.d.ts files are type headers for an FFI boundary. The estate already has a canonical machine-readable boundary: Idris2 ABI proofs and Zig-first FFI descriptions.

Capability: an ABI → declaration generator. Emit .d.ts at build time from the Idris2/Zig ABI, and commit none. No TypeScript is authored, none is tracked, and the type surface becomes provably consistent with the ABI instead of hand-maintained beside it.

3. Consumer bindings — 71 files. Same tool as #2.

These exist to expose estate work to TypeScript consumers. Capability: the same generator — derive the binding surface from the Idris2 ABI rather than hand-writing it.

⚠ This is the highest-leverage item in the whole programme. One generator retires 110 of the 305 exempt files — 36% — and it strengthens correctness rather than trading it away, because generated bindings cannot drift from the ABI they are generated from.

4. Bootstrap shims — 18 files. Self-hosting.

They bootstrap the toolchain that would replace them. Capability: AffineScript self-hosts its test runner and CLI (affinescript#446). affinescript#727 has just restored the CLI's publishable manifest and bin entry, which is a prerequisite.

5. VS Code extension host — 1 file. A JS API, not a TS one.

@vscode/test-electron is TypeScript-native, but the extension-host API it drives is JavaScript. Capability: AffineScript → JS extension output plus a harness driven by that compiled output. Nothing about the host requires TypeScript to be authored.

6. Archived repos — 0 present today, but for the record

Archived repos cannot accept PRs — but they can be unarchived, fixed, re-archived. A workflow, not a wall.

Revised bottom line

lever	files retired	what must be built
delete the vendored ReScript compiler	93	nothing — just remove it
ABI → declaration/binding generator	110	one tool
pin linguist as a release, not a fork	~small	packaging change
AffineScript self-hosting (#446)	19	already-tracked work
port the 308 non-exempt files	308	the actual migration

Nothing here requires an exemption to survive. The two things standing between the estate and zero authored TypeScript are one generator and the 308-file port — plus deleting a banned language's compiler that should never have been vendored.

The earlier "cannot be retired, structurally" table is superseded by this one.

[hyperpolymath]

Correction to my own comment above — the ReScript-compiler item was wrong

I claimed the 93 vendored ReScript-compiler files were "a deletion nobody proposed … no capability needs building". I checked, and that is wrong. Retracting it.

What is actually there:

• _OPM (other peoples repos) _SET is a plain local directory — not inside any git repository, so nothing in it is estate-tracked content. Deleting the local clone changes nothing on any remote.
• Its rescript/ checkout points at git@github.com:hyperpolymath/rescript.git — a genuine estate-owned fork of the ReScript compiler, not a stray vendored copy.

Why it cannot simply go: the fork is load-bearing right now. 18 estate repos still contain .res sources whose compiled .res.js/.bs.js output is what actually runs (see #658). That fork is their compiler. Removing it removes the only thing that can build them.

So it retires on exactly the same condition as everything else in this issue: after those sources are ported. It is not the free 93-file win I described.

Revised table (superseding the one in my previous comment):

lever	files retired	what must be built	available now?
ABI → declaration/binding generator	110	one tool	✅ yes — the real win
pin linguist as a release, not a fork	small	packaging change	✅ yes
AffineScript self-hosting (#446)	19	already-tracked work	⏳
retire the hyperpolymath/rescript fork	93	nothing — but blocked on the port	⏳ after the 308
port the 308 non-exempt files	308	the migration itself	⏳

The library-of-possibility argument stands unchanged — none of this needs a permanent exemption. But the sequencing is stricter than I first wrote: one item (the generator, 110 files) is genuinely available today; the rest queue behind the port.