Doom In TypeScript Types???

Running Doom inside TypeScript’s type system is no longer a punchline—it’s been built, booted, and made to render the first frame using types as a full virtual machine. The core achievement is an isolated “computer” whose components—RAM, caches, execution contexts, and tooling—are encoded entirely in TypeScript types, then evaluated by the TypeScript type checker to produce pixel output. The payoff is both technical and symbolic: it demonstrates that TypeScript’s type system can be pushed far beyond typical static checking into something that behaves like computation.

The project’s scale is staggering. The first frame required roughly 177 terabytes of generated type data after extreme optimizations, down from an initial estimate of 1.25 petabytes of type work. Getting there took 12 days of continual runs, with the type checker sustaining about 20 million type instantiations per second. The author also hand-wrote 12,364 tests, built custom tooling, and learned multiple new languages to overcome the gaps between “types as types” and “types as an execution substrate.”

Mechanically, the system treats TypeScript type evaluation as the engine cycle. The virtual machine implements the 116 WebAssembly instructions Doom needs, with the logic alone totaling about 18 million instructions. Each type-check pass corresponds to a machine state, and the final output becomes a TypeScript object where each value maps to a line of pixels—128,000 pixels for a 320×200 frame. Keyboard input is possible, but the emphasis is on the hard constraint: everything required for Doom—maps, textures, sprites, sounds, enemy AI, weapons, items, physics, and text—must be encodable in types.

To make this feasible, the usual safety rails of TypeScript had to be removed or raised. The compiler’s limits on excessive stack depth, deep type instantiation, union size, and recursion were lifted, and the author also increased the runtime stack limit on their machine. The cost was severe: type checking could consume around 100 GB of memory, syntax highlighting barely worked with files up to 1 GB, and language-server integrations and linters crashed. Even small mistakes—like misspelling an import—could trigger infinite loops that eventually exhausted heap memory and crashed the system.

The build also required low-level engineering normally handled by runtime features: a type-level garbage collector, L1 cache simulation, dead code elimination, a global value stack with stack-underflow protection, and dynamic dispatch tables. Linear memory is represented as a huge unsortable object, and binary arithmetic is implemented using two’s-complement numbers stored in string literals—plus reverse-iteration workarounds because TypeScript can only iterate strings from left to right. Doom’s engine uses only 64-bit and 32-bit integers, neither signed nor unsigned, forcing careful handling of bit-level semantics.

Beyond the technical feat, the discussion frames the effort as a “side quest” that teaches more than routine work: the project’s value comes from repeatedly jumping hurdles, learning compiler and VM internals from scratch, and refusing to accept the initial assumption that Doom couldn’t run in types. The creator signals that deeper technical breakdowns are coming in follow-up videos, with one aimed at a higher-level condensed journey and another focused on the super-technical details.