The Lua API also ships as Lua stubs: plain .lua files with type annotations and no code. A Lua language server that reads them knows every function, its parameters and what it returns, so your editor completes api.make_ and warns when a call does not fit.

1. Download the stubs

Download the zip from the Lua API reference and unzip it somewhere that stays, outside the plugin’s folder, so it never ends up in your bundle:

mkdir -p ~/.prusa-slicer-lua-api
unzip prusa-slicer-lua-api-stubs-*.zip -d ~/.prusa-slicer-lua-api

2. Point the language server at them

Both common Lua language servers read the stubs. Put the file in the root of your plugin’s folder and use the absolute path to the folder you unzipped.

EmmyLua

What the slicer team uses (emmylua_doc_cli generates the reference). In VS Code it is the EmmyLua extension; it reads .emmyrc.json:

{
  "$schema": "https://raw.githubusercontent.com/EmmyLuaLs/emmylua-analyzer-rust/refs/heads/main/crates/emmylua_code_analysis/resources/schema.json",
  "workspace": {
    "library": ["/Users/you/.prusa-slicer-lua-api"]
  }
}

Lua Language Server

The Lua extension by sumneko in VS Code; Neovim (lua_ls) and Zed use the same server. It reads .luarc.json:

{
  "workspace.library": ["/Users/you/.prusa-slicer-lua-api"]
}

Reopen the folder. Hover over api.make_cube and you see its parameters; api. lists the whole module.

Keep them current

The stubs belong to one API version. When a new one comes out, download its stubs and replace the folder. The reference shows which version you are reading, and a plugin declares the version it needs in required_apis of its manifest.json.

The stubs are also a good way to teach an AI coding agent the API: point it at the folder.

Leave .emmyrc.json or .luarc.json out of the zip you sign: they are for you, not for the people who install the plugin.