Forem: Juri Strumpflohner

Versioning and Releasing Packages in a Monorepo

Juri Strumpflohner — Fri, 09 Feb 2024 18:49:59 +0000

When it comes to publishing NPM packages, there are a bunch of libraries and utilities out there that help with the process. Many of them are tricky when it comes to properly configuring them in a monorepo.

Nx already has all that knowledge. About project dependencies and relationships and leverages that information already for optimizing your task runs.

Here's the structure of our current example workspace we're going to refer to in this article:

As you can see @tuskdesign/forms relies on @tuskdesign/buttons and as such has to consider that when running versioning and publishing.

Note, it is worth mentioning that the Nx community has also stepped up in the past and created jscutlery/semver, a package that adds semantic versioning and publishing to your Nx workspace. Make sure to check that out as well

Prefer a video?

Table of Contents

Adding Nx
- Installing the JavaScript/TypeScript versioning Package
Running Nx Release
Excluding Packages
Running the Versioning and Changelog Generation
Versioning using Conventional Commits
Generating a GitHub Release
Programmatic Mode
Wrapping Up
Learn more

Adding Nx

You can add Nx to your existing monorepo workspace using the following command:

pnpm dlx nx@latest init

(use npx nx@latest init in a NPM workspace)

This brings up a couple of questions. It'll also ask about installing Project Crystal plugins.

It gives you some additional benefits (you can read more here), but you don't have to as it is not required for Nx Release.

Installing the JavaScript/TypeScript versioning Package

Nx Release is made to handle the versioning and publishing of any package. For now, the Nx team provides the JS/TS package publishing approach, which comes with the @nx/js. You could provide your own implementation, like for Cargo, NuGet etc..

pnpm add @nx/js -w

(We use the -w flag to install it at the monorepo root level)

Running Nx Release

Once you're set-up, you can already go ahead and run the following command:

pnpm nx release --dry-run

This command will do the versioning, changelog generation, and publishing steps together. Note the --dry-run, simply simulating a run.

You'll get asked whether you want to release a major, pre-major, minor... release or choose an exact version.

Once this runs through, you might hit the following error:

Since Nx Release has never been run on this repository, it cannot figure out the historical information, for instance, to generate the changelog starting from previous git tags. Re-run the command with --first-release

pnpm nx release --dry-run --first-release

If you inspect the console output, you can see that:

it would increment the version in the package.json
update the pnpm (or npm) lockfile
stage the changes with git
creates a CHANGELOG.md file
git commits everything
git tags the commit using the version

The dry-run mode also nicely previews all package.json changes in a git diff style:

Note, if you want to get even more insights into what is happening when running the command, you can use the --verbose, which will also print the actual git commands.

Excluding Packages

If you look closely at the dry-run logs, you may notice that Nx Release bumped the version on all of our packages:

@tuskdesign/forms
@tuskdesign/buttons
@tuskdesign/demo

While we want to have it bumped on the forms and buttons packages, the demo is just for us to test things in the workspace. In this particular workspace, Nx Release doesn't have a way to distinguish what is an app and what is a library/package. Note, if you're in an Nx-generated workspace that uses Nx Plugins, you'd potentially have that classification in the project.json files.

In our particular scenario, let's exclude @tuskdesign/demo as follows:

// nx.json
{
    ...
    "release": {
        "projects": ["*", "!@tuskdesign/demo"]
    }
}

You can also explicitly list the packages to be released individually. Or, as shown above, include all (*) and exclude the private package.

If you re-run the nx release command, you'll see that @tuskdesign/demo will be ignored now.

Running the Versioning and Changelog Generation

Once you have configured the excluded packages, feel free to go ahead and run the command without --dry-run:

pnpm nx release --first-release

You can skip the release part when prompted for now. Check how the workspace got updated, incrementing the package.json version property and updating the version on the package dependency definition, i.e. the @tuskdesign/buttons version got updated in the @tuskdesign/forms package.json.

Versioning using Conventional Commits

Instead of manually confirming the next version each time, we can use a versioning strategy: Conventional Commits is a commonly adopted approach for publishing packages.

To configure conventional commits with Nx Release, go to the nx.json and adjust it as follows:

// nx.json
{
    ...
    "release": {
        "projects": ["*", "!@tuskdesign/demo"],
        "version": {
            "conventionalCommits": true
        }
    }
}

If you now run..

pnpm nx release --dry-run

..you'll notice that it doesn't pick up any changes because it leverages conventional commit, and we haven't changed anything yet.

Let's go ahead and change something in our @tuskdesign/buttons package and then commit it as follows:

git commit -am 'feat(buttons): add new background shadow'

