Nevermore: 278 Roblox packages, two release toolchains, and a generated table with typos

Every package versions on its own schedule

Nevermore is not a single package with a single version. It is 278 packages, each published under the `@quenty` scope and each carrying its own changelog, and the release feed shows what that means in practice. Three tags from the same publish run on 2026-09-30 sit seconds apart: `@quenty/time` at 2.6.2, `@quenty/tie` at 10.51.2 and `@quenty/templateprovider` at 11.54.2. The version numbers have nothing to do with each other, because a package that has not changed does not move. The practical consequence is that upgrading is per package: adding one dependency can pull a new version of something else you never touched, and pinning the whole set means choosing 278 version numbers rather than one. The root manifest is private and named `@quenty/nevermore`, so the repository itself is a workspace rather than a distributed library.

The package table is generated, and it carries three naming slips

The list of all packages sits between generated markers in the README, with columns for description, install command, docs, source, changelog and npm. Being generated, it reflects exactly what the extractor emitted, including three disagreements between a package's name and the rest of its row. `AdorneeBoundingBox` installs as `@quenty/adorneeboundingbox` but its docs link points at an `AdorneeBoundingBoxUtils` path. `Aggregator`, described as aggregating async promise requests, links to `AggregatorUtils`. And `AdorneeUtils` installs as `@quenty/adorneeutils`, with an extra e in the scope name. So the lowercase install string is not always a faithful transformation of the package name, which is the sort of detail that costs an afternoon when a scripted install fails on one row.

auto-it and lerna both sit in the root manifest

The release tooling is doubled up. The dev dependencies include the auto-it suite, with plugins for conventional commits, first-time-contributor labelling, npm publishing and released notes, alongside a matching `.autorc` at the root. They also include `lerna` at version 9, with a `lerna.json` in the tree, while package management itself runs through pnpm, pinned to 10.27.0 with `pnpm-workspace.yaml` and `pnpm-lock.yaml`. Two version-management systems in one repository is a choice rather than an accident, but it means release behaviour is split across configuration files written for different tools. Documentation is a third system: `moonwave` and `moonwave.toml` generate the site at the project home page, and a lint script runs the moonwave extractor across `src` through lerna in parallel.

Luau linting cannot start until generated files exist

The Luau analysis step has a bootstrap that no other lint task needs. `lint:luau` invokes `luau-lsp analyze` against `src`, but it needs two artifacts first: a `sourcemap.json` and a `globalTypes.d.lua` of Roblox type definitions. The `prelint:luau` hook produces both, by running the build that asks rojo to emit a sourcemap from `default.project.json` and then calling the project's own CLI to download the Roblox types. The analyzer is also told to ignore `node_modules`, `*.story.lua`, `*.client.lua` and `*.server.lua`, and it runs with the LuauSolverV2 flag turned off. Two more linters cover the same source with different rules: selene for lint, configured from the root, and stylua for formatting, run in check mode across `src`, `games` and `plugins`.

lint:ts and build:ts are the same command

The TypeScript side of the repository is small and the scripts reflect that. Both `build:ts` and `lint:ts` expand to one command: a recursive pnpm run restricted to the `./tools/**` filter, with `./tools/nevermore-vscode` excluded. One script type-checks and the other rebuilds; neither covers the Luau that most of the repository is written in, which is handled by the selene, stylua and luau-lsp passes described earlier. Prettier covers the TypeScript trees with an ignore path taken from `.gitignore`, and it is the one dependency in the manifest pinned to an exact version, 2.7.1, while every other entry uses a range. Formatting the Lua side is a separate command, stylua invoked with the root config across `src`, `games` and `plugins`.

Copy and paste works until a package becomes a feature

There are two ways in, and the project is candid that they are not equal. The supported route is a package manager: install from npm or pnpm, then sync into Roblox with rojo.

npm install @quenty/maid

The fallback is to copy the source into ModuleScripts and refactor it into place, which works for small utilities and stops being ergonomic as a package approaches a full gameplay feature. The example the project gives for that limit is the inverse-kinematics package. That framing also explains the shape of the library. Maid, Rx, Binder, Spring, AccelTween, Signal, Promise, Octree, Blend, DataStore and the layered Camera system are infrastructure-shaped, and the claim attached to them is reach rather than novelty: code from Nevermore has powered over a billion play sessions on Roblox, and it is used in all Studio Koi Koi games.

Four tool managers and three editor configs in one root

The root directory is a good map of the project's conventions. Tool installation is declared twice, through `aftman.toml` and `foreman.toml`, and `.autorc` covers the release automation. Linting and formatting have their own config files: `selene.toml`, `stylua.toml`, `.styluaignore`, `.luaurc`, `.prettierrc` and `.prettierignore`. Editors are covered three ways, with `.vscode/`, a `Nevermore.code-workspace` file and a `Nevermore.sublime-project` file, plus a `.devcontainer/` for a containerised environment. Two Rojo project files sit side by side, `default.project.json` and `deploy.nevermore.json`, which separate local mapping from deployment mapping. There is also a `testez.toml` for the TestEZ runner, a `games/` directory of example projects, a `plugins/` directory, and both `CLAUDE.md` and a `.claude-plugin/` directory, so the repository ships its own agent instructions alongside its Lua tooling.

Editorial conclusion

Nevermore suits Roblox developers who want proven modules rather than a framework, especially teams already using rojo to sync a project, since the install path is a normal npm dependency and the well-known packages have their own documentation pages. Before you adopt it, expect to pin per package rather than per project, because version numbers diverge widely across the set and a single install does not move all of them at once. Read the generated table with care: at least three package names and install commands disagree with their documentation paths. If your game leans on the largest gameplay-level packages, check the copy-and-paste route first, since the project itself says ergonomics degrade there.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes