Skip to main content

Build Nevermore locally

This document is intended to help people submit bug patches, new features, and more to Nevermore. If you would simply like to consume Nevermore and not contribute to it, then this is not the correct article. Please see the installation docs for more.

To provide a bit of background, Nevermore is a mono-repo. This means that it has a few hundred packages in one repository. In general, you should feel free to deploy Nevermore compatible packages to your own repository. This is part of what using npm empowers us to do.

What you need to be comfortable with​

Contributing to Nevermore is a little bit more difficult than consuming it. That being said, it shouldn't be too bad.

  1. Programming in Lua
  2. Git
  3. A bit of command line usage
  4. Use of linter and other tools

Tools and technologies we use​

There are certain open source technologies that Nevermore uses to keep the build pipeline clean and working well. These are as follows.

  1. NPM - Package manager
  2. Git - Source control
  3. Rojo - Build system (syncs into Studio)
  4. Selene - Linter
  5. Aftman - Toolchain manager
  6. Lerna - Helps manage multiple repositories
  7. TestEz - Unit testing system
  8. Hoarcekat - Story book (testing)
info

We use a custom version of Rojo to allow symlinks between components.

Additionally in the cloud we use

  1. Github - To host code
  2. Github Actions - Build pipeline
  3. Auto - Publishing workflow

Versioning in Nevermore​

There are some additional ideas worth reviewing which are relatively unique to this repository.

  1. Conventional Commits - The Conventional Commits specification is a lightweight convention on top of commit messages.
  2. Semantic Versioning - In systems with many dependencies, releasing new package versions can quickly become a nightmare. This versioning provides a simple set of rules and requirements that dictate how version numbers are assigned and incremented.

In general, our CHANGELOG.md are generated by our commits, which also dictates our semantic versioning.

Get the repo setup to develop locally.​

Unlike consuming Nevermore, building and changing Nevermore for general production is a little bit trickier. This is because:

  1. Unlike consuming, we want changes to show up immediately so we can test everything at once.
  2. We need to consider people consuming the code to make versioning good.

However, this build workflow is highly optimized to not cost any development time once setup. So while there is a fixed cost, the total cost is a monorepo that anyone can consume, but that development can also occur on. This was a very important design decision.

In general you want to install the following by hand.

  1. NPM
  2. Git
  3. Aftman

After than you will want to clone Nevermore to a folder.

git clone https://github.com/Quenty/NevermoreEngine.git

Why does building need a custom version of Rojo?​

Nevermore does not need a custom version of Rojo to be consumed, but it does need one to be built. This custom version of Rojo understands symlinks and turn them into ObjectValues. These symlinks link the packages together and means that a change to a transient dependency, or direct dependency will immediately be shown in the upstream package.

As an added bonus, this custom version of Rojo also supports live-syncing mesh parts.