Skip to main content

Feature comparison

The following comparisons are not an exhaustive list of features, and may be inaccurate or out of date, but represent a good starting point for investigation. If something is not correct, please create an issue or submit a patch.

Before diving into our comparisons below, we highly suggest reading monorepo.tools for a deeper insight into monorepos and available tooling. Although moon is not included, it's a great resource for learning about the current state of things and the ecosystem.

Unique features

Although moon is still in its infancy, we provide an array of powerful features that other frontend centric build systems do not, such as...

  • Integrated toolchain - moon manages its own version of programming languages and dependency managers behind the scenes, so that every task is executed with the exact same version, across all machines.
  • Task inheritance - Instead of defining the same tasks (lint, test, etc) over and over again for every project in the monorepo, moon supports a task inheritance model where it only needs to be defined once at the top-level. Projects can then merge with, exclude, or override if need be.
  • Continuous integration - By default, all moon tasks will run in CI, as we want to encourage every facet of a project or repository to be continually tested and verified. This can be turned off on a per-task basis.

Curious to learn more? Check out the "Why use moon?" or "Features" sections for more information, or these wonderful articles provided by the community:

Comparison

Turborepo

At a high-level, Turborepo and moon seem very similar as they both claim to be build systems. They both support incremental builds, content/smart hashing, local and remote caching1, parallel execution, and everything else you'd expect from a build system. But that's where the similarities stop, because in the end, Turborepo is nothing more than a package.json scripts orchestrator with a caching layer. While moon also supports this, it aims to be far more with a heavy focus on the developer experience.

info

Looking to migrate from Turborepo to moon? Use our moon migrate from-turborepo command for a seamless migration!

In the next section, we'll be talking about a few key areas that we deem important to consumers. If you'd prefer a more granular comparison, jump down to the comparison tables.

Configuration

Turborepo only supports the Node.js ecosystem, so implicitly uses a conventions based approach. It provides very little to no configuration for customizing Turborepo to your needs.

moon is language agnostic, with initial support for Node.js and its ecosystem. Because of this, moon provides a ton of configuration for customizing moon to your needs. It prefers a configuration over conventions approach, as every repository is different.

Projects

Turborepo infers projects from package.json workspaces, and does not support non-JavaScript based projects.

moon requires projects to be defined in .moon/workspace.yml, and supports any programming language2.

Tasks

Turborepo requires package.json scripts to be defined for every project. This results in the same scripts being repeated constantly.

moon avoids this overhead by using task inheritance. No more repitition.

CI

Each pipeline in turbo.json must be individually ran as a step in CI. Scripts not configured as pipeline tasks are never ran.

moon runs every task automatically using moon ci, which also supports parallelism/sharding.

Long-term

Turborepo is in the process of being rewritten in Rust, with its codebase being shared and coupled with the new Turbopack library, a Rust based bundler.

Outside of this, there are no publicly available plans for Turborepo's future.

moon plans to be so much more than a build system, with one such facet being a repository management tool. This includes code ownership, dependency management and auditing, repository linting, in-repo secrets, and anything else we deem viable.

We also plan to support additional languages as first-class citizens within our toolchain.

  1. Turborepo remote caching is powered by Vercel. moon provides its own paid service.

  2. moon projects may run commands for any language, but not all languages are supported in the toolchain.

Lerna

Lerna was a fantastic tool that helped the JavaScript ecosystem grow and excelled at package versioning and publishing (and still does), but it offered a very rudimentary build system. While Lerna was able to run scripts in parallel, it wasn't the most efficient, as it did not support caching, hashing, or performant scheduling.

However, the reason Lerna is not compared in-depth, is that Lerna was unowned and unmaintained for quite some time, and has recently fallen under the Nx umbrella. Lerna is basically Nx lite now.

Comparison tables

🟩 Supported🟨 Partially supported🟦 Similarly supported🟥 Not supported

Workspace

moon (9)nx (8)turborepo (6)

Written in

Rust

Node.js

Go (being rewritten in Rust)

Workspace configured with

.moon/workspace.yml

nx.json

turbo.json

Project list configured in

.moon/workspace.yml

workspace.json

package.json workspaces

Repo / folder structure

loose

strict

loose

Ignore file support

🟥

🟩  .nxignore

🟥

Supports dependencies inherited by all tasks

🟩  via implicitDeps

🟥🟥

Supports inputs inherited by all tasks

🟩  via implicitInputs

🟩  via implicitDependencies

🟩  via globalDependencies

Supports tasks inherited by all projects

🟩🟥🟥

Integrates with a version control system

🟩  git  🟨  svn (in dev)

🟩  git

🟩  git

Supports scaffolding / generators

🟩🟩🟥

Toolchain

moon (5)nx (2)turborepo (2)

Supported languages

Bash, Batch, Bun, Deno, Go, Node, JavaScript, TypeScript, PHP, Ruby, Rust, Python

JavaScript, TypeScript

JavaScript, TypeScript

Supported dependency managers

npm, pnpm, yarn

npm, pnpm, yarn

npm, pnpm, yarn

Has a built-in toolchain

🟩🟥🟥

Downloads and installs languages (when applicable)

🟩🟥🟥

Configures explicit language/dependency manager versions

