Build output

KILLSCRIPT loads a module folder or a packaged .KillScript file. It does not load the TypeScript project itself. The CLI therefore produces two forms from the same source:

a folder build for installation and hot reload;
a packaged build for distribution.

Generated folder

The compiler writes .killscript/build/<ModuleName>/:

ModuleName/
├── module.json
├── config.json
├── inputs.json
├── scripts/
│   ├── main.lua
│   └── server.lua       # Reflex modules only
├── images/              # When present in public/
├── sounds/
├── ui/
└── localization.csv

Path	Source
`module.json`	Project metadata from `killscript.config.json`
`config.json`	Top-level `defineSettings()` declarations
`inputs.json`	Top-level `defineControls()` declarations
`scripts/main.lua`	Everything reachable from `src/client/main.ts`
`scripts/server.lua`	Everything reachable from `src/server/main.ts`
Other files	Copied from `public/` with their relative paths

Nested TypeScript files are statically bundled into the two entry scripts. They do not become runtime require() files, which avoids the game’s limited module-path lookup.

Development installation

killscript install or killscript dev synchronizes the folder build to:

<game Modules>/<ModuleName>/

The installed folder keeps the project’s module UUID and an ownership marker. The CLI only updates a missing folder, its own managed folder, or a folder with the same UUID. It will not silently overwrite another module.

Development uses the folder form so a save can update only changed files. No .KillScript import is required after every change.

Release package

npm run build

creates:

dist/ModuleName.KillScript

The file is an archive of the same internal folder structure, not a standalone text script. Distribute this file to users; keep the TypeScript project and .killscript/ build directory out of the package.

Use killscript build --no-pack when another tool needs only the generated folder.