Now re-run the nx release command (don't forget the --dry-run). You'll see how it chooses v1.2.0 as our new version (we had v1.1.0 previously), given we added a new feature (denoted by the feat(...) conventional commit).

It also generates a nice CHANGELOG.md for us:

## 1.2.0 (2024-02-09)

### 🚀 Features

- **buttons:** add new background shadow

### ❤️  Thank You

- Juri

## 1.1.0 (2024-02-09)

This was a version bump only, there were no code changes.

Generating a GitHub Release

Instead of just generating a CHANGELOG.md entry in our repository you can also opt-in for creating a Github release (here's the example of the Nx repository).

Use the createRelease property and set it to github.

// nx.json
{
    ...
    "release": {
        "projects": ["*", "!@tuskdesign/demo"],
        "version": {
            "conventionalCommits": true
        },
        "changelog": {
            "workspaceChangelog": {
                "createRelease": "github"
            }
        }
    }
}

To see the working, you need to make sure to

push the repo to GitHub
make some change so you can run the nx release command again and get a changelog generated
now also get a GH release created

Note, you can still use --dry-run and it'd show you the URL where the GitHub release would be created. You can also use the --skip-publish to skip the NPM publishing.

Programmatic Mode

As you've seen, you can use nx release right away with minimal configuration. However, we are very well aware that many real-world scenarios are more complex, you want/need more control over when the version is happening, when the changelog generation kicks in and so on. This is why we also introduced a programmatic API.

This approach gives you full control to embed Nx Release into your current release flow. There's a nice example script on our docs that can help you get started.

Create a file - I call it release.ts - at the root of my workspace. Nx Release obviously doesn't care how the file is called or where you place it. You can also go with plain JS.

Here's the example script from our docs:

import { releaseChangelog, releasePublish, releaseVersion } from 'nx/release';
import * as yargs from 'yargs';

(async () => {
  const options = await yargs
    .version(false) // don't use the default meaning of version in yargs
    .option('version', {
      description:
        'Explicit version specifier to use, if overriding conventional commits',
      type: 'string',
    })
    .option('dryRun', {
      alias: 'd',
      description:
        'Whether or not to perform a dry-run of the release process, defaults to true',
      type: 'boolean',
      default: true,
    })
    .option('verbose', {
      description:
        'Whether or not to enable verbose logging, defaults to false',
      type: 'boolean',
      default: false,
    })
    .parseAsync();

  const { workspaceVersion, projectsVersionData } = await releaseVersion({
    specifier: options.version,
    dryRun: options.dryRun,
    verbose: options.verbose,
  });

  await releaseChangelog({
    versionData: projectsVersionData,
    version: workspaceVersion,
    dryRun: options.dryRun,
    verbose: options.verbose,
  });

  // The returned number value from releasePublish will be zero if all projects are published successfully, non-zero if not
  const publishStatus = await releasePublish({
    dryRun: options.dryRun,
    verbose: options.verbose,
  });
  process.exit(publishStatus);
})();

You can invoke it with tsx or tsnode.

pnpm dlx tsx release.ts

Notice by default in the script we have dry-run enabled as a more cautious approach to not accidentally publish something as we keep editing and trying our programmatic setup.

From here on you have full control and can pretty much do whatever works best for your workspace setup. Common examples include to

move files to a common root-level dist/ folder and version and release them from there. This is pretty common to avoid messing with your src files and swapping versions there, allowing you to always depend on the latest local packages for instance.
setup fully automated releases on CI, including enabling provenance support. Our docs have more details on how to set that up or check out the linked talk above which goes through those steps
...

Wrapping Up

With this release of Nx Release it is fully ready to be used. Make sure to check out our docs on Managing Releases as well as our release-related recipes.

Here are some example repositories already leveraging Nx release

our own Nx Repo
RxJS repo
typescript-eslint
Watch the live stream with Kent and James as they enable Nx Release on the EpicWeb workshop app repository.

Learn more

What if Nx Plugins Were More Like VSCode Extensions

Juri Strumpflohner — Mon, 05 Feb 2024 15:32:55 +0000

Enhance, but don't interfere! That's the ideal! And this is how extensions work in VSCode (or Webstorm). You can use VSCode without any extension and get some basic functionality, or you can add an extension on top to enhance your experience and, ideally, increase your productivity.

Table of Contents

Adding Nx to an Existing Monorepo
Project Crystal
Project Crystal Plugins in an Nx Monorepo
- Inferred Targets
- Visualizing Inferred Targets
More Transparency and a Single Source of Truth
Enhancing existing Monorepos with Nx Plugins
This is just the Beginning
Learn more

Prefer a video? I've got you covered!

Also, make sure to check out Launch Nx Conf on Thursday, Feb 08th, where there are going to be more in-depth talks about Project Crystal as well as other exciting features around Nx and Nx Cloud.

Take, for instance, the Playwright plugin. You install it, and it'll automatically detect the Playwright config file and enhance your workspace by providing quick run buttons alongside your tests or even a dedicated Test Explorer window.

Adding Nx to an Existing Monorepo

You can add Nx to an existing npm/yarn/pnpm monorepo quite straightforwardly. You run

npx nx@latest init

You'll get an nx package installed and an nx.json allowing you to define task dependencies and caching. With that, you're now able to run commands like nx build <your project> or nx run-many -t build test to run all build and test targets in your workspace in parallel. Nx will read and use your existing package.json scripts. I've written an in-depth blog post about adopting Nx in such a scenario.

This is the most lightweight setup you can get while still getting some improvements via Nx regarding faster task running and more intelligent parallelization. But, you need to deal with the remaining of the monorepo setup.

Project Crystal

Nx always had more to offer, though, which it mainly did through its plugins. They're optional but usually something you'd get set up when creating a new workspace with create-nx-workspace. Nx Plugins are extremely powerful, helping you not only create and configure new monorepos, but also taking away the burden of integrating various tooling as well as providing features for enforcing consistency and helping with maintainability. These aspects are fundamental in enterprise settings, where Nx Plugins have proven to help teams successfully manage their monorepos.

However, this is a balancing act. More abstraction and automation means more support but also potentially a learning curve and giving up some low-level control. It also requires a slightly more significant upfront investment when migrating to an Nx plugin-powered monorepo.

These are things we wanted to solve, and Project Crystal is the first step in that direction.

Some of the main objectives of Project Crystal are to

make Nx plugins more transparent
reduce the amount of configuration required
allow Nx plugins to be drop-in enhancements in existing npm/yarn/pnpm monorepos
allow for a migration to an Nx plugin-powered monorepo

Project Crystal Plugins in an Nx Monorepo

Note, starting with Nx 18, Project Crystal will be active for new workspaces only. You can opt-in to use them though.

When you create a new Nx workspace using

npx create-nx-workspace myorg

..and you choose an "integrated monorepo" you'll get the usual setup powered by Nx Plugins and all the features and benefits that come with them. Where you'll see Project Crystal in action is when you open a project.json file, which will most likely look like the following:

{
  "name": "reactapp",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "apps/reactapp/src",
  "projectType": "application",
  "targets": {},
  "tags": []
}

Inferred Targets

Starting with Nx 18 and Project Crystal, we don't generate any targets anymore, but the corresponding Nx plugin instead infers them. If we open the nx.json, you'll see a new property, plugins:

{
  ...
  "plugins": [
    {
      "plugin": "@nx/vite/plugin",
      "options": {
        "buildTargetName": "build",
        "previewTargetName": "preview",
        "testTargetName": "test",
        "serveTargetName": "serve",
        "serveStaticTargetName": "serve-static"
      }
    },
    {
      "plugin": "@nx/eslint/plugin",
      "options": {
        "targetName": "lint"
      }
    },
    {
      "plugin": "@nx/cypress/plugin",
      "options": {
        "targetName": "e2e",
        "componentTestingTargetName": "component-test"
      }
    },
    ...
  ],
  ...
}

Notice the options property defining the names of the potentially inferred targets for each plugin. These targets will be generated dynamically s.t. you can still run nx build reactapp even though there's no build target explicitly defined in the project.json of your apps/reactapp project.

This dramatically reduces the redundancy of repeatedly configuring the same tasks (e.g., Jest or Vitest tasks) throughout your various projects. Instead, with this new approach, you get the defaults, and if you need to override them, you can still define them in your project.json file as you were accustomed to before.

Visualizing Inferred Targets

Dynamically inferred targets help with the maintainability aspect and reduce the configuration overhead overall. But how do we know which targets are available for a given project?

Option 1 is to run the following command:

npx nx show project reactapp --web

This opens your browser with the following view:

Option 2 is Nx Console, which is an extension for VSCode as well as IntelliJ (Webstorm etc..). It comes with a project detail view, as shown below, as well as "Codelens" features that enhance your configuration files with context-based information and features.

More Transparency and a Single Source of Truth

We also wanted the new approach to plugins to be closer to the actual CLI tool of the framework you're using. If you have a React + Vite project, nx build should be as close as possible to the vite build while still providing the enhancements around caching configuration.

And this is what happens. Behind the scenes, the plugin configures caching with inputs and outputs and task dependencies (e.g., ^build) but then mostly pipes through to the Vite CLI (in this particular case), Remix, Next CLI, etc.

Furthermore, the framework-specific config - in the example of Vite, the vite.config.ts - is the single source of truth from which Nx infers configuration such as caching. If you change your Vite build.outDir, Nx automatically picks that up and uses that as the caching output directory.

Enhancing existing Monorepos with Nx Plugins

As mentioned earlier, one of the key goals of Project Crystal was to improve the adoption story of Nx Plugins, which implicitly also helps with migrating to Nx plugin-based monorepos. By reducing the config footprint of an Nx plugin and by automatically inferring tasks from existing framework configs, we've moved in a direction where plugins have become much more of a drop-in approach.

Starting with Nx 18, if you now run nx init on an existing npm/yarn/pnpm workspace, you'll also get asked about installing plugins based on the setup you have in your monorepo.

You can also obviously start with no plugin at all and incrementally add them as you go and feel comfortable using the new add command:

npx nx add @nx/vite

This is just the Beginning

We just released Project Crystal, so this is just the beginning of it. While we've moved many of our existing Nx plugins to adopt the new approach, there are still some more refinements to be done in the coming weeks. But we are excited about the possibilities Project Crystal enables for Nx and its adoption story going forward, making Nx plugins more approachable, transparent, and lightweight.

Learn more

Also, if you liked this, click the ❤️ and make sure to follow Juri and Nx on Twitter for more!

#nx Follow

Nx - Highlights of 2023

Juri Strumpflohner — Thu, 28 Dec 2023 17:01:08 +0000

Co-authored by Victor Savkin and Zack DeRose

It is that time again: getting flooded by Year of Review blog posts. We did it last year, and we should do it again! So here we go, and be warned, 2023 was massive!!

Table of Contents

Top 10 Nx Highlights of 2023
- TypeScript for Extensibility - Rust for Speed
- First Class Vite Support
- Nx't Level Publishing
- Improved Node Backend Development: Fastify and Docker
- Nx Console support for IntelliJ
- Playwright for e2e testing
- TypeScript Packaging and Batch Mode
- Nx team maintained Vue plugin
- Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support
- Module Federation
Many OSS repos adopt Nx
Nx Community
New Content & Improved Docs
New Tagline: Smart Monorepos - Fast CI
Nx Conf
Looking ahead - 2024

Top 10 Nx Highlights of 2023

We shipped a ton of features in 2023. You can find all our release blog posts and release-related info here: https://nx.dev/changelog or check out our Dev.to collection.

I picked out 10 highlights for you.

TypeScript for Extensibility - Rust for Speed

At Nx, we’ve heavily embraced Typescript from the beginning and we’ve been very happy with that decision. Nx also stands as the fastest JS monorepo tool available, demonstrating that adopting TypeScript does not necessarily compromise speed. However, we don't stop here. To push the boundaries further, we started to rewrite the most performance critical and computationally intensive parts of the Nx core in Rust.

Our initial focus was on rewriting the task hasher, previously reliant on Git with a Node fallback. This shift to Rust brings a noticeable performance boost, particularly in large repositories, while maintaining the same user experience.

Following this, we revamped the TypeScript dependency resolution, observing an almost 5x speed increase with our Rust-based approach over the traditional TSC method.

// Detect dark theme var iframe = document.getElementById('tweet-1726977598218199302-389'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1726977598218199302&theme=dark" }

Such enhancements are especially crucial for the efficient project graph calculation. As we continue to evolve Nx, Rust will play a key role in optimizing performance-critical components. This strategic use of Rust complements our ongoing commitment to TypeScript, ensuring Nx remains as extensible and powerful as ever.

First Class Vite Support

Vite is rapidly transforming the landscape of frontend development! Its refreshing simplicity and innovative approach have made a significant mark in the developer community. What truly stands out is not just Vite's technological aspect but also how its team approaches and grows the community around the tool. Vite stands for speed and community, values that deeply resonate with us here at Nx.

Our collaboration with our friends in the Vite core team has been incredibly fruitful. Vite is not just compatible but a first-class option with many of Nx's frontend plugins. When you create a new Nx powered React workspace, Vite (and Vitest) are your default options.

We also built some powerful code generators that not only facilitate a seamless transition from Webpack to Vite but also pave the way for an effortless migration from a CRA-based setup to a modern Nx + Vite based workspace. To see this process in action, check out this short video.

AnalogJS - the fullstack Angular meta-framework which also heavily builds on top of Vite - is using the @nx/vite plugin to power its Angular and Nx based workspaces.

We also spoke at both editions of ViteConf. If you're curious check out Juri's talk about High Speed Monorepos and this year's talk by Katerina on Streamlining your Vite dev flow with Nx.

Nx't Level Publishing

Open source libraries and frameworks share a common necessity: the need to develop multiple packages cohesively and efficiently while managing their versioning and publishing to NPM. Nx has emerged as a go-to choice for handling such open source monorepos (as we'll explore further in the next section of this blog post). Until recently, one area Nx did not address directly was versioning and release management. Traditionally, this gap has been filled with tools like release-it, changesets, or custom Node scripts, similar to our approach in the Nx repository.

However, many in our community have expressed a desire for a more native, integrated experience for versioning and publishing, akin to what Lerna offers. In response to this feedback, we've introduced the "nx release" command, a solution designed to seamlessly integrate these processes into the Nx workflow.

James Henry gave a deep dive talk of an early version of it at this year's Nx Conf:

Since its introduction, the "nx release" feature has significantly evolved, leveraging the power of the Nx project graph to effectively understand inter-package dependencies. This understanding is crucial as it allows for:

Versioning packages offering support for both independent and "locked" versioning strategies.
Releasing packages in the correct sequence, ensuring dependency integrity.

Beyond these core functionalities, the feature also includes a robust grouping mechanism, supports semantic versioning, and changelog generation. Additionally, it provides various release targets, such as GitHub and NPM. For those having special requirements, the programmatic API offers maximum flexibility.

Improved Node Backend Development: Fastify and Docker

Colocating frontend and backend code within the same monorepo has become a popular practice. It greatly facilitates cross-functional teams and helps ensure end-to-end type safety. Although you can use other backend stacks with Nx, Node is a popular backend companion for JS based frontends. We had support for Express and NestJS backend for a while.

This year we added another popular option: Fastify. Known for its high performance, excellent developer experience, and useful built-in features like logging, Fastify aligns well with Nx's modular software design principles. Its extensible and modular nature complements the Nx philosophy perfectly.

In tandem with Fastify, we've also introduced Docker support for Node deployments.

Nx Console support for IntelliJ

Nx Console has evolved from an experimental side project of the Nx team to a core part for enhancing your productivity when working in a monorepo. Being integrated right into your editor it can provide useful information and functionality right where you need it, whether that's running commands, providing contextual autocomplete support or the ability to explore the project and task graph.

This year we not only added a lot of new features to Nx Console, but also rewrote its internals which paved the way to expand Nx Console to other code editors: JetBrains IDEs.

Yes, this means you can now use the latest Nx Console directly in your Webstorm IDE. Read the announcement blog post for all the details or go ahead and install Nx Console if you didn't already:

Playwright for e2e testing

2023 saw Nx introduce official support for Playwright - a popular testing tool from Microsoft.

In this video, Zack DeRose explains how you can use Playwright to test both a single web application, as well as stand up a full-stack system - including a backend server and a frontend application - and write and run tests using Playwright:

The repo for this video can also be found here.

Generally, Playwright fits in the Nx ecosystem as a tool that developers can use as a possible alternative to Cypress - a popular e2e testing tool that Nx has supported for a long time now! In addition to publishing an official @nx/playwright package, running the command to create a new workspace will now prompt for Playwright as an option for React, Angular, and Vue stacks:

% npx create-nx-workspace@latest

 >  NX   Let's create a new workspace [https://nx.dev/getting-started/intro]

✔ Which stack do you want to use? · react
✔ What framework would you like to use? · none
✔ Integrated monorepo, or standalone project? · integrated
✔ Which bundler would you like to use? · vite
? Test runner to use for end to end (E2E) tests … 
Cypress [ https://www.cypress.io/ ]
Playwright [ https://playwright.dev/ ]
None

Similar options will appear when using Nx generators to create new frontend web applications for an existing workspace.

TypeScript Packaging and Batch Mode

TypeScript has won. It has become the prevalent way of writing modern JavaScript applications. And we kept improving our support to streamline development and polish some of the rough edges. Like properly defining secondary package entry points. You can define them in the package.json, but both creating these entries but especially maintaining them can be quite painful.

{  
  "exports": {  
    "./package.json": "./package.json",  
    ".": "./src/index.js",  
    "./foo": "./src/foo.js",  
    "./bar": "./src/bar.js"  
  }  
}

So in v16.8 we added the ability to automatically have these generated for you by defining the additionalEntryPoints and generateExportsField when using the @nx/js plugin.

// packages/my-awesome-lib/project.json
{
  "name": "my-awesome-lib",
  "targets": {
    "build": {
      "executor": "@nx/js:tsc",
      ...
      "options": {
        "main": "packages/my-awesome-lib/src/index.ts",
        ...
        "additionalEntryPoints": ["packages/my-awesome-lib/src/foo.ts"],
        "generateExportsField": true
      },
    },
    ...
  }
}

Similarly we improved the ability to package your TS libraries in multiple formats (ESM and CJS). When using the @nx/rollup plugin, all you need to do is define the format property in your config:

// packages/my-awesome-lib/project.json
{
  "name": "my-awesome-lib",
  "targets": {
    "build": {
      "executor": "@nx/rollup:rollup",
      ...
      "options": {
        "main": "packages/my-awesome-lib/src/index.ts",
        ...
        "format": ["esm", "cjs"],
        "additionalEntryPoints": ["packages/my-awesome-lib/src/foo.ts"],
        "generateExportsField": true
      },
    },
    ...
  }
}

Here's a video that walks you through:

But we wouldn't be talking about Nx if we didn't also look into speeding up TypeScript compilation for large monorepos. We called it "batch mode". When enabling batch mode, Nx leverages the underlying project graph to generate TypeScript project references behind the scenes for you, to fully leverage TS incremental building. The results are amazing. According to our benchmarks, batch mode has the potential to speed up Typescript compilation by up to 5x for large monorepos.

Nx team maintained Vue plugin

After adding Vite as a first-class citizen of Nx workspaces, it was only a matter of time before Nx started offering official support to Vue!

Vue is currently the second most popular frontend framework (according to npm downloads) behind React and slightly ahead of Angular.

The first place your might notice Nx's support for Vue is in the create-nx-workspace script:

The option above will create a new Nx workspace with a fresh new Vue application, all set up and ready to develop! To add new Vue projects to an existing Nx workspace, you can also add our @nx/vue package as a dev dependency to your workspace:

% npm add -D @nx/vue

And you'll then have access to Nx generators so you can create Vue applications, libraries, and more in your workspace!

Checkout out our Vue standalone tutorial for more, as well as our Vue API docs and stay tuned as Nx prepares to offer more Vue support (including support for Nuxt, a full-stack framework built around Vue) in the near future!

Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support

Extensibility is at the heart of Nx, serving as the cornerstone of its flexibility. It enables the Nx core team to continually expand capabilities through dedicated plugins and simultaneously paves the way for a rich array of community plugin contributions. Furthermore, Nx's adaptable nature is particularly beneficial for large enterprises, as it allows for the creation of custom automation solutions, specifically tailored to meet their unique organizational needs.

In 2023 we kept improving Nx's extensibility, unifying the Nx plugin development model and how you develop workspace-local automations. You can now scaffold a new plugin into your Nx workspace and run it right away which makes it an interesting approach to automate your monorepo.

When creating automations with Nx you cannot just enhance existing Nx workspaces, but also develop a complete Nx preset that controls the entire appearance of an Nx workspace. Basically your own, personalized create-nx-workspace. You can publish and then use your preset like

npx create-nx-workspace myrepo --preset=@yourpkg/nx-preset

We wanted to make building on top of Nx even more pleasant, allowing you to introduce your own branding by building your own CLI with Nx. The Qwik-Nx repo is a great example where they allow you to scaffold a new Nx workspace for Qwik development with:

npx create-qwik-nx

And finally, we extracted our own Verdaccio setup that we've been using to run our e2e tests in the Nx repo s.t. you can use it for your own plugin development as well. Check out this video for a walkthrough on how this works.

Module Federation

Module Federation is an exciting new feature of Webpack 5 that has gained a significant amount of interest in 2023.

Simply put, Module Federation allows a Javascript application running in a browser to dynamically load code from another application hosted at a different url, while facilitating optimal loading of shared dependencies.

This is an exciting development as it allows a paradigm shift in how you can architect, build, and deploy Javascript applications! And this is especially exciting for monorepo fans, as Nx has best-in-class support for module federation that makes a Module Federation approach easy to adopt and simple to understand!

Currently, our @nx/angular and @nx/react plugins both have generators to create a "host" application that will load and consume federated modules from "remote" applications, which you can also generate using Nx. Then, by running a simple command with Nx, you can serve all applications required for your host application with the command:

% nx serve host-application --devRemotes=remote-application

Where in the example above your host application is named host-application and a remote application that you want live updates on as you're developing is named remote-application.

Throughout 2023, we've continued to increase Nx's support and general dev experience around Module Federation, including adding a generator to federate an existing module, improving the local developer experience by improving local webserver performance, and introducing the concept of Dynamic Module Federation which will allow you to dynamically specify the location of your remote applications via a module-federation.manifest.json file!

At Nx, we're excited about the Module Federation support we offer for our users, and think that it has many interesting applications when paired with Nx's CI capabilities - in particular allowing for much shorter build times, especially for larger Angular applications.

Many OSS repos adopt Nx

By simply installing the nx package (or initializing with nx init in any project or monorepo), you already get some cool features:

Advanced task scheduling, including task pipelines and parallel execution.
Efficient caching mechanisms.

If you want to learn more about such setup, make sure to check out our blog post on how to adopt Nx on a npm/yarn/pnpm workspace or the corresponding video version.

Numerous open-source packages are adopting Nx in this lightweight manner. It enables them to maintain their existing setup while notably enhancing the local developer experience (DX) in task execution and accelerating processes on CI.

I picked out some of the more well-known OSS repos that started using Nx this year:

Tanstack - Tanstack has evolved to an entire ecosystem consisting of the famous Tanstack (or React) Query, Tanstack Table, now also Tanstack Router and Tanstack Form. It started with Tanstack Query, which adopted Nx and Nx Cloud. Zack talked about this collab with Dominik, and we also had Dominik on our Nx live stream. Now, all the above-mentioned Tanstack libs have adopted Nx, and there's more coming.

Sentry JavaScript - Sentry, renowned for its comprehensive solutions in frontend monitoring and error logging, recently adopted Nx for their official JavaScript SDK. This move integrates Nx's capabilities into their monorepo, containing packages for popular frontend and Node.js backend integrations. They also published a blog post on the benefits they've seen following the adoption of Nx in their monorepo (hint: reducing CI times by 35%).

RxJS - The library for reactive programming in JavaScript. It is widely popular, with over 40 million downloads/week on NPM. RxJS only recently adopted Nx, not only leveraging speed improvements via caching, but also leveraging Nx's latest nx release feature to publish packages to NPM.

AnalogJS - Analog is a full-stack Angular meta-framework that brings exciting features to Angular, like faster Vite setup, support for both server-side and static rendering, and easy file-based routing. Analog uses an Nx monorepo for its development and also uses Nx's DevKit to create tools that work great in both Nx and Angular CLI workspaces.

Qwikifier - The Qwikifiers community built a dedicated Nx plugin to combine the power of Qwik and Nx. Their repo is a great example of building Nx plugins and using Nx to build your own CLI.

Builder.io Mitosis - BuilderIO has an ambitious compiler project that allows you to write a component once and then compile it to different frameworks. Check out their mind-blowing demo page. They adopted Nx to coordinate task dependencies and speed up their CI builds.

Ghost - Are you into blogging? You might want to look at Ghost. They were using Lerna in the past and migrated to a fully Nx-powered workspace.

And these are just some of them that joined in 2023. If I missed some cool ones (which I'm pretty sure), ping me and let me know!

Nx Community

Nx has a huge community! We're lucky to have so many folks rooting for Nx, whether on socials, talking at conferences, writing blog posts or creating awesome plugins.

Nx Champions - This year we finally launched which we had planned for a long time. Our Nx Champions program.

These are individuals who stood out for their contributions and passion for helping within the NX community. We wanted to build a more connected relationship with these folks and have a channel to gather more direct feedback as well. Get to know all of our champions.

New Discord server - Around September we also switched over from our previous Nx Slack community to a brand new Nx community Discord, which is already counting 2,600+ members. Discord is popular among OSS communities and allows new folks to join easily. In addition, we now have a dedicated forum integrated, as well as a couple of useful automations. More coming next year!

Make sure you join!

New Content & Improved Docs

Our Youtube channel has grown to over 15k subscribers and peaks of 65k views a month. We love to provide educational video content, so make sure to subscribe! It got a little silent towards the end of the year, but we've been working a lot behind the scenes. So stay tuned!

We also poured a lot of effort into the docs. We restructured them following the Diataxis to make pages less overwhelming and more structured based on their type of content. You'll find

Concept docs - which explain some of the inner workings and mental model behind certain features. Like how caching works.
Recipes - which are solution oriented. You already know how to cook, we provide the exact recipe for it.
Tutorials - for when you just want to sit down and follow along, step by step to learn how to use Nx in a certain context.
Reference and API docs - pure, raw and to the point.

We created a brand new "Why Nx" page explaining the overall architecture of Nx including a brand new video giving you a holistic overview of what Nx is capable of.

We also refreshed our entry pages, including dedicated examples of using Nx with popular stacks:

You can also browse them in the nx-recipes GitHub repository.

// Detect dark theme var iframe = document.getElementById('tweet-1736023402933318011-479'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1736023402933318011&theme=dark" }

And obviously, we jumped on the AI train as well. A couple of months ago, we added the Nx Assistant. A ChatGPT-powered interface trained on our docs. Katerina wrote about it on our blog. The AI chat allows to interactively ask questions about Nx and will give you relevant answers from our docs (including linking to the sources).

New Tagline: Smart Monorepos - Fast CI

Nx stands out for its flexibility, accommodating for both monorepo and non-monorepo project structures. This approach allows users to begin with simpler project configurations, leveraging the benefits of Nx's robust tooling, and later, when the need arises, seamlessly migrate to a monorepo.

However, Nx's true strength becomes most apparent at scale, typically within a monorepo setup. We wanted to capture it in our new tagline: Smart Monorepos - Fast CI.

// Detect dark theme var iframe = document.getElementById('tweet-1734558895547568634-36'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1734558895547568634&theme=dark" }

Setting up an efficient and maintainable CI process for monorepos can be a complex task, so we've also made it a focal point in our new tagline. Nx expands beyond the local development experience, helping you set up an efficient CI process. We're publicly launching Nx Agents to add seamless distribution to your CI pipeline, and more are coming in 2024.

As part of that, we also restructured our docs to have a section entirely dedicated to CI: https://nx.dev/ci.

Nx Conf

We did it again! The second in-person Nx Conf was a resounding success, this time set against the vibrant backdrop of the Big Apple.

There's not much to say. Check out some of the amazing talks. I did a Nx Conf 2023 recap blog post.

Looking ahead - 2024

Although we shipped a lot in 2023, in many ways 2023 was about preparing for what we are planning to ship in Q1 2024.

Solving CI

Legacy CI systems are a performance and productivity bottleneck if you use a powerful build system like Nx. Big tech companies know it and that's why their CI systems look nothing like Circle or Jenkins. We've been narrowing this gap over the years, but only this year we finally built a turn-key CI solution that gives you great performance, scalability, dev ergonomics, and must better cost efficiency.

It has three components:

Nx Cache: Built-in local and remote caching to speed up your tasks and save you time and money. Available now.
Nx Agents: A single line to enable distributed computation, across multiple machines. Fully managed agents, dynamically allocated based on PR size. Available early Feb.
Nx Workflows: Next generation, fully managed CI solution with distribution at its core, designed from the ground up for monorepos. Available late March.

Optimal parallelization and distribution, using the right numbers of agents for each PR, rerunning flaky tests, splitting and distributing large test suites, handling dependencies between tasks across machines -- are just some of the things we can now handle automatically for you. Turn it on and enjoy the speed.

Solving the Simplicity vs Power Dilemma

Balancing simplicity and power is the trickiest part of the dev tools design. Simple onboarding for small projects or handling the biggest enterprise systems? Two years ago we solved this problem by giving you a choice between the package-based setup (a more powerful version of something like Turborepo) and the integrated setup (we manage your whole monorepo in the most optimal way). But now we believe we have a much better solution, where you have both, the simplicity of the former with the power of the latter. So you no longer have to choose.

We took inspiration from VSCode. Any project you open in VSCode will work right away: it is simple, and you don't need to configure anything. If you install say a Playwright plugin, VSCode becomes aware of Playwright. It can run and debug your tests right in the editor. That's what the Nx experience is going to be like. Any project, any tool will work right away. But if you - for instance - install the Playwright plugin, Nx will become aware of Playwright and will be able to cache test runs in the most optimal way and distribute your e2e tests across machines for best efficiency. All the benefits with none of the costs.

The whole team is excited about it as the new experience feels much more elegant.

As always, we try very hard not to break folks, so all your current workspaces will keep working, and we will provide automatic migrations to bring you to this new way of using Nx.

Exciting stuff! So keep an eye on our channels, and subscribe if you haven't already ;)

Nx Conf 2023 - Recap

Juri Strumpflohner — Fri, 13 Oct 2023 18:22:55 +0000

The 3rd edition of Nx Conf, this year live from New York City. If you missed the talks, no worries, we've got you covered. This article does a brief recap of all the presentations and has links to the individual recordings and slides.

1. Keynote
2. Nx Cloud Workflows: Next-Gen CI with First-Class Monorepo Support
3. United by Nxcellent DX
4. Redefining Projects with Nx: A Dive into the New Inference API
5. Package-based to Integrated: One Small Step or One Giant Leap?
6. Nx't Level Publishing
7. Lightning Talk: What if your stories were - already - your e2e tests?
8. Lightning Talk: Nx Cloud Demo
9. From DIY to DTE - An Enterprise Experience
10. Vanquishing Deployment Dragons with Nx wizardry
11. Optimizing your OSS infrastructure with Nx Plugins
12. Level Up Your Productivity with Nx Console
13. That's a wrap

Keynote

Speaker: Juri Strumpflohner & Victor Savkin
Slides • Watch on Youtube

Juri Strumpflohner (me 😅) opens the keynote. He focuses on the Nx ecosystem, how it is much more than just monorepos by helping you integrate your framework of choice (whether that is Angular, React, or Vue) with tooling such as ESLint, Playwright, Cypress, Webpack, ESBuild, Vite etc.

Such integration capabilities really help push the developer productivity, whether that's in single-project workspaces or monorepos.
Juri also dives deeper into efforts from the team to provide high quality educational content around Nx and its capabilities. The Nx docs have been restructured to follow the Diataxisframework, dividing content into into learning-, task-, understanding- and information-oriented sections.

This makes it easier to find keep the content organized and focused and makes it easier for the reader to choose between solution-oriented recipes vs learning-oriented tutorials.

The Nx team not only produces written content, but also video content mainly on the Nx Youtube Channel. Juri shows some of the growth stats, with the channel now having more than 14k subscribers and around 3.7k hours of watch time per month. The channel serves mostly short-form videos about new releases, highlighting new features as well as longer-form tutorial videos.

The Nx Community also got a special place in the keynote. Juri highlighted in particular the transition from the "Nrwl Community Slack" to the new "Nx Community" on Discord.

Discord is built for managing communities and will open up a series of features to come. Things like a built-in forum to ask questions, the ability to highlight Nx events (e.g. the Nx live stream) and having powerful automation and moderation tools. Since the launch a couple of weeks ago, already 1500+ members have signed up. If you didn't sign up yet, go to https://go.nx.dev/community.
Juri also highlighted the Nx Champions program that got launched this year which helps with efforts to grow the Nx community. The program features members that stood out in the Nx community by helping support others, producing content or speaking at conferences about Nx and related tech.

Finally there were also two announcements:

the Nx team decided to move off Medium for a better publishing experience but mainly also to avoid the paywall, something that the team has no control over. The new blog is currently being built and will be hosted at https://nx.dev/blog. This also allows to better resurface information by being able to integrate blog articles into the Nx docs search and make them also accessible to the Nx AI Assistant which was the 2nd announcement.
the Nx AI Assistant is an experiment the team is running to use AI to improve discoverability on the Nx docs. The ChatGPT powered assistant allows to ask natural language questions and responds based on the Nx docs training data, also including links to the sources. Try it out at https://nx.dev/ai-chat and use the feedback thumbs-up/down buttons to help improve it over time 🙏.

Also, Nx is open source: https://github.com/nrwl/nx. Contribute! And while you're there, don't forget to give us a star 😃.

Victor Savkin began the second segment of the keynote discussing the hidden expenses that often plague large teams.

He emphasized that as an organization grows, so does the supporting work. This isn't limited to just communication and management. Every artifact, be it code, process, or otherwise, needs to be assimilated into the broader context. This supporting work becomes intricate and demanding. He pointed out that the remote work trend, while it started with a lot of momentum, struggles in larger corporations because it demands even more coordination and effort. In contrast, smaller entities often outshine their larger counterparts due to the reduced overhead of supporting work.

One of Victor's main points was the potential of software developers. Given the right tools and environment, they can achieve remarkable feats. CI is one such tool.

The state of CI configuration, Victor explained, is essentially a meticulous blueprint of tasks for the CI tool. This blueprint defines everything from the number of machines to their precise roles. Historically, these processes were performed manually, with individuals running test cases and subsequently approving or rejecting them.

However, scaling CI is a challenge. In larger workspace, up to 50 agents is pretty common, all requiring careful coordination and configuration to ensure tasks run in the correct order.

This might be manageable in a static repository setup, but monorepos introduce an added layer of complexity. Here, static "CI recipes" just won't cut it. The result is either an overuse of computational resources, leading to waste of money, or a painfully slow CI.

Victor critiqued that most current CI setups are:

Oriented towards machines
Low-level in their configuration
Maintenance-heavy
Detached from developer intentions
Challenging to implement with monorepos

The big question: how can we revolutionize CI? Victor then showcased a demo workspace and highlights where the complexity of setting up CI comes from:

Even running e2e tests on CI requires:

Building the application to be tested to produce an artifact
That usually requires first building all libraries the app depends on, in the correct order
Once all libraries are built, the application itself can be build
Finally e2e can be run on the application artifact

Notice, since we want to do this as fast as possible, we want to parallelize these operations across machines. This involves also taking care of transferring build artifacts between them.

This is where Nx Cloud Workflows shines. It enables developers to draft CI configurations at a far more abstract level. Instead of delving into the minutiae of tasks, developers specify what commands to execute, with the how being implicitly managed by Nx Cloud.

env:
  NODE_OPTIONS: '--max_old_space_size=4096'
setup:
  - name: Git Checkout
    uses: 'nx-cloud-steps/checkout'
  - name: Npm Install
    uses: 'nx-cloud-steps/npm-install'
steps:
  - name: CI Checks
    parallel-scripts: |
      nx affected -t build e2e --parallel=1
      nx affected -t test lint --parallel=3

This elevated abstraction is possible because Nx Cloud & Nx are intimately familiar with the workspace, understanding the interdependencies between projects and tasks.

Beyond simplifying CI configurations, Nx Cloud Workflows helps optimize computational resource use. Agents are instantiated dynamically based on the project's requirements.

Victor highlighted that most current CI setups:

Consistently utilize a predetermined number of agents, irrespective of the actual needs of the PR
Possess non-reusable agents since each is tailored to a specific task, like building or testing
Struggle with granular retries

As a metaphor Victor mentions that Nx Cloud Workflows is to CI what S3 is to file uploads.

Sounds interesting? Watch the entire talk here.

Nx Cloud Workflows: Next-Gen CI with First-Class Monorepo Support

Speaker: Simon Critchley
Slides • Watch on Youtube

Simon Critchley (Senior Software Architect at Nx) dives into the more technical details of the newly announced Nx Cloud Workflows (which is in private beta as of this writing).

Apart from the distributed caching, Nx Cloud already offers DTE (Distributed Task Execution), which is a mechanism to seamlessly distribute tasks across various machines to achieve a high degree of parallelism. Up until now it was on you to configure your existing CI in a way to provision machines (agents) to Nx Cloud DTE. This required some fine-tuning to understand the best level of parallelism given the underlying monorepo and tasks that need to be run. If you have too many machines, it'll be wasteful, if you have to few your CI will be slower.

Nx Cloud Workflow is an advancement of the DTE mechanism, where machines can be automatically provisioned and scaled based on the tasks that need to be run. Essentially it is a replacement for your existing CI but way smarter because it is able to leverage the knowledge it has about the Nx workspace, historical data and can thus do a series of optimizations. Traditional CI systems are running low-level commands on machines. Nx Cloud Workflows is task oriented instead: you tell it to run builds, tests, e2e, linting on the affected projects of the Nx workspace and it figures out how to split them up into fine-grained tasks and then distributes them among dynamically provisioned agents.

From a developer's perspective, Nx Cloud Workflows are written in Yaml (or alternatively in JSON which is handy if you need to generate them). The format is very similar to existing CI providers to make sure the knowledge you have easily transfers. If you want an example, we're dog-fooding Nx Cloud Workflows on the Nx repo (note the config will change as the product progresses): https://github.com/nrwl/nx/blob/master/.nx/workflows/agents.yaml

Simon then dives way deeper into the underlying architecture. In particular, how scheduling in Kubernetes works, which is used at the infrastructure level for Nx Cloud Workflows.

Workflow scheduling is handled by Kubernetes, specifically through a "Workflow Controller" that interacts with the K8s API Server and triggers Kubernetes Pods. Each Pod contains a Workflow executor and sidecar containers. All containers in the Nx Cloud workflow share a workspace volume for collaborative access. This allows for interesting optimizations in terms of sharing node_modules and restoring cache results.

The Workflow executor, written in Go, is responsible for receiving and executing workflow steps, capturing output, buffering logs, and communicating with the Workflow Controller. It also exposes its own grpc API for distributed locking, file system cache operations, and setting output parameters for each step, ensuring efficient workflow execution.

Nx Cloud Workflow is in its early development phase. The Kubernetes scheduler supports Docker based executors (basically any Docker image can be used as build image).

Windows, macOS and Linux is currently in development which will use a Cloud VM scheduler on the cloud of your choice.

United by Nxcellent DX

Speaker: Michael Hladky
Slides • Watch on Youtube

Michael talks about how to leverage Nx to migrate multiple repositories into a monorepo to streamline development and increase developer productivity. He goes through

how a project gets started
how to prep moving to a monorepo from a polyrepo situation
how to do the move in parallel
how to measure the progress

The project usually starts with an architectural audit. That involves a detailed analysis of the underlying codebase, also including an executive summary for non technical folks. Once the audit is done, the actual move is planned and prepared. A part of that is to define "Nx migration goals", like

Single Version Policy
Improved Maintenance
Shared Infrastructure
Shared Architecture
Efficient Task Runs
Frictionless Code-Sharing
Frequent Deployments
Decouple Deployment

To prioritize which ones to address first, Michael uses the following metaphor:

The important part here is to understand why "apples get bad" in the first place. Is it the harvesting process?

Once the priorities are defined and roadmap laid out, the goal is to move in parallel.
As part of that move the following gets produced:

Migration Guide
Training Program
Communication Strategy
Impact Measurement

The migration guide defines where to start, what the company goals are, how the deliveries will be integrated into the existing process and how the interaction with the various teams will happen.

The training program is there to tackle the bottleneck of missing knowledge, right from the beginning. Each stage of the process will have a different training content and collect feedback.

Finally the impact measurement; Nx Cloud already has graphs to measure how much time got saved in CI due to the improvements made. Michael mentions they go further, also measuring communication and productivity.

An interesting part is also how they perform the repository synching (from polyrepo to monorepo). They leverage an Nx plugin that

contains shared build logic
has rules to run that produce actionable feedback about what is needed to sync/align the polyrepo repository s.t. it can be merged into the monorepo
it also allows to track progress and produce according reporting of where the company is at

Sounds interesting? Watch the entire talk here.

Redefining Projects with Nx: A Dive into the New Inference API

Speaker: Craigory Coppola
Slides • Demo Repo • Watch on Youtube

Craigory did a deep dive into the new Nx inference API. This is particularly interesting if you're developing Nx plugins or if you have leverage/build some more advanced automation for your Nx workspace.

What is project inference

how Nx reads your project configuration
introduced between v13.3 and v14
initially to support package-based monorepos which use package.json scripts rather than project.json. Generalizing the project config reading mechanism also allowed to define an API that community plugins can leverage and which allows to integrate even languages outside the JS ecosystem into Nx (e.g. where projects are just defined differently, such as .Net, Java, Python,..)

Inference API v1

projectFilePatterns - identify files that represent the root of a project
registerProjectTargets - takes a project file and converts to a list of targets that Nx knows how to run

Shortcomings have been

strict 1-1 mapping between project files and projects
the logic of finding proj files and targets had to be decoupled which introduced potential failure points
no way to add dynamic metadata to a project

Project graph API v2

createNodes - finds graph nodes based on files on disk
createDependencies - finds edges to be added to the graph

Still 2 parts, but there's no overlap between these two and they have very specific purposes.

createNodes is a tuple composed of

projectFilePattern
CreateNodesFunction It can return a map of projects and external nodes, so there's no more the shortcoming of a 1-1 as it was in v1 API. With this new setup multiple plugins might detect the same project. Nx merges the configuration that has been identified. Kinda what happens right now if you mix package.json and project.json targets in an Nx workspace.

Craigory demoes the inference API by building a spell checking plugin for Nx.

createDependencies replaces processProjectGraph. It is more constrained but mainly because things like adding nodes should be done in a different function now (e.g. createNodes). This has also advantages for Nx itself, as it knows all nodes will have been created after the createNodes has terminated.

This API is still marked as experimental, next steps will be

mark as stable
remove v1 API after deprecation period
plugin authors should start looking into the new API, provide feedback and think about migration scenarios

Package-based to Integrated: One Small Step or One Giant Leap?

Speaker: Isaac Mann
Slides · Repo · Watch on Youtube

Isaac initiated his talk by drawing an analogy between software development and the moon landing. While Neil Armstrong is often singularly celebrated for setting foot on the moon, Isaac emphasized that the monumental achievement was the collective effort of countless individuals on the ground crew, from engineers to support staff.

Isaac: Nx wants to be that indispensable ground support crew for developers, allowing them to push the boundaries of software development.

Currently, Nx offers support for two predominant monorepo styles: package-based and integrated.

Package-based Monorepos:

These are tailored for flexibility and innovation.
Packages within this setup can have diverse configurations.
Every package boasts its individual node_modules and dependencies.
Crucially, each can be upgraded independently, offering a high degree of autonomy.

Integrated Monorepos:

These are structured to prioritize consistency and maintainability.
Updates within this framework are automated, and the setup adheres to a single-version policy.

Isaac then drew parallels between the Apollo program and the package-based mindset. The Apollo missions were evolutionary in nature, constantly pushing the envelope and embracing innovation with each successive mission. However, this trailblazing approach wasn't without its perils, as evidenced by tragic accidents. This experimental approach was feasible because the core team, responsible for creating the setup, remained consistent throughout the project's duration.

In contrast, Isaac likened the International Space Station (ISS) to the integrated mindset. The ISS epitomizes the challenges of coordination, given its international collaboration involving numerous countries. Emphasizing longevity, the ISS necessitates that every new crew member be proficient in operating its intricate machinery.

Shifting gears, Isaac delved into a hands-on demonstration. He outlined the process of transitioning from a package-based monorepo to an integrated one, including demoing

Initializing Nx with nx init.
Establishing new projects to facilitate type sharing across applications.
Harnessing the power of the Nx graph visualization to navigate and understand the project structure.
Employing the module boundary rule, ensuring constraints are maintained in the revamped structure.
Devising a novel Nx generator, streamlining the process of setting up new libraries within the workspace.
Finally, he showcased the seamless upgrade mechanism, ensuring the workspace is always aligned with the latest version.

Nx't Level Publishing

Speaker: James Henry
Slides · Watch on Youtube

James Henry unveils the new versioning and publishing functionality that is now built into Nx itself.

Nx has always given you the building blocks to do integrate the versioning and publishing; you could easily use Lerna with Nx, or changesets, release-it as well as a series of Nx Community plugins
The nx core team decided to go into this problem space and provide an opinionated approach that is easy to use within existing Nx workspaces; something that works and scales; also something that works outside the JS ecosystem which Nx can also be used with

new command nx release
- nx release version to determine and apply version updates
- nx release changelog generate a CHANGELOG.md file and optional GitHub releases based on git commits
- nx release publish takes a newly versioned project and publishes them to a remote registry (e.g. NPM)

this new command is not tight to package.json files but is general purpose; clearly publishing JS/TS packages is the main use case right now in Nx
Important to note that all the existing plugins are still valid and will still be going forward.

James goes forward demoing how nx release works in a simple NPM package: jump directly into the video

Nx release can be added to any npm package. All that's needed is the nx and @nx/js package and a nx: {} node in the package.json

nx release has a dry-run mode; nx release version --dry-run. This will output a diff of what version would be created and on which package.json files (if there are multiple).
The same mechanism also works for the changelog command, e.g. nx release changelog --dry-run. In addition to just dry-run, the changelog command also has an --interactive mode that allows to get the generated changelog in an interactive editor where you can adjust and add extra stuff.

James then moves on to show how the release process works in a monorepo scenario using pnpm workspaces, where there are multiple NPM packages that need to be published: Jump to the video.

The monorepo has a pkg-a and pkg-b where there's a relationship between them as follows: pkg-a --> pkg-b .
If the version command is used in such scenario, it will also be applied to the dependent packages (pkg-b) since Nx knows about the dependencies via the project graph.
A nice feature is also that the changelog will

automatically group first by type (e.g. features grouped together, fixes etc)
within each type grouping it will be grouped by scope such as pkg-a etc which will be alphabetized
if there's a fix on the entire repo that'll come first before the per-package changes

nx release changelog --create-release=github allows to also automatically push the changelog to a Github release.

When running nx release publish, Nx also takes into account the right order of how the packages should go on NPM. Like if there's a relationship pkg-a --> pkg-b, Nx automatically detects such dependency and will go and publish pkg-b first and then pkg-a which depends on it. That to make sure that even if there's a network error in between packages, you'd still not break anything.

Future roadmap:

ability to customize how the release works by defining it in nx.json
"release groups" will allow to group packages and define whether versions should be in sync or versioned independently; filter by projects, or even just publish a subset of projects of a workspace
publishing also automatically takes into account the provenance data on NPM

Lightning Talk: What if your stories were - already - your e2e tests?

Speaker: Katerina Skroumpelou
Slides · Repo · Live Demo · Watch on Youtube

Katerina starts by introducing the concept of UI testing for error detection, usability verification, regression prevention but also for validating the user journey and making sure the software is reliability.

Nx had support to use Storybook for doing component-level tests, both using a Cypress e2e setup as well as Cypress component tests. This is where Nx would fill in to launch Storybook to render a single component and then launch Cypress and run dedicated tests against that served component.
Meanwhile Storybook has introduced so-called Interaction Tests which allow you to do something similar.

You can read more on our docs. Or check out our corresponding video on Youtube.

Lightning Talk: Nx Cloud Demo

Speaker: Johanna Pearce
Watch on Youtube

Johanna gives us a tour through the Nx Cloud UI. So there's not much to say other than go watch the talk :)

From DIY to DTE - An Enterprise Experience

Speaker: Adrian Baran
Slides · Watch on Youtube

Adrian Baran, a Senior Software Engineer at Cisco, embarked on his talk by presenting the status quo of their monorepo which encompasses approximately 150 projects at the start of the experiment.

Their CI workflow is powered by CircleCI. For the purpose of clarity, Adrian zoomed in on the frequently executed tasks: build, lint, and test. To execute these tasks, they leverage the Nx affected command to avoid running all commands on all projects.

Despite that, on average CI runs on PRs still lingered around the 1-hour mark. The immediate remedy? Harnessing CircleCI to parallelize tasks across multiple machines, while continuing to utilize Nx affected. Adrian wrote about that journey in a blog post last year, titled Nx Affected + CircleCI Parallelism = Faster CI/CD Pipelines.

They ended up with a loooot of parallelism:

The outcome was promising though – they witnessed a significant reduction, approximately 75%, in execution time, even in scenarios where all projects were influenced by a PR. Done, right?

However, as their monorepo burgeoned to encompass 400+ projects, the DIY solution began to show its limitations. The incessant parallelization implied the addition of more agents, leading to escalating costs. Furthermore, they observed considerable variability in task durations.

Their workaround was to manually allocate specific tasks to distinct agents. This method in addition to capping on a max number of agents helped keep costs under control, but regrettably, it also compromised performance due to the lowered parallelism.

This is when Cisco looked into running an Nx Enterprise pilot, specifically with the goal of adopting DTE. In the 2nd part of the talk, Adrian outlined their journey of setting up DTE, starting with the generation of the initial CI setup:

nx g @nx/workspace:ci-workflow --ci=circleci

They tuned the generated configuration, but failed to get it properly running, many of the issues leading to resource exhaustion. As a result, they went the route of going on a 1-1 mapping setup between DIY and DTE. That made sure the DTE setup was as close as possible and allowed for a gradual transition approach, which proved invaluable, allowing them to maintain stability whilst progressively migrating to DTE.

The comparative analysis of their DIY solution versus DTE revealed roughly equivalent performance metrics. However, the DTE framework shone in its simplicity, maintainability, and resource efficiency, achieving similar outcomes with a 75% reduction in resource utilization.

Adrian's Key Insights:

DTE setup warrants a dual-pronged strategy: an immediate plan for initiation and a long-term vision for transition. Notably, Nx DTE supports incremental adoption.
Patience is paramount during the tuning phase to determine the optimal number of agents.
While results might vary, Adrian humorously assures that one can always bank on the Nx team for support. 😅

Vanquishing Deployment Dragons with Nx wizardry

Speaker: Miroslav Jonas
Slides · Jump to the live stream · Watch on Youtube

There's not much to say here. Lean back and emerse yourself into the world of dragons and wizards

Optimizing your OSS infrastructure with Nx Plugins

Speaker: Brandon Roberts
Slides · Watch on Youtube

Brandon discussed his work on the open-source tool Analog and how Nx Plugins are crucial to its development.

He introduced Analog, shedding light on its foundational ecosystem and the its core features.

Nx plays a crucial role in helping integrate and maintain these different tools:

How? Brandon dives straight into it by explaining how Nx plugins in particular can be useful, explaining:

Features of Nx plugins such as generators, executors, automated migrations, presets and how to use them just locally to automate your workspace
how to create a new plugin
the anatomy of a generator and how they can be useful in scaffolding new setups, but also integrating technology, like adding tRPC to your stack etc
Similarly Nx executors provide a thin abstraction layer over the actual commands, allowing the plugin developer to update the underlying tooling without necessarily disrupting the end user
most importantly allowing to write automatic migrations he can leverage with Analog, like running nx migrate @analogjs/platform@latest to update a given workspace automatically to the latest version, across potentially breaking changes.

Brandon highlighted a pivotal aspect for OSS package/framework authors: the power to not just assimilate into pre-existing Nx workspaces via custom Nx plugins but also to steer the entire workspace setup process. This is particularly beneficial when tailored setups specific to individual use cases are required. By leveraging an Nx preset, one can achieve this tailored configuration. Brandon also touched upon the possibility of advancing further by constructing an install package through Nx.

Level Up Your Productivity with Nx Console

Speaker: Jonathan Cammisuli & Max Kless
Slides · Watch on Youtube

Jon and Max are the masterminds behind Nx Console, the Nx IDE extension for Code and JetBrains.

They mention the release of the JetBrains IDE support earlier this year and give a big shoutout to Issam who was the original author of the Nx Console Webstorm community plugin and who helped a lot with the official Nx Console version for JetBrains IDE.

Jon and Max demo the new IntelliJ version of Nx console and how it properly integrates as well as how they wrote the new UI completely from the ground up using Lit.

Clearly they did not spare showing off the awesome new graph capabilities built into Nx Console that allow you to directly navigate to files.

That's a wrap

If you enjoyed these, make sure you subscribe to our Youtube channel where we keep releasing educational content and fun videos.

Also

say hi on Twitter/X
subscribe to our Newsletter

Evergreen Tooling - More than Just CodeMods

Juri Strumpflohner — Wed, 26 Jul 2023 13:15:48 +0000

As developers, we always want to use the latest shiny tools. There’s a new bundler? Let’s try! A new code editor, I’m in! For your side-project: for sure! At work: nah, not really. Keeping your tooling up to date with the relatively fast-moving JS ecosystem can be a significant challenge. Nx provides a mechanism that can help mitigate that by providing a command to upgrade your tooling automatically:

npx nx migrate latest

Prefer a video? I’ve got you covered!

TL;DR

You can run the following command to automatically upgrade your Nx workspace to the latest version:

npx nx migrate latest

The Balancing Act: Updating Tooling vs Shipping Features

If you’re anything like me, you’ve probably found that discussions about updating tooling tend to fall to the bottom of the priority list when talking to your product owner. It’s understandable - their primary goal is to ship features. However, sticking with outdated tooling can impact our ability to deliver these features swiftly (not to speak about potential security concerns due to outdated libraries).

Don’t get me wrong, I’m not suggesting that we should always be on the bleeding edge of technological innovation - especially in an enterprise environment.

Jason Lengstorf has some opinions there as well: “The Hidden Danger of Switching Tech Stacks in 2023?).

It’s wise to let security patches land and initial bugs get fixed before jumping on the upgrade bandwagon. But here’s the catch - don’t wait too long. The longer you delay upgrading, the more challenging and time-consuming it becomes. And the more effort it requires, the harder it is to sell the idea to your product owner.

The Key: Making Updates Easy(ier)!

Updating tooling is never easy, but the Nx team aims at making it “easier” at least. We try to embrace the concept of “evergreen tooling”, a strategy that’s been around since Google decided to automatically update Chrome for all users. The Angular team adopted this approach for their Angular CLI, and Nx has followed suit. But what exactly is it, and how does it work?

What if I told you Nx users have been automatically updating their React applications from Webpack 4 to Webpack 5!

The “why” is pretty straightforward. From the perspective of an open-source project, you want users to adopt the latest version as quickly as possible. This minimizes the maintenance work involved in supporting older versions, which can be a real headache. Looking at how Nx manages it, it seems to be successful in this regard (Source):

The distribution of Nx installs by version demonstrates the effectiveness of this approach. For instance, v16.5, which accounts for 19.7% of all versions, has already been adopted by many users, despite its recent release. The latest major accounts for 34.7% already and 41.4% are on the previous v15, a large majority of which is on the latest 15.9 minor. Hence, v16 & v15 make up 3/4 of all Nx installs.

How? Database Migration Scripts for Code?

If you know what “database migration scripts” are, then yes, it’s the same concept but applied at the code level. A series of small functions invoked to bring your workspace from version X to version Y (usually the latest). That includes:

update nx itself
update all Nx plugins and the technology they are responsible for (for example: @nx/react will upgrade React as well, @nx/webpack is upgrading Webpack)
automatically adjust relevant config files and source code (e.g., adjusting imports, functions etc..)

Everything that is required to get you to the latest version and still have a running code, even if there have been breaking changes.

How?! Because the Nx team (and plugin authors) do the work for you! Nx has a built-in mechanism where you can define so-called “migrations” for each Nx package. Here’s an excerpt of the @nx/webpack's migration file.

{
  “generators”: {
    "add-babel-inputs": {
      “cli”: “nx”,
      “version”: “15.0.0-beta.0”,
      “description”: “Adds babel.config.json to the hash of all tasks”,
      "factory": "./src/migrations/update-15-0-0/add-babel-inputs"
    },
    "remove-es2015-polyfills-option": {
      “cli”: “nx”,
      “version”: “15.4.5-beta.0”,
      “description”: “Removes es2015Polyfills option since legacy browsers are no longer supported.”,
      "factory": "./src/migrations/update-15-4-5/remove-es2015-polyfills-option"
    },
    "webpack-config-setup": {
      “cli”: “nx”,
      “version”: “15.6.3-beta.0”,
      “description”: “Creates or updates webpack.config.js file with the new options for webpack.”,
      "factory": "./src/migrations/update-15-6-3/webpack-config-setup"
    },
    "add-babelUpwardRootMode-flag": {
      “cli”: “nx”,
      “version”: “15.7.2-beta.0”,
      “description”: “Add the babelUpwardRootMode option to the build executor options.”,
      "factory": "./src/migrations/update-15-7-2/add-babelUpwardRootMode-flag"
    },
    "update-16-0-0-add-nx-packages": {
      “cli”: “nx”,
      “version”: “16.0.0-beta.1”,
      "description": "Replace @nrwl/webpack with @nx/webpack",
      "implementation": "./src/migrations/update-16-0-0-add-nx-packages/update-16-0-0-add-nx-packages"
    }
  },
  ...
}

They are defined in a migrations.json config file within the NPM package. Each entry defines a version for which the entry should be run, a description (just for humans to read) and a factory property which points to a TypeScript file.

Example: if you’re on Nx 15.5 and you run nx migrate latest it would run the corresponding “factory functions” for:

webpack-config-setup
add-babelUpwardRootMode-flag
update-16-0-0-add-nx-packages

Depending on the nature of the update, these functions can be as simple as performing text replacements to more complex AST parsing and TypeScript source file manipulations. Let’s have a look at the add-babelUpwardRootMode-flag migration:

import {
  formatFiles,
  readProjectConfiguration,
  Tree,
  updateProjectConfiguration,
} from '@nx/devkit';
import { forEachExecutorOptions } from '@nx/devkit/src/generators/executor-options-utils';
import { WebpackExecutorOptions } from '../../executors/webpack/schema';

export default async function (tree: Tree) {
  forEachExecutorOptions<WebpackExecutorOptions>(
    tree,
    ‘@nrwl/webpack:webpack’,
    (
      options: WebpackExecutorOptions,
      projectName,
      targetName,
      _configurationName
    ) => {
      if (options.babelUpwardRootMode !== undefined) {
        return;
      }

      const projectConfiguration = readProjectConfiguration(tree, projectName);
      projectConfiguration.targets[targetName].options.babelUpwardRootMode =
        true;
      updateProjectConfiguration(tree, projectName, projectConfiguration);
    }
  );

  await formatFiles(tree);
}

It leverages the utility functions provided by the @nx/devkit package to read the various projects.json files to adjust the babelupwardRootMode property.

Nx’s modular design helps as each plugin is responsible for a particular area and can thus contribute according migration scripts. To give you some context. There is the nx package at the core - which you can use nicely in combination with a PNPM workspaces repo to speed things up - and then there are plugins built on top.

(Source: https://nx.dev/getting-started/why-nx)

These plugins are usually technology-specific, like a plugin to help you manage React, Next, Remix, or Angular projects and tooling like ESLint, Cypress, Playwright, Vite, Jest, and so on. There are no limits as you can create your own. They are optional, in that you can use Nx and React and set everything up on your own. But it might be worth relying on them for some better DX and automation, such as the update mechanism we’re currently looking at.

Plugins are helpful here, because each plugin has a clearly defined responsibility. Like the @nx/webpack we looked at earlier, handles everything related to Webpack. So it’ll be responsible for updating the webpack NPM package and adjusting config Webpack-related files.

Performing the Update

Alright, we’ve learned how these updates work behind the scenes. Let’s look at what the experience looks like as a developer performing the update on your codebase.

Note, it is highly recommended to start with a clean Git workspace s.t. you can quickly revert the update.

To run the update, use the following command:

npx nx migrate latest

Note latest stands for the target version. You can also provide a specific Nx version if you cannot update to the latest one for some reason.

At this point, Nx

analyzes your workspace and finds all the plugins you’re using
downloads the version of the plugins specified in the migrate command above
collects all the migration.json files from these plugins
picks out the relevant ones based on your current workspace version
creates a migrations.json at the root of your workspace
updates the package.json to point to the matching NPM package versions (without performing an install just yet)

You can now inspect the migration.json and the package.json before you run the following command to run the migrations on your codebase.

npx nx migrate —-run-migrations

After that, your codebase should have been updated. Run your (ideally automated) sanity checks and fix the remaining issues that couldn’t be adjusted automatically.

Wrapping Up

That’s it! If you want to dive deeper, here are some potentially helpful links:

Also, if you haven’t already, give us a ⭐️ on Github: https://github.com/nrwl/nx. We’d appreciate it 😃.

Learn more

Also, if you liked this, click the ❤️ and make sure to follow Juri and Nx on Twitter for more!

#nx Follow

Nx Cloud 3.0 - Faster Cache, More Powerful DTE, Better Ergonomics

Juri Strumpflohner — Wed, 19 Apr 2023 18:25:35 +0000

It has been almost 2 years since we released Nx Cloud 2.0. Since then, it has saved over 400 years of computation by leveraging its distributed caching and task execution. And we keep adding 8 years every single week. Not only does this tremendously impact our environment, but it also helps developers be more productive and companies save money.

In the last couple of months we have quadrupled the team and have done some amazing things. And we have some big plans for what is coming next. Here's all you need to know!

1. New, Streamlined UI
2. Prefetching and Faster Cache Uploading
3. DTE Just got Better
4. Direct Integration With GitHub, GitLab and Bitbucket
5. Enterprise Support
6. New, Simplified Plans and Pricing Model
7. Coming Next
8. Learn more

Prefer a Video? We've got you Covered!

New, Streamlined UI

This latest release of Nx Cloud comes with a new, streamlined design that offers users a more modern and visually appealing experience. This includes the main Nx Cloud website, where we improved our messaging, including interactive visualizations to better explain some core concepts around remote caching and distributed task execution.

The Nx Cloud application - showing your runs, cache saved, and stats - also got a significant overhaul, making the UI more lightweight and easier to parse.

More UI-related updates and improvements are already underway.

Prefetching and Faster Cache Uploading

At Nx, we are performance addicts! Especially when it comes to local development, every millisecond counts! In the latest update of the Nx CLI, we added the ability to offload some of the remote cache management to the Nx Daemon. As a result you no longer have to wait for the cache to upload. This saves valuable time, allowing the command to complete instantly and immediately providing you with the necessary link.
We also prefetch cache results in the background to have them ready when needed.

Both optimizations can save seconds.

DTE Just got Better

Distributed Task Execution (short DTE) is a core part of what makes Nx Cloud stand out compared to other solutions. And we made some significant improvements to both the ergonomics and speed.

Identify failed tasks early - You can now view information about the in-progress DTEs, allowing you to quickly identify and address any failed functions without waiting for the command to complete.

Simplified CI setup - We simplified the setup process for most CI systems, eliminating the need to pass environment variables manually. Instead, everything is automatically derived from the context.

Improved performance and efficiency - Nx Cloud now intelligently figures out which tasks will be cache hits before sending them to agents. Rather it can directly send them to the main job, reducing unnecessary round trips and drastically speeding up CI pipeline executions.

Efficient agent management - We have introduced a new command, npx nx-cloud start-ci-run –stop-agents-after=e2e, that allows you to notify Nx Cloud when specific commands, such as long-running e2e tasks, have started. This helps Nx Cloud proactively identify and shut down agents that will not be needed, improving compute efficiency.

Reduce fix costs - Even though cache hits are basically free, spinning processes still have fixed costs. We fixed that (see what I did there) by leveraging a new Nx feature that allows to have a long-running process on an agent to which we can arbitrarily feed new tasks. This removed the DTE overheads and also improved the predictability of runs.

Direct Integration With GitHub, GitLab and Bitbucket

Our GitHub integration has been enhanced. Now, the list of runs is updated in real-time as soon as they are created or their status changes, providing developers with up-to-date information directly on GitHub.

In addition to the GitHub, we expanded our Nx Cloud live status updates to work on GitLab and BitBucket.

Enterprise Support

We have extensive experience working with Fortune 500 companies, helping them scale their development using monorepos. This has given us valuable insight into the unique security requirements of these companies. Our Enterprise plan reflects that allowing organizations to have a fully self-contained version of Nx Cloud that can be hosted on their own servers and comes with dedicated support from the Nx and Nx Cloud core team.

We've recently made a couple of improvements to our enterprise offering.

Helm Charts - We added a Helm chart to simplify the process of deploying Nx Cloud to on-premises infrastructure, allowing organizations to quickly set up and manage their own instance of Nx Cloud within their secure environment.
Stability improvements - We significantly reworked our on-premises solution to be identical to our SaaS deployment. This revamp resulted in a more robust and reliable on-premises deployment of Nx Cloud, ensuring enterprise-grade performance and reliability.
SSO - We now support AWS Identity and Access Management (IAM) for seamless integration with existing AWS environments and the SAML protocol for a more flexible single sign-on integration across various providers. This enables organizations to leverage their existing identity management systems for authentication and authorization.

Learn more at https://nx.app/enterprise.

New, Simplified Plans and Pricing Model

Nx Cloud has evolved a lot since we first released it in 2020, and is changing even more in 2023. To better adapt to Nx Cloud being a critical CI tool, we changed our pricing model to be more consistent and predictable for CI workloads.

Nx Cloud's previous pricing was based on time savings from Nx Cloud, which made sense when Nx Cloud was strictly a distributed caching service. The new pricing model is based entirely on the number of CI pipeline executions per calendar month. We believe this is a simpler and more transparent model that should help you predict your costs far more easily.

Our Free plan allows one administrator and up to 300 CI pipeline executions per month. Our Pro plan allows more administrators, and uncapped CI pipeline executions, with a flat fee and incremental charges per 100 CI pipeline executions. The OSS plan comes with unlimited CI pipeline executions. Nx has been open source from the beginning and we care a lot about that ecosystem. So this is our contribution to help OSS projects and make their CI pipeline executions faster.

Finally, the Enterprise plan is for companies that want full control over where their data is hosted, get hands-on, dedicated support from the Nx & Nx Cloud team, and enterprise features such as SSO & SAML-based authentication support.

All these changes should allow developers to choose the plan that best suits their needs and budget more easily, ensuring a seamless and transparent experience regarding pricing and subscription management.

Learn more at https://nx.app/pricing.

Coming Next

We've got some big plans for Nx Cloud. You really want to write your CI script by focusing on what you want to achieve rather than thinking about making it fast. We're going to make this happen!

The current Distributed Task Execution (DTE) already goes a long way, but you still have to provision the agents by yourself. Providing the correct number of agents is crucial for maximizing efficiency and reducing idle time. And it is not even a static number but might depend on the actual run itself. Nx has extensive knowledge about the structure of the workspace and according tasks. We want to leverage that information. Imagine a setup where you have a roughly 20 line CI config for a repo with hundreds of developers and Nx Cloud automatically determines for each run the ideal number of agents required, provisions them, distributes all tasks efficiently and then disposes all agents again. All fully automatically. And it will be fast. To the point where you wouldn't even need your Jenkins, CircleCI etc at all.

In addition, we are actively exploring ways to provide advanced analytics for your workspace, including insights into the frequency and duration of specific tasks. This valuable information can help identify large tasks that could benefit from being broken down into smaller ones, leveraging caching and other speed improvements to optimize performance. Stay tuned for more to come!

Learn more

Also, if you liked this, click the ❤️ and make sure to follow Nx on Twitter for more!

#nx Follow

Rspack - Getting up to speed with Nx

Juri Strumpflohner — Fri, 10 Mar 2023 09:04:57 +0000

At Nx, we are excited to see the JavaScript tooling ecosystem evolve, particularly when it comes to improving speed! Performance is at the core of Nx. Faster tools with which we can integrate make our lives easier and allow us to provide a better experience for developers.

Almost a year ago ByteDance started developing a new, faster Webpack alternative: Rspack. Valor Software joined the collaboration and reached out to us about developing a dedicated Nx plugin. The goal: give developers an easy onboarding path to Rspack and React!

Faster than Webpack? What is Rspack?

Rspack is a rewrite of Webpack with the primary goal of improving performance. Rust is the main language, allowing for a highly parallelized architecture that takes full advantage of modern multi-core CPUs. In addition, it also comes with essential bundling features already built-in to avoid further bottlenecks from 3rd-party packages. It also highly optimizes HMR (Hot Module Replacement) using a specialized incremental compilation strategy.

ByteDance developed Rspack to solve performance issues they faced when developing and maintaining their internal monolithic applications, all of which rely heavily on complex Webpack configurations. Rspack being a rewrite allows to rely on Webpack's mature architecture and is, at the same time, an easy drop-in replacement.

ByteDance already applied Rspack on some of their internal business applications and has seen between 5 to 10x improvement in compilation performance.

More on the official Rspack docs: https://rspack.dev

Getting up to speed with Rspack & Nx!

Our goal at Nx is to be the best CLI for your framework of choice. We want to remove friction so developers can easily leverage these new tools and focus on shipping features using a production-ready setup. This is why we developed a dedicated Rspack plugin that lets everyone quickly get up to speed.

Check out the following video for a complete walkthrough of how Nx and Rspack work together to create production-ready React applications.

React Standalone App with Rspack

You can create a new Rspack-based React application using the following command:

npx create-nx-workspace myrspackapp --preset=@nrwl/rspack

This creates a pre-configured setup with React, TypeScript, ESLint, Jest (optionally Vite), Cypress for e2e testing, and obviously Rspack as the bundler.

All the usual Nx features, such as

..work out of the box.

But not just the "speed features". All the code generators, automate code migrations, and code editor extensions work too.

Rspack in an Nx Monorepo

Similarly, you can use Rspack-based applications in existing Nx monorepos. Just install the NPM package:

npm i @nrwl/rspack -D

Then generate a new application:

npx nx g @nrwl/rspack:app myrspackapp

This creates a new application in your Nx monorepo that uses Rspack as the bundler. You can even import existing React libraries, which can also be an excellent way to experiment with Rspack in an existing production setup.

Wrapping up

Go and learn more on the

official Rspack website: https://rspack.dev
learn about the Nx Rspack plugin: https://nx.dev/packages/rspack

Learn more

Also, if you liked this, click the ❤️ and make sure to follow Juri and Nx on Twitter for more!

#nx Follow

Nx 15.8 - Rust Hasher, Nx Console for IntelliJ, Deno, Node and Storybook

Juri Strumpflohner — Wed, 08 Mar 2023 20:35:22 +0000

Just weeks after the release of Nx 15.7 (release video here), the Nx team has now launched Nx 15.8, with exciting new features and enhancements aimed at improving developer experience, productivity, and efficiency. Let's dive straight in.

1. Pefer a video? I've got you covered!
2. Heads-up: Release Live stream tomorrow
3. Rustifying the Nx Hasher
4. Deno Support
5. Nx Console - IntelliJ Support
6. Nx Console Field Prioritization (x-priority)
7. Modular Node Applications
8. Storybook
9. How to Update Nx

Prefer a video? I've got you covered!

Heads-up: Release Live stream tomorrow

We have the Nx live stream on Thursday, March 9th at 7 PM CET, to talk about all the features that went into Nx 15.7 and 15.8. So tune in to ask your questions :)

Enable notifications here:
https://www.youtube.com/live/P3TinTe3O2g?feature=share

Rustifying the Nx Hasher

Starting with Nx 15.8, we now have a Rust-based Hasher enabled by default!

Performance is at the core of what we do at Nx. Hence it isn't surprising that Nx is the fastest JS-based monorepo solution out there. We've shown that a couple of times. But every millisecond counts! As such, we decided to experiment with Rust to see whether we could further optimize our project graph creation as well as the hasher function that is used for the computation cache.

Our original implementation used Git to calculate the hash. But it had some downsides as

it didn't work if you don't have or use Git (obviously)
it didn't work if you used Git submodules
it became super slow if you had a lot of file changes on your Git working tree, like when switching between branches
it triggered a lot of execSync calls to get different git status which was a fragile implementation

In some situations where we couldn't rely on or use the Git hasher, we did a fallback to a node implementation which made things even slower.

All nice and good, but show me the numbers!

So we did run some experiments on a small repo:

avg. time for Rust hasher: 17ms
avg. time for Git hasher: 24ms

We also tried it on the Nx repository itself:

Rust hasher: 50ms
Git hasher: 69ms

When running these tests on Windows (not WSL), the Nx repo hashing timings turned out to be

Rust hasher: 72ms
Git hasher: 330ms

Right now, we only observed the Rust hasher to be slightly slower on large repositories when you don't have any changes. Once you start making changes the Git hasher becomes slower again and is overtaken by the Rust version which remains stable in performance.

An interesting side-effect of using the Rust-based hasher is the size of the generated hashes, which are much smaller and thus allow for a quicker serialization between the Nx Daemon and Nx.

Future work

While we started with the hasher optimization, the next implementation we’re exploring is using a binary format to communicate between the Nx Daemon and the Nx client. Currently, we serialize the JSON to a string, and pass that through an IPC socket. Using a binary format will significantly speed up the communication here.

Opting out

We build the binary for the Rust hasher for:

macOS x64
macOS arm
linux arm
linux gnu
linux musl
windows arm64
windows x64

As such, it should work on most CI and local developer machines. If we missed something, please reach out an open an issue on GitHub! In case something breaks though, you can also disable the Rust hasher by using the environment variable NX_NON_NATIVE_HASHER=true.

Deno Support

Nx Deno support already landed in 15.7, but didn't make it into the blog post. So here we go: we have a brand new Nx Deno plugin published at @nrwl/deno. For now, it is experimental and lives in our labs repository.

This plugin features the ability to generate Deno applications and libraries inside of an Nx workspace. Obviously, all the other much-loved Nx features such as caching, affected commands and the project graph visualization work out of the box as well.

To use Deno in an existing Nx workspace, just install the @nrwl/deno plugin:

npm i -D @nrwl/deno

Then run the generator to create a new application:

npx nx g @nrwl/deno:app mydenoapp

Or generate a new library with:

npx nx g @nrwl/deno:lib mydenolib

We're excited to see folks welcome in Deno APIs to their Nx workspaces and be able to easily share their Typescript packages across Deno, Node, and web applications, all inside the same monorepo.

Given this is still experimental, we're more than happy to receive feedback and hear about ways you are using Deno right now and/or plan to use it in an Nx workspace.

To see some of this in action, be sure to check out our recent livestream with Caleb and Chau, two of our engineers that have been working on this plugin:

Nx Console - IntelliJ Support

Developer tool CLIs are known for being, well, command-line interfaces. Nx comes with many of such CLI commands for scaffolding projects, running tasks, and more. We wanted to make some of this more approachable, so we introduced Nx Console, an extension to the Visual Studio Code editor. And it turned out to be highly successful. Nx Console now has over 1.2 million downloads on the Visual Studio Code marketplace. We kept improving it over the years,

adding support for rendering the Nx graph
providing IntelliSense support for Nx configuration files
integrating Nx Cloud

With the growing popularity, the ask for an equivalent extension for JetBrains' IntelliJ & WebStorm editors got louder and louder. At Nx, we're lucky to have an awesome community. Issam Guissouma and Edward Tkachev from the Nx community jumped in and provided their implementation of Nx Console for IntelliJ.

Since our team now works full-time on Nx and the surrounding tooling, we decided to have a dedicated Nx Console extensions for IntelliJ and WebStorm that is actively maintained and developed by the core team. We reached out to Issam and Edward and started collaborating on it. The result can now be installed from the JetBrains marketplace:
https://plugins.jetbrains.com/plugin/21060-nx-console

Read all the details on our blog post or check out our docs page about integrating with editors.

Nx Console Field Prioritization (x-priority)

Nx Console has proven a highly valuable tool for exploring Nx generators. Especially if you cannot recall all the various parameters, you can possibly pass. And sure, you could always pass the --help or browse the docs, but it is just less convenient.

With a growing number of parameters that a generator can take, it started to get messy and overwhelming. Furthermore, in 80% of the cases, you would probably need the main parameters such as the name, bundler, and directory where to generate the output.
This is the main reason we introduced a x-priority flag to our generator metadata, to have a way to prioritize certain flags and show them more prominently to the end user. Available values are important and internal.

The property can be defined for the desired parameters in the generator's schema.json:

{
  "directory": {
    "description": "The directory of the new application.",
    "type": "string",
    "x-priority": "important"
  }
}

All required properties and those marked with an x-priority: important will be shown at the top of both, the CLI output (when using --help) as well as the Nx Console UI.

Read all about it in the doc about Customizing Generator Options.

Modular Node Applications

Nx has had Node backend support since the very beginning, where you could add an ExpressJS or Nest.js based application to your monorepo. This is a powerful approach as it allows you to colocate your frontend and backend code, which helps share code and, in particular, TypeScript types for your APIs!!

In Nx 15.7, we then announced Nx Standalone Projects support for Node. This allows to develop a Node backend in isolation but still leverage all the features from Nx in terms of code generators, automated migrations and obviously speed features such as affected commands, caching and optimized CI setups.

In 15.8, we kept improving our Node support. Our main focus was on

allowing to have a non-bundled output, while still being able to modularize the codebase with local libraries
generating a pruned lock file when building in production mode
improving our docker setup to account for non-bundled output and properly install node packages

Check out the following video walkthrough on using these features for modularizing a Fastify application:

Storybook

Nx now generates stories using Component Storybook Format 3 (CSF3). If you are using our @nrwl/react:storybook-configuration, @nrwl/angular:storybook-configuration, @nrwl/react:stories and @nrwl/angular:stories generators, you will notice that the stories are now generated in the new format. You can check out our documentation for Storybook and Angular or Storybook and React to see the new syntax.

As the Storybook docs mentions, CSF3 reduces boilerplate code and improves ergonomics. This makes stories more concise, faster to write and easier to maintain.

You can migrate your existing stories in your Nx workspace to CSF3 using the Storybook csf-2-to-3 migrator:

npx storybook@next migrate csf-2-to-3 --glob="**/*.stories.ts"`

How to Update Nx

Updating Nx is done with the following command and will update your Nx workspace dependencies and code to the latest version:

npx nx migrate latest

After updating your dependencies, run any necessary migrations.

npx nx migrate --run-migrations

Learn more

Also, if you liked this, click the ❤️ and make sure to follow Juri and Nx on Twitter for more!

#nx Follow

Nx 15.7 - Node Support, Angular LTS, Lockfile Pruning

Juri Strumpflohner — Fri, 17 Feb 2023 09:52:51 +0000

Here's all you need to know about our latest Nx release.

Prefer a video? We've got you covered!

10k Subscribers on Youtube
Updates to our Nx Plugin Guides
Nx meets Node - First-Class Support landed
Detaching Angular versions
Bootstrapping a new Angular app with Standalone API support
Lockfile parsing and pruning
Storybook 7.0 beta support
More flexible Webpack config
How to Update Nx
Coming up

10k Subscribers on Youtube

It's almost a tradition to have some stats at the beginning of our Nx release blog posts. This time, about our YT channel: incredibly, we crossed 10k subscribers on our Youtube channel!!

Apart from delivering high-quality engineering work, we're very invested in producing educational content around developer tooling and monorepos. We've been almost consistently shipping new content every week, whether that is blog posts on the Nx blog or on dev.to or in the form of new videos and live streams on our channel. Seeing our audience grow on Youtube confirms we're on the right track and gives us new fuel to keep pushing!!

If you haven't subscribed yet, please do 🙏: https://www.youtube.com/@nxdevtools. We also announce most of our new videos and live streams on Twitter.

Updates to our Nx Plugin Guides

Nx has been designed to be extensible from the ground up. Which is precisely why Nx Plugins are so powerful. They don't just come as part of an Nx integrated monorepo or standalone setup. Still, you can leverage them in the same way to automate your local workspace or even share them as proper Nx plugins with the community.

Please have a look at our updated guide: https://nx.dev/plugin-features/create-your-own-plugin

Zack from our team wrote a full in-depth blog post on how to create your own stack with tRPC and Nx. He was also on the Nx live stream together with tRPC core member Ahmed Elsakaan. An edited version of the livestream can be found here.

Nx meets Node - First-Class Support landed

Due to a lack of time we never invested much more into streamlining the Node experience within Nx, though. This changed now, which is why we're committed to making Nx the best developer tool for node based apps. Starting with v15.7 we improved support for ExpressJS, Fastify and Koa.
When starting a new Nx workspace, you now have a new option: "Standalone Node Server app".

This is when you want a single-project Nx workspace to build out your Node backend.

All the features Nx is known for also apply to backend development. That includes

code generation support for all the previously mentioned Node frameworks
avoiding monolithic codebases via modularizing it with local libraries (with code generation support)
Ability to automatically setup a Dockerfile for packaging your app
Optionally bundle your Node app for easy deployment in the case of edge-functions
Speed via running building, linting, testing for only (affected) parts of your applications, via caching and optimized CI setups
the ability to use and/or expand to a monorepo

This is the first iteration with first-class Node support. But we're already working on a whole set of improvements for the Nx + Node story. So stay tuned!

Detaching Angular versions

The Angular CLI supports a single version of Angular and requires the user to upgrade them together with the help of automated upgrade mechanisms like ng update. On the other hand, Nx operates on a different release cycle and is independent of Angular versions. However, prior technical limitations resulted in each Nx major version only being compatible with a specific Angular major version. This caused challenges for Angular developers and corporations who were either stuck on an older Angular version or unable to upgrade promptly but still wanted access to the latest and greatest Nx features for increased productivity.

Starting with v15.7.0, the @nrwl/angular plugin will support both Angular v14 and v15, and our goal is to continue supporting the Angular LTS versions from Angular v14 onwards.

New workspaces will always be created with the latest Angular version, but during migration, you can skip some package updates as defined by Nx plugin authors. For Angular, this means you can skip migrating to newer versions. This feature can be enabled by running the following command in an interactive mode:

$ nx migrate latest --interactive

When collecting migrations in interactive mode, you'll be prompted to apply any optional migrations, and any updates you choose to skip won't be applied. The rest of the updates will be used as usual.

If you need to apply an Angular update that you previously skipped, you can collect migrations from an older version of Nx by running:

$ nx migrate latest --from=nx@<version>

In particular, we're working on making that part more intuitive in upcoming versions.

Also, have a look at our updated docs as well as our Nx and Angular compatibility matrix for more details.

Bootstrapping a new Angular app with Standalone API support

Angular's new standalone APIs is exciting as it provides a new, more lightweight way of developing and composing Angular applications without the need for NgModules. Nx has had the ability to generate new Angular components using the Standalone API for a while. With v15.7, we now also allow you to quickly bootstrap a new single-project Nx workspace with a NgModule-less Angular application.

$ npx create-nx-workspace@latest ngapp 
  --preset=angular-standalone 
  --standaloneApi

Lockfile parsing and pruning

Lockfiles can be highly complex, and different formats across the NPM, Yarn, and PNPM package managers don't make it easier. Nx used to consider the lock-file a black box. Starting with 15.7, this changes! Nx can now properly process the lock-file of all three major package managers (and their different versions!).

Why is this useful? Glad you asked! Mostly for three reasons:

more accurately map the nodes and dependencies in the Nx graph (yep the graph also includes npm packages used by every single project)
generate a package.json with precise snapshot of the used versions (especially useful in a monorepo with single-version policy)
ability to generate a pruned lock-file that can be used along-side the package.json when packaging your app in a Docker container

Some of our plugins' build executors include:

generatePackageJson flag (@nrwl/webpack:webpack and @nrwl/node:webpack) that automatically generates package.json and lock file.
generateLockfile flag (@nrwl/js:swc, @nrwl/js:tsc and @nrwl/next:build) that generates lock file

If you're an Nx plugin developer, you can generate package.json and lock file using the following functions from the @nrwl/devkit package:

import { createPackageJson, createLockFile } from '@nrwl/devkit';

const projectGraph = await createProjectGraphAsync();
const packageJson = createPackageJson(projectName, projectGraph);
const lockFile = createLockFile(packageJson);

// save files using e.g. `fs.writeFileSync`

Stay tuned for a more in-depth blog post coming soon to our blog.

Storybook 7.0 beta support

Nx provides support for Storybook version 7.0 beta, with generators and executors, so that you can try it out now, either in a new or in your existing Nx workspace. Storybook version 7 is a major release that brings a lot of new features and improvements. You can read more about it in the Storybook 7 beta announcement blog post. Apart from the new features and enhancements, it also brings some breaking changes. You can read more about them in the Storybook 7 migration docs and the Storybook 7 migration guide. Do note that version 7 is still in beta, and so is the Nx support for it.

You can try out Storybook 7.0 beta in a new Nx workspace by passing the --storybook7betaConfiguration flag when generating the Storybook configuration for your projects. Read more in our Storybook 7 setup guide. If you want to migrate your existing Storybook configuration to Storybook 7.0 beta, please read our migration guide.

More flexible Webpack config

Previously when you created a new React application with the Nx @nrwl/react plugin, the actual Webpack config was hidden within the plugin itself.

It was for a good reason, but at the same time, it is a thin line to walk between giving more flexibility and ensuring integrity and consistency (not to speak about features such as automated code migrations). We wrote a blog post about it last week.

Inspired by our new Vite setup, which allows for a more modular configuration in the vite.config.ts, we wanted to bring some of the same flexibility to our Webpack setup as well. As such, now every Nx Webpack setup (e.g. a new React + Webpack based app) have a webpack.config.js in the project root. Old project are automatically migrated to this new setup.

If you want to upgrade but still retain the previous behavior, we introduced an isolatedConfig mode that can be set to false. More details on our docs: https://nx.dev/packages/webpack/documents/webpack-config-setup

How to Update Nx

Updating Nx is done with the following command and will update your Nx workspace dependencies and code to the latest version:

npx nx migrate latest

After updating your dependencies, run any necessary migrations.

npx nx migrate --run-migrations

Coming up

We are currently working on some exciting stuff, including

Deno support
Improvements to Nx Console, including support for IntelliJ
NestJS
Rust 👀
Nx for non-JS environments
...

So keep an eye on our Twitter, Youtube and blog to not miss those announcements.

Learn more

Also, if you liked this, click the ❤️ and make sure to follow Juri and Nx on Twitter for more!

#nx Follow

Setup React and Tailwind - The Easy Way

Juri Strumpflohner — Mon, 13 Feb 2023 10:48:16 +0000

Developers love to argue about whether Tailwind is good, almost like arguing about code formatting or tabs vs. spaces (I use spaces!!). But whether you love it or hate it, Tailwind has found massive adoption among the frontend developer community. In fact, I'm right now in the process of refreshing and rebuilding my personal site (it will be at https://juri.dev soon, so keep an eye on that).

1. Prefer a video? I've got you covered!
2. Configuring Tailwind for React
3. There is an easier way - Code Generators
4. Generating a Tailwind Setup
5. That's it!

Prefer a video? I've got you covered!

Configuring Tailwind for React

Tailwind has good docs around getting started quickly. There are options to set up Tailwind with their Tailwind CLI, PostCSS, and framework-specific guides.

These steps mostly involve

installing tailwindcss, postcss and autoprefixer
configuring your tailwind.config.js to make sure Tailwind can properly "purge" its generated CSS file based on the content files (usually your html, [j|t]sx, [t|j]s )
adjusting your main CSS file to include the Tailwind base classes (in case you want to use Tailwind also in your CSS files, a heated topic)

One important thing: if you use Create-React-App you might want to check out what the Tailwind docs say first.

This came up a couple of weeks ago due to a PR opened on the CRA repo asking to kinda deprecate it as the main choice for new React projects. I couldn't help but share my opinion on this as well:

And so did also Fireship and ultimately Dan Abramov. Anyway, if you're in the "CRA situation", read on. There's a way to get unblocked there.

There is an easier way - Code Generators

Code generators speed up such configuration tasks. They are valuable for scaffolding the initial project structure and adding new features to the app setup, such as Tailwind.

Nx has such generators. To use them, you need an Nx-based React setup. If you're starting new, you can create an Nx Standalone React project easily using the following command

$ npx create-nx-workspace reactapp --preset=react-standalone

As you can see, this allows you to choose which bundler to use as well as other options (such as the CSS setup). Again, this is already such a code generator that creates this initial project scaffold.

Alternatively, if you happen to use CRA already, you can easily convert to an Nx and Vite (or also Webpack) based setup by running:

$ npx nx@latest init

You can pass --vite=false if you still want to keep the Webpack configuration or pass --integrated if you already plan to have a monorepo instead of a single-project setup. The Nx docs go into more detail here.

Generating a Tailwind Setup

Once you have a Nx-based React setup, adding Tailwind is as easy as running:

$ npx nx g @nrwl/react:setup-tailwind

This launches a generator that will guide you through the setup. It works not only for Nx React-based projects, but also if you use Next.js in an Nx workspace.

You'll get

Tailwind, PostCSS, and Autoprefixer installed
Tailwind configured together with PostCSS
your main styles.css file updated with the Tailwind base classes

That's it!

You should be all setup and ready now! Here are some related resources to explore:

Learn more

Also, if you liked this, click the ❤️ and make sure to follow Juri and Nx on Twitter for more!

#nx Follow

React, Vite and TypeScript: Get started in under 2 minutes

Juri Strumpflohner — Thu, 12 Jan 2023 15:48:24 +0000

Let's be honest. Dealing with tooling is not something enjoyable if you have to deliver code. It should just work and not be in the way. So let's explore how to kickstart your next React project using Vite, in under 2 minutes, without worrying about the setup.

1. How do I create a new project setup?
2. Running, building and testing the app
3. Building the app
4. Testing the app
5. Running integration tests with Cypress
6. Linting
7. Customize Vite and Vitest
8. Hidden gem: Caching
9. Hidden gem: Easily modularize your app
10. Hidden gem: Visualize your architecture
11. Hidden gem: Guard your boundaries
12. Hidden gem: Just run what changed
13. Hidden gem: A dedicated Editor extension
14. Hidden gem: Automated Upgrades
15. Using CRA? Automatically migrate to Vite + Nx
16. Conclusion
17. Learn more

Traditionally, you might lean towards Create-React-App (CRA) started to do precisely that. But what if I told you there's a better alternative, providing

not just scaffolding for the initial setup but helping you along the way to generate components, routing, etc
automatically sets you up with best practices tools for e2e testing, unit testing, code formatting, and linting
has built-in support for Vite and Vitest (alternatively Webpack & Jest)
caches your scripts to speed up things
helps you modularize your application
comes with automated upgrade features to keep your tooling evergreen

I'm talking about Nx. Nx comes with a set of plugins that come with code generation abilities and help abstract some of the lower-level tooling setups. And this can be really interesting for the use case we wanna tackle today.

Reader: "Wait a minute, I heard about Nx. Isn't that for monorepos?"
Me: "Yeah you're right. But in 15.3 they introduced something called 'standalone apps'"
Reader: "Standalone?"
Me: "Yeah, a fancy term for a setting up a single app and allows for some cool modularization. There's a video introducing that feature here: https://youtu.be/qEaVzh-oBBc"
Reader: "ha, interesting 🤔"

So let's go and set up our React + Vite + TypeScript project.

How do I create a new project setup?

To set up a new project, just invoke the following command:

npx create-nx-workspace@latest awesomereactapp --preset=react-standalone

Note awesomereactapp is the name of the app and folder being created, and --preset=react-standalone tells Nx which template to use when scaffolding the initial setup. You can also invoke it like:

npx create-nx-workspace@latest awesomereactapp

And then choose the option you prefer in the terminal prompt:

In the end, what you'll get is the following structure:

Running, building and testing the app

First off, let's run our new, shiny application. Just invoke

npm start

And in a matter of milliseconds, your app should be served at http://localhost:4200/.

npm start just invokes the script defined in the package.json:

// package.json
{
  "name": "awesomereactapp",
  ...
  "scripts": {
    "start": "nx serve",
    "build": "nx build",
    "test": "nx test"
  }
  ...
}

Internally this delegates to nx serve, where serve is the Nx target to be invoked. You can find those in the project.json:

// project.json
{
  "name": "awesomereactapp",
  "$schema": "node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "./src",
  "projectType": "application",
  "targets": {
    "build":  {...},
    "serve": {
      "executor": "@nrwl/vite:dev-server",
      "defaultConfiguration": "development",
      "options": {
        "buildTarget": "awesomereactapp:build"
      },
      "configurations": {
        "development": {
          "buildTarget": "awesomereactapp:build:development",
          "hmr": true
        },
        "production": {
          "buildTarget": "awesomereactapp:build:production",
          "hmr": false
        }
      }
    },
    "test": {...},
    "lint": {...}
  },
  "tags": []
}

This is where you can see all the targets available for a given project, and you can add your own! In a Nutshell, an Nx target contains

executor - a function (here dev-server) exposed by the plugin (here @nrwl/vite) to run the task at hand. Think of it as the wrapper of your usual Npm scripts
options - this is where you can pass options to the executor
configurations - allows you to create different versions of the options . You control which configuration is used by passing it via the --configuration=production flag to your commands. Also, note the defaultConfiguration.

You can go more in-depth if you want on the Nx docs.

Building the app

Just in the same way as serving our web app, we can build it with

npx nx build

This places an output into a dist folder. Now that we've seen the project.json targets, you probably guessed that you could customize that output folder directly in those settings.

Testing the app

This setup also comes with testing baked in using Vitest. And you probably guessed it, you can just run tests as follows:

npx nx test

Running integration tests with Cypress

You might have noticed the e2e folder. That's a fully-functioning setup of Cypress for doing integration-level or even full end-to-end tests.

This is excellent because you don't have to configure anything at all. No need to

Cypress configured to use Vite (instead of Webpack)
set up linting for the e2e project (yes writing good quality test code is just as important)
spinning up our development server manually first that serves our React app such that we can load it in our Cypress tests environment

All we need to do is to use

npx nx e2e e2e

This might look weird initially, but basically, we run the e2e target (see e2e/project.json) on the e2e project.

// e2e/project.json
{
  "name": "e2e",
  "$schema": "../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "e2e/src",
  "projectType": "application",
  "targets": {
    "e2e": {
      "executor": "@nrwl/cypress:cypress",
      "options": {
        "cypressConfig": "e2e/cypress.config.ts",
        "devServerTarget": "awesomereactapp:serve:development",
        "testingType": "e2e"
      },
      "configurations": {
        "production": {
          "devServerTarget": "awesomereactapp:serve:production"
        }
      }
    },
    ...
  }
}

By default, these tests run in headless mode, but you can pass --watch to run it interactively with the Cypress test runner such that the tests get re-executed whenever we change our source.

Want Cypress Component testing? There's an Nx generator that can help set that up. Check out the docs: https://nx.dev/packages/react/generators/cypress-component-configuration

Linting

And similarly, linting can be triggered by running the following command:

npx nx lint

There's a .eslintrc.json file already at the workspace's root that contains some best practices rules.

Customize Vite and Vitest

The project setup is made in a way that you can easily customize your Vite and Vitest setup. Just open the pre-generated vite.config.ts at the root of your workspace and add custom Vite plugins or fine-tune Vitest.

/// <reference types="vitest" />
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import viteTsConfigPaths from 'vite-tsconfig-paths';

export default defineConfig({
  server: {
    port: 4200,
    host: 'localhost',
  },
  plugins: [
    react(),
    viteTsConfigPaths({
      root: './',
    }),
  ],

  // vitest config
  test: {
    globals: true,
    cache: {
      dir: './node_modules/.vitest',
    },
    environment: 'jsdom',
    include: ['src/**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}'],
  },
});

Hidden gem: Caching

Nx is known for its caching that helps optimize the speed in monorepos. Caching takes the inputs (the command, source files, environment variables...) and computes a hash.

On every run, Nx compares that hash against a local cache folder. If the hash exists, Nx restores the command line output and potential artifacts (JS, CSS,... files) produced by a previous run. This helps speed up computation because you don't run it if you don't need to.

See Nx the docs for more info: https://nx.dev/concepts/how-caching-works

While this obviously makes a lot of sense in a monorepo, it can also help speed up single-project workspaces. Most projects have multiple targets, such as build, test, lint. These can be cached! Imagine you have a PR where you change some *.spec.ts files because you add a test or fix some. Your CI script probably runs all the targets (build, test, lint) all the time. And it should totally do that. But you could avoid the build step because your spec file should not influence that outcome. As such, it could be restored from the cache. test needs to run and potentially also lint if you run linting also for spec files.

You can fine-tune what goes into the cache for each command. More on the Nx docs

Hidden gem: Easily modularize your app

Imagine a storefront application. You will probably have domain areas like

Product list - which would have facilities for listing all currently available products, their ratings, user reviews etc
Orders - for viewing your currently open orders as a user or browsing past orders. Things like placing a new order or triggering a refund on a previously acquired product
Payments - for handling the payment flow, asking for the credit card, triggering the payment, and starting the order placement process once the payment is successful
Authentication - which handles the whole signup/login flow and provides lower-level utilities for other domain areas in the app, like getting access to the current user.
User Profile - which manages everything user related. Think of it when you access Amazon and go to your account. Things like managing your addresses
...

We're just scratching the surface here. This can become big quickly. The only way to manage such a structure with the current tooling (including CRA) is to organize these domains in folders. So you'd have something like this in a CRA setup:

cra-app
  ├─ public/
  ├─ src/
  │   ├─ authentication/
  │   │  ├─ current-user/
  │   │  │   ├─ ...
  │   │  │   └─ index.ts
  │   │  ├─ login/
  │   │  └─ signup/
  │   ├─ orders/
  │   │   ├─ checkout/
  │   │   ├─ place-order/
  │   │   ├─ refund/
  │   │   └─ order-list/
  │   ├─ payments/
  │   ├─ products/
  │   ├─ user-profile/
  │   │   ├─ addresses/
  │   │   └─ credit-cards/
  │   ├─ App.css
  │   ├─ App.tsx
  │   ...
  ├─ package-lock.json
  ├─ package.json 
  └─ README.md

Most devtools (including CRA) force you into a monolithic structure, where you divide your features into folders. Folders are limited in terms of isolation, though; as your application grows, this might quickly go out of hand.

We can impose a different, stronger structure with Nx by extracting these areas into dedicated libraries or modules. These live side-by-side with your application. Let's say we have a folder named "domains" which contains these domain areas. Then you can easily generate a new library with the following command:

npx nx g @nrwl/react:lib checkout --directory=domains/orders/checkout --bundler=none

The above command creates a new " checkout " library in the domains/orders/ folder. Here's what it looks like:

awesomereactapp
├─ public
│  └─ favicon.ico
├─ src
│  ├─ app
│  ├─ ...
├─ domains
│  └─ orders
│     └─ checkout
│        ├─ src
│        │  ├─ index.ts
│        │  └─ lib
│        │     ├─ domains-orders-checkout.module.css
│        │     ├─ domains-orders-checkout.spec.tsx
│        │     └─ domains-orders-checkout.tsx
│        ├─ tsconfig.json
│        ├─ tsconfig.lib.json
│        ├─ tsconfig.spec.json
│        └─ vite.config.ts
├─ ... 
├─ index.html
├─ package-lock.json
├─ package.json
├─ ...
├─ tsconfig.app.json
├─ tsconfig.base.json
├─ tsconfig.json
├─ tsconfig.spec.json
└─ vite.config.ts

Notice the domains/orders/checkout/src/index.ts: this is the public API of the checkout library where you can decide what to export and what should remain private within the library. This conscious process of selecting what to expose and what not leads to a much stronger encapsulation than just a folder structure. It also greatly helps with the maintainability aspect as your app grows.

When generating the library, a TypeScript path mapping is automatically created in the root-level tsconfig.base.json:

{
  "compileOnSave": false,
  "compilerOptions": {
    ...
    "paths": {
      "@awesomereactapp/domains/orders/checkout": [
        "domains/orders/checkout/src/index.ts"
      ]
    }
  },
  "exclude": ["node_modules", "tmp"]
}

In this way, anything that's being exported from the checkout library can be consumed like

import { SomeComponent } from '@awesomereactapp/domains/orders/checkout';

You can also just run linting or testing in isolation for these new libraries:

npx nx test domains-orders-checkout

And obviously, caching (as seen previously) would work on these new libraries as well.

Note, domains-orders-checkout is the unique name of the project, composed by its file structure. You can change the name in the domains/orders/checkout/project.json if you'd like.

Hidden gem: Visualize your architecture

Another side-effect of splitting up your codebase into libraries is that your code structure and architecture emerge and becomes visible. Nx comes with a graph command built-in, so you can even visualize it:

npx nx graph

It becomes even more interesting if you select the "Group by folder" checkbox as the domains become visible at that point:

Note this is a hypothetical app to demo some of the features of the Nx graph visualization. Some of the connections might only make a little sense.

Hidden gem: Guard your boundaries

Scaling a software product is more than just the initial structuring and modularization. It consists of a constant ongoing process of ensuring modules stay in shape and don't contain any undesired cross-references or circular dependencies. You could leverage the Nx graph to verify that visually, but that doesn't scale.

To help with that, Nx has a built-in module boundary lint rule. Projects can be assigned "tags", like type:domain, type:utils, type:shared and domain:products, domain:orders, domain:auth. These tags can be assigned in the project.json, like

// 
{
  // ... more project configuration here
  "tags": ["domain:products", "type:domain"]
}

Note that type:domain or domain:products are really just strings. You can define them however you want.

In the .eslintrc.base.json you can then define the rules. Here for instance we're stating that a library of type:utils can only depend on other utility libraries, while a type:domain can depend on both, other domain libraries as well as utility libraries.

// .eslintrc.base.json
{
  "overrides": [
    {
      "rules": {
        "@nrwl/nx/enforce-module-boundaries": [
          "error",
          {
            "depConstraints": [
              {
                "sourceTag": "type:utils",
                "onlyDependOnLibsWithTags": ["type:utils"]
              },
              {
                "sourceTag": "type:domain",
                "onlyDependOnLibsWithTags": ["type: domain", "type:utils"]
              },
              {
                "sourceTag": "domain:products",
                "onlyDependOnLibsWithTags": ["domain:products", "domain:orders"]
              }
            ]
          }
        ]
      }
    }
  ]
}

If some of these lint rules need to be followed, your editor will show it right in your code, and you can also run lint checks for each PR on CI.

If you're curious, you can read more here: https://blog.nrwl.io/mastering-the-project-boundaries-in-nx-f095852f5bf4

Hidden gem: Just run what changed

In such a modular structure (as shown above) where your code is organized in smaller modules/libraries, it is very common that a given team member just works within a single domain area. Hence, very often PRs just touch a subset of the entire set of libraries. Nx comes with a backed-in command that allows you to take advantage of that on CI, using the so-called "affected commands".

Let's say we make a change in the product-detail library of our application. This would affect all other libraries that depend on it. You can also visualize it by running

npx nx affected:graph

To run tasks only for the affected areas, use:

npx nx affected:<target>

To make a concrete example, running just tests for those projects:

npx nx affected:test

Hidden gem: A dedicated Editor extension

If you are not the "command line interface type" developer and you'd rather prefer something integrated within your IDE, then there's good news. The Nx core team also ships a dedicated VSCode extension: Nx Console.

It has a dedicated view within VSCode to trigger common commands, browse the workspace structure and even inline render the graph.

It also comes with contextual menus to quickly access most of the commonly used functionality:

Here's a walkthrough video showing some of the powerful capabilities of Nx Console:

Hidden gem: Automated Upgrades

To keep workspaces evergreen, Nx comes with automated code migrations that

upgrade your package.json packages to the next version
can automatically update your configuration files if necessary
can automatically update your source files if necessary (in case of breaking changes in the API)

This allows for smooth transitions even if there are breaking changes. Just run

npx nx migrate latest

Nx gathers the currently installed packages and updates them to the latest version. If a package comes with Nx migration scripts, Nx collects them in a migrations.json file. You can inspect and then run them. This dramatically helps to keep your project tooling up to date.

Read more about how Nx migrations work on the docs.

Using CRA? Automatically migrate to Vite + Nx

If you're currently on a CRA setup, you can easily migrate to an Nx + React + Vite-based setup by running the following command in your CRA project:

npx nx init

Read more on the Nx docs: https://nx.dev/recipes/adopting-nx/migration-cra

If for some reason you cannot migrate to Vite just yet, you can pass --vite=false to keep a Webpack-based setup for now.

Conclusion

Ready? Give it a try:

npx create-nx-workspace mycoolapp --preset=react-standalone

And let us know what you think :)

Learn more

🧠 Nx Docs
👩‍💻 Nx GitHub
💬 Nrwl Community Slack
📹 Nrwl Youtube Channel
🥚 Free Egghead course
🧐 Need help with Angular, React, Monorepos, Lerna or Nx? Talk to us 😃

Also, if you liked this, click the ❤️ and make sure to follow Juri and Nx on Twitter for more!

#nx Follow

Reflecting on 2022 - The Year in Review

Juri Strumpflohner — Thu, 29 Dec 2022 18:55:22 +0000

As clichéd as it is to start a "year in review" post by stating how exciting the year has been... 2022 was an exciting year for Nx! In 2022 we've seen amazing growth in Nx usage, and in the community, we hosted our first in-person event and received our first round of funding so we can focus our efforts on making Nx and Nx Cloud better than ever.

Here are some 2022 highlights.

Launching monorepo.tools

At the beginning of 2022, we saw a significant increase in the interest in monorepos, especially in the JavaScript community. Since we had a couple of years of experience in the area, we decided to launch monorepo.tools.

We wanted to make this a place where interested developers can go to get a high-level overview of what a monorepo is about, what features you should be looking for and what tools are available.

Although we kick-started the page, we reached out to all the mentioned monorepo tool maintainers and got some really good feedback and complete PRs to add new tools.

From 1 to 3 Million Weekly Downloads

The popularity of Nx exploded in 2022. We were at 1 million weekly downloads in January 2022, crossed 2 million by end of June, and, as this year comes to a close, we've exceeded 3 million! It's incredible to see such an adoption rate, but it very much motivates us to continue our path.

Nrwl takes over Stewardship of Lerna

Lerna has been around for a long time, and it was actually the first proper solution for implementing JavaScript-based monorepos. Long before NPM/Yarn/PNPM workspaces were a thing. Lerna allowed to easily link packages locally and had first-class support for versioning and publishing monorepo packages.

Around the summer of 2020 Lerna's development got slower and was mainly on the shoulders of a single developer, doing it in his free time. Lerna was in maintenance mode. At Nx, we added an easy transition with an automated migration script. It was only later around March 2022, that someone merged a PR stating in big letters that Lerna is deprecated and people should migrate to an alternative. Still, Lerna is pretty popular at 1.5 million downloads/week on NPM and developers loved the automated versioning and publishing flow.

We wanted to keep Lerna alive and reached out to its core maintainer Daniel Stockman and offered to move it forward. Nx has been open source since the beginning which gives us a lot of experience in managing projects in the open. Furthermore, Nx was already closely aligned with Lerna's functionality (with Lerna providing the added benefit of automated versioning and publishing). And obviously, we saw the potential of being able to easily modernize Lerna with features such as caching. So we did it! If you're curious, we wrote an in-depth blog post about it.

Since then,

we released Lerna v5
we completely redesigned both the website and docs at https://lerna.js.org
we released Lerna v6
and made upgrading a no-brainer

Nx Conf Lite and our first in-person Nx Conf

This year we hosted two events featuring members of the Nx Team and community: Nx Conf Lite, an online mini-conference held in the spring; and Nx Conf, in-person, in Arizona, this past fall.

Both were a huge success, and we had some fantastic in-depth talks around Nx, Lerna, monorepos and developer tooling. You can check out the recordings here:

Nx Funding and New Focus on Product Development

Nrwl, the company behind Nx, is fully bootstrapped. Our work is divided into roughly 80% consulting for some of the biggest companies in the world and 20% open source work on Nx and Nx Cloud.

Seeing the traction Nx got in 2022, we wanted to invest more and hence in November 2022 we raised the first round of funding of $8.6 million.

This allows us to work mostly full-time on improving Nx and Nx Cloud. And you can see that effect already in our latest 15.3 and 15.4 releases (continue reading for that).

Here's our official fundraising announcement blog post.

Epic Releases

We had some epic releases this year. Want to get a feel for it? Just have a look at our latest Nx 15.3 and Nx 15.4 releases.

Here's some more:

Improved docs - Documentation is hard but extremely important. We invested and kept investing a lot of time in optimizing how we structure our docs to serve newcomers and expert users alike.
Speed - we drastically improved the speed of Nx, making it the fastest monorepo solution in the frontend space.
Improved terminal output - It might not sound as important. But if you run a command in a monorepo it usually involves running it for potentially hundreds of projects. A decent visualization of what's relevant can make a huge difference.
Local plugins - Making Nx extensible has been a key for our community adoption. But Nx plugins go beyond and can be useful even for just automating a local Nx workspace without publishing the plugin to some public registry. Check out our docs for local plugins
Built-in Module Federation - We added some pretty cool support for working with Webpack module federation. That includes migrating an existing Angular or React app to MF and generating new ones, including SSR support. Explore our docs for more details
Massive improvements on Nx Console - Nx Console exceeded 1 million installations but also experienced some huge improvements. You can now visualize the graph from within VSCode, autocompletion for config files and even use it with your Lerna workspace.
Packaged-based and Integrated repositories - There are different styles of monorepos: package-based and integrated. Nx has been strong with integrated monorepos since the beginning. This year we made Nx a first-class citizen for package-based monorepos as well. Check out the blog post on how to add Nx to a PNPM workspace monorepo.
Easy migration - We made migrating to Nx is as easy as running nx init. Regardless of whether you want to add Nx to an existing monorepo, migrating from CRA, the Angular CLI or even a non-monorepo project. More here
Standalone apps support - Nx's powerful generators, executors and ability to modularize a large codebase are not only valuable for a monorepo scenario. That's the main driver why in Nx 15.3 we introduced "standalone apps". Here's a short video walkthrough: https://youtu.be/qEaVzh-oBBc
Vite support - The Vite community is growing fast, and many of our users asked for an Nx plugin coming from the core team. Even though you could use Nx in a package-based monorepo with Vite already, we wanted to make it the best experience for developing React applications with Nx and beyond. Check out our Vite docs for all the details.
Nx Watch - Watching for changes in a monorepo (especially package-based) can be tricky or require some weird hacks involving 3rd-party packages. In Nx 15.4 we added a native nx watch command. See the docs.

And these are just some of the highlights. Want all the details? Check out our release blog posts: https://blog.nrwl.io/changelog/home

Things to look forward to in 2023

We have some huge plans for 2023 for Nx, Nx Cloud, Lerna, and beyond. Let's make 2023 even more epic than 2022 has been 😉.

Make sure you follow us on our socials not to miss anything. We are on Twitter, LinkedIn, Youtube, TikTok, our blog and dev.to.

Learn more

Also, if you liked this, click the ❤️ and make sure to follow Juri and Nx on Twitter for more!