lux: a Rust package manager for Lua with a lockfile and parallel builds

A package manager written in Rust for a language that is not

lux is a package manager for Lua, written in Rust, published by the lumen-oss organisation and hosted at lux.lumen-labs.org. The description calls it a luxurious package manager for Lua, and the wordplay is the only flourish in an otherwise technical document.

The workspace layout shows the scale of the effort. There are nine crates: `lux-cli` and `lux-lib` are the default members, and `lux-lua`, `lux-definitions`, `lux-macros`, `lux-lsp`, `lux-workspace-hack`, `xtask` and `xtask-lua` sit alongside them. There is a `lux-lsp` crate, which is the language server, and the key features list mentions automatically adding project dependencies to `.luarc.json` for rich LSP diagnostics, so the tooling story goes beyond the package manager itself.

The core library depends on `mlua`, the Rust binding to Lua, with the serialize, macros, error-send and async features enabled. `git2` is there with ssh and https support, which is how dependencies are fetched, and `stylua` is a workspace dependency with the luau, lua52, lua53, lua54 and luajit features plus editorconfig support, which is how the formatter knows which dialect to target.

The release profile sets `lto = true` and `codegen-units = 1`, so the binary is optimised for size and speed at build time. The project is LGPL-3.0, and the last push was on 2026-10-19 with v0.47.0 tagged on 2026-10-05.

The workspace manifest is the clearest single view of the project structure:

[workspace]
members = [
  "lux-lib",
  "lux-cli",
  "lux-lua",
  "lux-definitions",
  "lux-macros",
  "lux-lsp",
  "lux-workspace-hack",
  "xtask",
  "xtask-lua",
]
default-members = ["lux-cli", "lux-lib"]

The project file replaces a pile of rockspecs

The change that defines lux is the project format. Instead of maintaining one `.rockspec` per package, dependencies, build steps and other settings live in a single `lux.toml` file, and the project format is described as TOML or Lua.

The rockspec approach has a real cost in a codebase of any size, and the README makes the pitch in the bluntest terms: say goodbye to managing 10 different rockspec files in your source code. A rockspec is a Lua file describing one package, and a project with several local packages ends up with a matching set of them, each of which has to be kept consistent with the others.

Lux does not abandon rockspecs, it absorbs them. There is full support for existing `.rockspec` files, and if you have a complex rockspec you would rather not rewrite in TOML, you can create an `extra.rockspec` file and everything works. There is also automatic generation of rockspecs, which matters for publishing rather than for consuming.

The comparison table makes the ecosystem claim concrete. Lux works with existing LuaRocks packages, supports Luarocks.org manifest namespaces and Luarocks.org dev packages, can pack and upload prebuilt binary rocks, and can install prebuilt binary rocks. The compatibility is with the distribution channel as well as the file format.

The lockfile, the parallel builds and the version constraints

Several features have no equivalent in LuaRocks, according to the comparison table.

The first is proper lockfile support with integrity checks, where LuaRocks v3.13.0 is marked as having only basic support covering dependency versions. The lockfile is what makes developer environments reproducible, and the README says it also makes lux easy to integrate with Nix, which is consistent with the presence of `flake.nix` and `flake.lock` in the repository root.

The second is parallel builds and installs. Installing a dependency tree one package at a time is the slowest part of a LuaRocks workflow, and the table marks parallel builds as absent in LuaRocks. With the Rust implementation, that part is fast.

The third is version constraints. The table shows LuaRocks cannot install packages using version constraints, while lux can, and the version scheme is SemVer where LuaRocks uses an arbitrary scheme. A SemVer-based constraint on a dependency is a different thing from a version range in a rockspec, and it is the sort of thing that makes an upgrade safe rather than an occasion for reading changelogs.

Installing multiple packages with a single command is also listed as a Lux-only feature, and there is auto-detection of external dependencies and Lua headers with `pkg-config`.

The parts of LuaRocks lux has not reimplemented

The comparison table is honest in the other direction too, and the gaps matter for anyone migrating.

