Rush vs Nx: A Comparison of TypeScript Monorepo Management Tools

With the increasing popularity of the strategy for storing source code, there is a growing number of tools to manage projects in a monorepo, such as , , , or .

This article will focus on comparing Rush and Nx: differences in their goals, capabilities, and their approach to structuring projects.

Goals of Rush and Nx

Both Rush and Nx have similar goals. They both aim to provide a scalable solution to manage large monorepos for web projects.

As stated by :

Rush: a scalable monorepo manager for the web

Rush Stack is a mission to provide reusable tech for running large scale monorepos for the web

As stated by :

Nx is a set of extensible dev tools for monorepos, which helps you develop like Google, Facebook, and Microsoft.

Each tool is oriented towards a different audience, based on the way the tool is published and marketed by its sponsor.

Rush was published by Microsoft after it was internally developed by the OneDrive + SharePoint teams to solve the specific scaling problems encountered by these teams. It is built with first-class support for publishing and managing changelogs for a large number of npm packages. It's published as with a permissive license, but feature development is mainly suited to Microsoft's needs.

Nx is published by , a consulting company whose mission is to help its clients build software better and faster. Nrwl built Nx specifically to help software organizations become more productive and organize their code in a more safe, predictable, and scalable fashion. Nrwl is actively building a community around Nx, including blog posts, training, and consulting to assist organization in adopting Nx.

Comparison of Capabilities

Project Structure

Rush and Nx have different approaches to structuring projects in a monorepo:

• With Rush, each project must contain:
  • package.json file defining the project's dependencies
  • build script
  • test script
• Beyond these constraints, a project's structure is up to the developer; the build and test scripts can be implemented arbitrarily.
• Nx emphasizes an opinionated structure of projects. Tasks such as building and testing are not arbitrarily-defined, but instead are encapsulated in plugins, which are collections of builders and schematics. Each plugin is typically associated with a specific tool, such as for , for , or for .

The result of these differences is that Rush has a higher degree of control over project configuration, but requires writing your own npm scripts to build, lint, and test a project. Whereas an Nx project has opinionated structure, commands, and generators, which can ease the maintenance burden over time, but can require writing your own plugins to control how things are built.

The constraints imposed by Nx afford several advantages:

• Predictable, consistent developer experience between projects.
• Easier to upgrade core dependencies.
• Easy to set up new projects using the same tools and conventions as existing projects.

Dependencies + Linking Projects

An important difference between Rush and Nx is how they handle installation of npm dependencies, and managing inter-dependencies between projects in the monorepo.

Rush

Rush can be configured to use either npm, Yarn, or pnpm to install npm dependencies. Running rush install performs these steps:

1. Install the correct version of the configured package manager, if it's not already installed.
2. Install npm dependencies to common/temp/node_modules.
3. Link dependencies declared by each project to its respective node_modules subdirectory.

For example, we might end up with this directory structure:

my-monorepo/
  rush.json
  common/
    temp/
      node_modules/
        react/
        luxon/
  projects/
    my-app/
      package.json
      index.ts
      node_modules/
        react/ -> ../../../common/temp/node_modules/react
        @my-monorepo/my-datetime-library -> ../../my-datetime-library
    my-datetime-library/
      package.json
      index.ts
      node_modules/
        luxon/ -> ../../../common/temp/node_modules/luxon

Observe that:

• The main dependencies store is tucked away in a subdirectory common/temp/node_modules/.
• Each project declares its own dependencies in a package.json file.
• Rush creates a node_modules directory in each project, containing symbolic links to dependencies which were declared in package.json. Links are created for both npm dependencies and inter-dependencies on other projects in the monorepo.

The result of this structure is that modules in projects are prevented from accidentally importing a package which haven't been declared in package.json. This is because the Node.js package resolution algorithm doesn't find a folder called node_modules as it walks up the directory tree from within projects/.

This idea of ensuring that only declared dependencies are available in node_modules is especially important when publishing npm packages from the monorepo. Without this guarantee, a package which imports an undeclared dependency might "work" in the monorepo, but it will fail when published to the npm registry.

Read more about Rush's unique approach .

Nx

Nx is not opinionated about how npm dependencies are installed. You can directly use any package manager with Nx, whether npm, Yarn, pnpm, or others. Nx does not apply any special directory structure or symbolic links, so there are no built-in safety guaratees like those provided by Rush.

It's possible to use or with Nx, which can provide some additional safety guarantees. However, a node_modules folder still must exist at the root of the monorepo to store Nx's own npm dependencies, so these may still be accidentally imported by individual projects.

There is a feature request for Nx to more directly support per-project npm dependencies:

For projects which depend on other projects in the monorepo, Nx uses TypeScript's config to enable imports across projects:

my-monorepo/
  package.json
  tsconfig.json
  node_modules/
    react/
    luxon/
  projects/
    my-app/
      index.ts
    my-datetime-library/
      index.ts

tsconfig.json

{
  "compilerOptions": {
    "paths": {
      "@my-monorepo/my-app": ["projects/my-app/index.ts"],
      "@my-monorepo/my-datetime-library": ["projects/my-datetime-library/index.ts"]
    }
  }
}

my-app/index.ts

import { DateTime } from '@my-monorepo/my-datetime-library';

// ...

This is a simpler approach, however it relies on every project being written in TypeScript in order to work. It requires additional setup to write a plain JavaScript library, or to use other compile-to-JS languages.

Nx supports some types of build targets which do not use tsc directly, such as . In these cases, is used to augment webpack's module resolution to resolve cross-project dependencies.

Conclusion

Rush and Nx each serve similar purposes, but with slightly different philosophies.

Rush emphasizes safety of npm dependencies and adherence with conventions used in Node.js, in particular package.json, npm scripts, and the Node.js package resolution algorithm to resolve project inter-dependencies.

Nx emphasizes extensibility with plugins and code generation, making it easy to scaffold new projects quickly and ensure that builds and code are consistent across projects. Common large-codebase requirements like linting, formatting, and planning CI builds are built in.

As with anything in technology, there are tradeoffs for each approach. It often comes down to organizational requirements, and ultimately developer preferences.

Personally, I prefer Rush for its safety guarantees, adherence to Node.js conventions, and greater control of builds via npm scripts.

Here's a list of some overlapping technologies to explore further: