# NevermoreEngine: a 278-package ModuleScript loader for Roblox

> Nevermore is a Luau package collection that syncs into Roblox through rojo. It is aimed at teams already using npm-style dependency management, and its install guide assumes that workflow.

**Quenty/NevermoreEngine** — ModuleScript loader with reusable and easy unified server-client modules for faster game development on Roblox.

- Repository: https://github.com/Quenty/NevermoreEngine
- Website: https://quenty.github.io/NevermoreEngine/
- Stars: 613 · Forks: 145
- Language: Lua
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/quenty-nevermoreengine

## The problem NevermoreEngine solves for Roblox teams

Roblox development has no standard package manager. Code is shared by copying ModuleScripts between places, by pasting snippets into a shared folder, or by re-implementing the same utility in every project. Nevermore attacks that gap by publishing its modules as npm packages and syncing them into Roblox with rojo, so a team can declare a dependency instead of copying a file.

The repository describes itself as a "ModuleScript loader with reusable and easy unified server-client modules for faster game development on Roblox." The audience is therefore Roblox developers who already work with a file-based workflow, not people building entirely inside Studio. The README states that the code has powered over a billion play sessions and is used in all Studio Koi Koi games, which tells you the intended scale is a production game, not a demo.

The package count matters more than the marketing line. There are 278 packages in the repository, and they are not all gameplay features. Maid cleans up connections, Signal and Promise fill in primitives that Roblox does not ship, Octree is a spatial data structure, and Blend is a declarative UI framework. A team can adopt one package, such as Maid, and ignore the rest.

## How the loader and the server-client split actually work

The repository is a monorepo. Top-level entries include src/, games/, plugins/, tools/, docs/, a pnpm-workspace.yaml, a lerna.json and a default.project.json. Each package lives under src/ with its own directory, and the README's package table links each one to a source path, a changelog and an npm page. The package.json at the root is marked "private": true, so the root is a workspace container rather than something you publish.

The server-client unification is a naming convention rather than a runtime trick. The lint script in package.json ignores files matching "**/*.client.lua" and "**/*.server.lua" when analyzing src, which shows that individual modules are split into client and server files inside the same package. The loader resolves those into the correct Roblox context. That is the mechanism behind the "unified server-client" claim: one package, two entry files, one dependency graph.

Tooling is part of the architecture. The build script runs rojo sourcemap against default.project.json and then strips sourcemap jest entries through @quenty/nevermore-cli. A separate lint:luau script runs luau-lsp analyze with a sourcemap, a base .luaurc and downloaded Roblox types. In other words, the repository is set up for static analysis against Roblox's API surface, and the sourcemap is a build artifact rather than a hand-maintained file.

## Installing NevermoreEngine with npm and rojo

The README gives one install path: npm or pnpm, followed by a rojo sync. You install a single package, not the whole engine. The example the README uses is Maid, the connection-cleanup utility.

```bash
npm install @quenty/maid
```

After that, the package has to reach Roblox. The README states that each package is designed to be synced into Roblox using rojo, and it points to an installation guide at quenty.github.io/NevermoreEngine/docs/install for the details. The repository itself carries a default.project.json at the top level, which is the rojo project file the build scripts reference.

A minimal rojo project therefore needs a mapping from the installed node_modules path into the Roblox tree. The README does not print that mapping in full, so treat the install guide as the source of truth rather than improvising one. What you should see after a successful sync is the Maid module available as a ModuleScript in the place, with its dependencies resolved by the loader.

The README also offers a second route: copy and paste. Many libraries can be pasted into ModuleScripts and run "with small refactors." The README is explicit that this gets less ergonomic as a package approaches a full-sized gameplay feature, and names Ik as the example where it stops being practical. That is a fair warning. Maid is a single file. Ik is not.

## Where NevermoreEngine gets awkward

The install story assumes a build pipeline. If your team edits places directly in Studio and has no rojo project, the documented path does not apply to you, and the fallback is copy-and-paste with manual refactoring. That is a real constraint, not a preference.

The second limitation is coupling. The README lists packages such as Binder, Blend, DataStore and CameraStackService, and those are not standalone utilities. Binder binds Roblox instances, Blend takes over UI state and animation, and the camera stack interops with Roblox's camera system. Adopting one of those means adopting its model of how a game is structured. A team that wants a single helper and nothing else is better served by Maid or Signal alone, and should read the dependency list before pulling in anything larger.