Load installed packages from multiple install trees is marked as unsupported in lux, with an open issue reference, while LuaRocks supports it. The README also states plainly that some LuaRocks features have not been fully implemented yet because the project is still a work in progress.

Rockspecs with CVS, Mercurial, SVN or SSCM sources are marked as not supported in lux, with the reason given as YAGNI. That is a deliberate scope decision rather than an oversight, and for most projects fetching from git is the only source type in play.

One more Lux-only feature is worth calling out because it is unusual: resolving multiple versions of the same dependency at runtime. LuaRocks supports this too, but having it listed as a check in both columns while Lux handles it in a single flat install tree is a design difference in how the two tools resolve version conflicts.

The README also notes that a very complex build script can be handled by shelling out to `luarocks` if the tool detects it has to preserve maximum compatibility. So the escape hatch exists: lux can hand the hard cases back to the tool it is replacing.

Tooling in the package manager, not beside it

The feature list bundles the developer tools into the same command, which is the clearest difference in philosophy between the two tools.

Lux offers run tests with busted, linting with luacheck, and code formatting with stylua, luafmt or emmylua_codestyle; LuaRocks v3.13.0 is marked as not having linting or formatting. Static type checking is also Lux-only in the table.

The formatting entry is a real design decision. Choosing between three formatters, with stylua as the one that appears in the workspace dependencies, means the package manager does not impose one house style but still runs whichever the project has selected. A Lua team that already has a stylua configuration in its repository gets that configuration honoured, and one that has no configuration gets a default.

The LSP integration is the other end of the same idea. The `lux-lsp` crate is a workspace member, and the DX feature is described as automatically adding project dependencies to `.luarc.json`, the configuration file for the Lua language server, so that diagnostics cover the project's dependencies rather than only the code in the buffer. A package manager that knows the resolved dependency graph can inform the language server about it, and that is something a language server cannot work out on its own.

One gap to note: the LuaRocks comparison marks automatic Lua detection and installation as Lux-only, and the feature list expands on what that means. Lux takes care of installing the right versions of Lua headers automatically, and the phrasing in the README is aimed at a specific complaint: forget about users complaining they have the wrong Lua installed on their system.

Distributing projects and the pre-1.0 caveat

Lux can distribute a project, including its dependencies, as an install tree archive or as a static binary without the need for a Lua installation.

That is a meaningful capability for application distribution, and it connects to the prebuilt binary rocks support in the table, both for installing and for packing and uploading them. A Lua project that currently ships as source plus a rockspec and a Lua install script can instead ship as something self-contained. The `zip` dependency in the workspace and the `lux-lua` crate with its mlua bindings are the machinery behind that, and the `mlua` `async` and `serialize` features are what let the tool embed a Lua runtime.

The caveat is stated in a note near the top of the README, and it is the first thing to weigh: while fully functional, lux is a work in progress and does not have a 1.0 release yet. For a package manager, that is a specific kind of risk. The tool's own interface can change between releases, and a team that standardises on it is standardising on something that has not declared its interface stable.

The mitigating detail is the release cadence. The tags show v0.47.0 on 2026-10-05 with a matching lux-lsp-v0.47.0 and a lux-lib at 0.65.0, and the workspace version is 0.47.0. The three components are versioned separately, which is what a language server and a core library need, and it means a `lux-lib` update does not force a CLI update.

Editorial conclusion

lux fits a Lua team that has outgrown ad hoc luarocks installs and wants a lockfile, parallel builds, integrated linting and formatting, and version constraints in one place, while keeping the existing rockspec ecosystem working. It does not fit a project that needs the LuaRocks features not yet implemented, such as loading packages from multiple install trees, and it is not yet at a 1.0 release, so its own API can still move. Before adopting it, read the getting-started tutorial in the documentation, keep your existing rockspec working through an `extra.rockspec` file, and check the comparison table for the specific LuaRocks features your current build depends on.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. lumen-oss/lux on GitHub
3. Project website
4. README
5. Releases