🟩🟥🟥

Projects

moon (6)nx (5)turborepo (2)

Dependencies on other projects

🟩  implicit from package.json or explicit in moon.yml

🟩  implicit from package.json or explicit in project.json

🟩  implicit from package.json

Ownership metadata

🟩🟥🟥

Primary programming language

🟩🟥🟥

Project type (app, lib, etc)

🟩  app, lib, tool

🟩  app, lib

🟥

Project-level file groups

🟩

🟩  via namedInputs

🟥

Project-level tasks

🟩🟩🟩

Tags and scopes

🟥🟩🟥

Tasks

moon (20)nx (18)turborepo (16)

Known as

tasks

targets, executors

tasks

Defines tasks in

moon.yml or package.json scripts

project.json or package.json scripts

package.json scripts

Run a single task with

moon run project:task

nx run project:target

turbo run task --filter=project

Run multiple tasks with

moon run :task or moon run a:task b:task or moon check

nx run-many --target=target

turbo run task or turbo run a b c

Can define tasks globally

🟩  with .moon/tasks.yml

🟥🟥

Merges or overrides global tasks

🟩🟥🟥

Runs a command with args

🟩

🟦  behind an executor abstraction

🟨  within the script

Runs commands from

project or workspace root

workspace root

project root

Supports pipes, redirects, etc

🟨  encapsulated in a file

🟨  within the executor or script

🟨  within the script

Dependencies on other tasks

🟩  via deps

🟩  via dependsOn

🟩  via dependsOn

Can depend on arbitrary or unrelated tasks

🟩

🟥  dependent projects only

🟥  dependent projects only

Runs task dependencies in parallel

🟩🟩🟩

Can run task dependencies in serial

🟩🟥🟥

File groups

🟩

🟦  via namedInputs

🟥

Environment variables

🟩  via env

🟨  within the executor or script

🟨  within the script

Inputs

🟩  files, globs, env vars

🟩  files, globs, env vars, runtime

🟩  files, globs

Outputs

🟩  files

🟩  files, globs

🟩  files

Output logging style

🟩  via outputStyle

🟩  via --output-style

🟩  via outputMode

Custom hash inputs

🟥

🟩  via runtimeCacheInputs

🟩  via globalDependencies

Token substitution

🟩🟥🟥

Configuration presets

🟥

🟩  via configurations

🟥

Configurable options

🟩🟩🟩

Task runner

moon (9)nx (7)turborepo (6)

Known as

action pipeline

task runner

pipeline

Generates a dependency graph

🟩🟩🟩

Runs in topological order

🟩🟩🟩

Automatically retries failed tasks

🟩🟥🟥

Caches task outputs via a unique hash

🟩🟩🟩

Can customize the underlying runner

🟥🟩🟥

Can profile running tasks

🟩  cpu, heap

🟩  cpu

🟩  cpu

Can generate run reports

🟩🟥🟥

Continuous integration (CI) support

🟩🟨🟨

Continuous deployment (CD) support

🟥🟥🟥

Remote / cloud caching and syncing

🟨  in beta (paid)

🟩  with Nx cloud (paid)

🟩  requires a Vercel account (free)

Generator

moon (13)nx (11)turborepo (1)

Known as

generator

generator

n/a

Templates are configured with a schema

🟩  via template.yml

🟩🟥

Template file extensions (optional)

🟩  .tera, .twig

🟥🟥

Template files support frontmatter

🟩🟥🟥

Creates/copies files to destination

🟩🟩🟥

Updates/merges with existing files

🟩  JSON/YAML only

🟩  using JavaScript

🟥

Renders with a template engine

🟩  via Tera

🟩  via EJS

🟥

Variable interpolation in file content

🟩🟩🟥

Variable interpolation in file paths

🟩🟩🟥

Can define variable values via interactive prompts

🟩🟩🟥

Can define variable values via command line args

🟩🟥🟥

Supports dry runs

🟩🟩🟥

Supports render helpers, filters, and built-ins

🟩🟩🟥

Generators can compose other generators

🟥

🟩  using JavaScript

🟥

Other systems

moon (1)nx (0)turborepo (0)

Can send webhooks for critical pipeline events

🟩🟥🟥

JavaScript ecosystem

moon (10)nx (0)turborepo (0)

Will automatically install node modules when lockfile changes

🟩🟥🟥

Can automatically dedupe when lockfile changes

🟩🟥🟥

Can alias package.json names for projects

🟩🟥🟥

Can add engines constraint to root package.json

🟩🟥🟥

Can sync version manager configs (.nvmrc, etc)

🟩🟥🟥

Can sync cross-project dependencies to package.json

🟩🟥🟥

Can sync project references to applicable tsconfig.json

🟩🟥🟥

Can auto-create missing tsconfig.json

🟩🟥🟥

Can sync dependencies as paths to tsconfig.json

🟩🟥🟥

Can route outDir to a shared cached in tsconfig.json

🟩🟥🟥

Docker integration

moon (3)nx (0)turborepo (2)

Efficient scaffolding for Dockerfile layer caching

🟩🟥🟩

Automatic production-only dependency installation

🟩🟥🟥

Environment pruning to reduce image/container sizes

🟩🟥🟩