The third is versioning. The repository uses lerna and auto for releases, and the recent release list shows packages moving independently, with @quenty/viewport at 11.55.0 and @quenty/voicechat at 5.24.0. Per-package semver at that pace means a large dependency set will drift. The README does not document a rollback procedure or a policy for pinning versions across packages, so a team that needs reproducible builds has to establish that themselves.

## NevermoreEngine compared with a plain Rojo project

The obvious alternative is no dependency layer at all: a rojo project with a shared/ folder of hand-written ModuleScripts. The difference is not feature count, it is where the abstractions live. In a plain project, every game re-implements connection cleanup, a signal type and a promise wrapper, and each implementation drifts. Nevermore ships those as versioned packages with changelogs and API docs, so the utility layer is maintained once.

The cost is the opposite of the benefit. A plain project has no external dependency graph, no npm install step and no lerna-managed release cadence to track. Nevermore trades that simplicity for reuse. For a solo developer on a small game, the trade is usually not worth it. For a studio running several games off a shared codebase, the README's claim that the code is used across all Studio Koi Koi games is the relevant data point.

A second alternative is to cherry-pick patterns rather than packages. The README makes this point directly: many packages "represent not just useful code, but useful patterns, or ways of thinking about programming on Roblox." You can read the Maid source, write your own thirty-line cleanup object, and keep zero dependencies. That is a legitimate choice, and it is cheaper than it sounds for the smaller utilities.

## Licence and ongoing upgrade cost

NevermoreEngine is MIT licensed, and the repository carries a LICENSE.md at the top level. MIT is permissive: you can use, modify and redistribute the code, including in closed-source games, provided the copyright notice and permission notice are preserved. That last condition is the one teams miss when they copy a module into a place file and drop the header comment. This is a description of the licence text, not legal advice; check LICENSE.md and your own counsel for anything that matters.

The upgrade cost is the part worth planning for. Releases are frequent and per-package, and the changelog for each package lives at src/<package>/CHANGELOG.md, with a link from the README table. Upgrading one package means reading one changelog. Upgrading the set means reading many, and the README does not describe a coordinated release train. The repository's last push was on 2026-08-28, so the project is current, but currency is not the same as stability: a package at major version 11 has had ten breaking-change windows.

One practical mitigation is to depend on the smallest set of packages you actually need. The package table lists an install command per package, so the granularity is there. Pulling in the full engine to get Maid is the expensive way to do it.

## Conclusion

Adopt Nevermore if your Roblox project already uses rojo and you want the Maid, Signal, Promise and Rx patterns without writing them yourself. Skip it if you ship a single-place game with no build step, because the npm and rojo install path is the documented one and copy-and-paste is described as less ergonomic for larger packages. Before committing, verify that the packages you need are published under @quenty/ on npm and that your rojo project maps node_modules correctly, since the README does not document rollback or a version-pinning policy.

## FAQ

### What does NevermoreEngine require to install?

The README states that Nevermore is designed to use npm or pnpm to manage packages, and that each package is synced into Roblox using rojo. The example install command is npm install @quenty/maid. There is also a copy-and-paste route for individual libraries.

### Can I use NevermoreEngine without rojo?

The README offers copy-and-paste as a second option, noting that many libraries can be pasted into ModuleScripts and run with small refactors. It also warns that the closer a package gets to a full-sized gameplay feature, such as Ik, the less ergonomic that becomes.

### How many packages does NevermoreEngine contain?

The README's generated package list states that there are 278 packages in Nevermore, each with its own docs page, source directory, changelog and npm package under the @quenty/ scope.

### What is NevermoreEngine licensed under?

The repository is MIT licensed and carries a LICENSE.md at the top level. MIT permits use and redistribution, including in closed-source projects, as long as the copyright and permission notice are preserved.

## Sources

- [Official documentation](https://quenty.github.io/NevermoreEngine/)
- [Official README](https://github.com/Quenty/NevermoreEngine#readme)
- [Project repository](https://github.com/Quenty/NevermoreEngine)
- [Release notes](https://github.com/Quenty/NevermoreEngine/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/quenty-nevermoreengine