Tua

Typed Lua source-to-source tooling for LuaJIT and LÖVE projects.

Tua starts with normal Lua syntax, adds erased type syntax and a small amount of LuaJIT-safe sugar, then emits readable Lua 5.1-compatible code.

Why it exists

I like Lua because it is small, direct and works very well for games, but larger projects can make it harder to understand what a value is supposed to contain or what a function expects. Tua adds stronger editor feedback and static checks without asking me to leave the normal Lua and LÖVE workflow.

The generated result is still ordinary Lua source. It can be read, debugged and shipped without putting a new runtime between the game and LuaJIT.

What Tua provides

• Erased local, function, alias, table-shape, optional-field and union types.
• Readable Lua 5.1-compatible output for LuaJIT and LÖVE 11.x.
• A CLI for init, check, fmt, lint, build, traceback, watch and lsp.
• A compiler-backed language server and VS Code extension.
• Diagnostics, completion, hover information, signature help, rename, references, semantic tokens and inlay hints.
• LÖVE-aware helpers, API catalogs, callback guidance and asset-path validation.
• Mixed-source builds where .tua files compile to .lua while normal Lua files and assets are copied into the build output.

This repository contains the compiler core, CLI, language server, VS Code extension, documentation site and bundled example projects. It is one versioned toolchain instead of a group of unrelated editor scripts.

Lua first

Tua is designed to be adopted gradually. Existing Lua modules can stay as Lua, and .tua files can be added only where stronger tooling helps.

Types are removed during compilation, so the code that runs is still Lua 5.1-compatible. The generated source stays readable instead of becoming a format that only the compiler understands.

That part matters to me. A language tool should help me understand the project while i am working on it, without making the final game harder to inspect.

Built around LÖVE

The compiler and editor understand common LÖVE callbacks, constructors and asset paths. Tua can catch missing assets, provide API completion and help navigate between typed source and generated Lua.

Opt-in helpers cover some of the systems that repeatedly show up in games: vectors, sprite sheets, typed input, signals, state stores, state machines, ECS and object pools.

They are there when a project needs them, but the language still starts from normal Lua syntax rather than replacing everything with a framework.

The editor is part of the toolchain

The VS Code extension bundles the matching Tua language server for each platform. It provides compiler-backed editing, project commands for running or debugging LÖVE, generated Lua inspection and source-linked explorers for assets, modules, signals, state machines, ECS and object pools.

The repository also includes the CLI, documentation, release binaries and examples, so the same language behavior is used from the terminal, editor and build pipeline.

What you can do with it

• Write typed gameplay code that still ships as ordinary Lua source.
• Keep existing Lua modules and gradually adopt Tua.
• Build mixed Tua and Lua LÖVE projects.
• Navigate generated Lua with source maps.
• Debug runtime tracebacks against the original Tua source.
• Use project graphs to understand modules and game systems.

Tua is still an active project, but it already represents the kind of development workflow i wanted for my larger Lua and LÖVE projects: more information while writing the code, and normal Lua when it is time to run it.

The language guide, installation instructions and complete CLI reference are available in the documentation. The compiler, editor tooling and examples are available in the GitHub repository.