---
title: Manage Your Gradle Project using Nx
authors: ['Emily Xiong']
cover_image: '/blog/images/2024-04-19/featured_img.png'
tags: [nx, gradle, how-to]
---

Here’s my situation: I have a Gradle workspace with multiple Gradle libraries. How do I easily view the relationships between different libraries? I have a monorepo workspace with both Gradle and Javascript libraries, how do I manage these libraries of different tech stacks?

We are very excited to announce our support for Gradle with our new plugin: `@nx/gradle`.

The Nx Gradle plugin registers Gradle projects in your Nx workspace. It allows Gradle tasks to be run through Nx. Nx effortlessly makes your [CI faster](/ci/intro/ci-with-nx).

> **Note:** this plugin is currently experimental.

This blog will show you:

- [What is Nx?](#what-is-nx)
- [How to add Nx to a Gradle workspace](#how-to-add-nx-to-a-gradle-workspace)
- [How to add @nx/gradle to an existing Nx workspace](#how-to-add-nxgradle-to-an-existing-nx-workspace)

---

## What is Nx?

Before we start, let’s answer this question: what is Nx and why should we use it?

From [nx.dev](https://nx.dev): “Nx is a build system with built-in tooling and advanced CI capabilities. It helps you maintain and scale monorepos, both locally and on CI.” It sounds good, what benefits does it bring?

Nx adds the following features to your workspace:

- [Cache task results](/features/cache-task-results): By storing task outputs in a cache, subsequent runs can skip redundant computations and reuse previously calculated results, significantly speeding up build processes. Nx intelligently manages this caching mechanism, invalidating the cache automatically when relevant inputs change.
- [Distribute task execution](/ci/features/distribute-task-execution): Nx CI efficiently distributes tasks across multiple machines for faster build times. It uses a distributed task execution algorithm to intelligently divide and assign tasks to available resources, minimizing redundant work and maximizing parallelism.
- [Run only tasks affected by a PR](/ci/features/affected): Nx identifies changes made since a specified base commit or branch, and then selectively runs tasks (like tests, linting, or builds) related to those changes.
- [Interactively explore your workspace](/features/explore-graph): Nx allows developers to visualize and understand the dependencies and relationships within their projects.

![Example Nx Graph](/blog/images/2024-04-19/bodyimg1.webp)

---

## How to add Nx to a Gradle Workspace?

Now we understand the benefits of Nx, now let’s set it up. The setup is pretty easy, just need to run one command.

In the workspace, run the below command:

```shell
npx nx@latest init
```

In the terminal, it should output:

```shell
Setting Nx up installation in `.nx`. You can run Nx commands like: `./nx --help`
CREATE nx.json
UPDATE .gitignore
CREATE .nx/nxw.js
CREATE nx.bat
CREATE nx

 NX   Recommended Plugins:

Add these Nx plugins to integrate with the tools used in your workspace.

✔ Which plugins would you like to add? Press <Space> to select and <Enter> to submit. · @nx/gradle


added 111 packages, and audited 112 packages in 2s

21 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

✔ Installing @nx/gradle@latest...
✔ Initializing @nx/gradle...
```

That’s it! Now we have Nx in our Gradle project.

### Example: Gradle Init

If you create your Gradle workspace using gradle init, by running `npx nx@latest init`, you will get:

![](/blog/images/2024-04-19/bodyimg2.webp)

It adds a .nx folder in the workspace root and nx executable files. Now you can run commands using ./nx (or nx.bat for Windows machines).

For example, you can run Gradle tasks using Nx now:

```shell
# macos/linux
./nx <gradle task> <gradle project>

# windows
nx.bat <gradle task> <gradle project>
```

If you build your Gradle library using the command `./gradlew :app:build` or `gradlew.bat :app:build`, you can run `./nx build app` or `nx.bat build app` to build your Gradle library.

Now you can an alternative way to run Gradle tasks, how can we leverage Nx?

### Nx Graph

To see the project graph, run the below command:

```shell
# macos/linux
./nx graph

# windows
nx.bat graph
```

![](/blog/images/2024-04-19/bodyimg3.webp)

### Run Only Tasks Affected by a PR

As mentioned before, Nx enables the ability to run only the tasks affected by a specific PR by running the below command:

```shell
# macos/linux
./nx affected -t <task>

# windows
nx.bat affected -t <task>
```

For example, when you run `nx affected -t build`, Nx uses your git information to determine the files you changed in your PR. Nx determines the list of projects in the workspace that can be affected by this change and only runs the build task against changed files.

You can also visualize the affected projects highlighted using the [Nx graph](/features/explore-graph). Simply run:

```shell
# macos/linux
./nx affected:graph

# windows
nx.bat affected:graph
```

### Nx Console

Furthermore, instead of running the command in terminal, you can use the editor tool [Nx Console](/getting-started/editor-setup). Anything you can do with Nx, you can do with Nx Console.

![Screencap of Nx Console UI](/blog/images/2024-04-19/bodyimg4.webp)

To download:

- [**Nx Console - Visual Studio Marketplace**](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
- [**Nx Console - IntelliJ IDEs Plugin | Marketplace**](https://plugins.jetbrains.com/plugin/21060-nx-console)

---

## How to add @nx/gradle to an existing Nx workspace?

If you have an existing Nx workspace, to add `@nx/gradle`, just run:

```shell
npx nx add @nx/gradle
```

That is it, it will add `@nx/gradle` plugin to your Nx workspace.

You can view inferred tasks for Gradle project in your workspace, open the [project details view](/features/explore-graph#explore-projects-in-your-workspace) in Nx Console or run `nx show project my-project --web` in the command line.

For all the interred tasks, you can run using Nx instead of Gradle:

```shell
nx <gradle task> <gradle project> [options]
```

For example, if you run `./gradlew :app:build` or `gradlew.bat :app:build` using Gradle command, to run using Nx: `nx build app`.

### How @nx/gradle Infers Tasks

The `@nx/gradle` plugin will create an Nx project for each Gradle configuration file present. Any of the following files will be recognized as a Gradle configuration file:

- `gradle.build`
- `gradle.build.kts`

### @nx/gradle Configuration

The `@nx/gradle` is configured in the plugins array in `nx.json`:

```json {% fileName="nx.json" %}
{
  "plugins": [
    {
      "plugin": "@nx/gradle",
      "options": {
        "testTargetName": "test",
        "classesTargetName": "classes",
        "buildTargetName": "build"
      }
    }
  ]
}
```

Once a Gradle configuration file has been identified, the targets are created with the name you specify under `testTargetName`, `classesTargetName`, or `buildTargetName` in the `nx.json` plugins array. The default names for the inferred targets are `test`, `classes`, and `build`.

---

## Summary

Here is how to set up Nx with the Gradle workspace. Hopefully, this gives you a good insight into how to get started with Gradle with Nx. The plugin is currently experimental, you can submit GitHub issues: [https://github.com/nrwl/nx/issues](https://github.com/nrwl/nx/issues).

---

## Learn more

- [Nx Docs](/getting-started/intro)
- [X/Twitter](https://twitter.com/nxdevtools) -- [LinkedIn](https://www.linkedin.com/company/nrwl/)
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](/community)
- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- [Speed up your CI](https://nx.app/)


Manage Your Gradle Project using Nx

---
title: Reliable CI. A new execution model fixing both flakiness and slowness
authors: [Victor Savkin]
cover_image: '/blog/images/2024-03-21/featured_img.png'
tags: [nx, nx-cloud, releases]
---

The proverbial slow and flaky CI isn’t the failure of the developers or even the testing tools. It’s the failure of the CI execution model we relied on for the last 20 years.

**By switching from the old CI model, implemented as a graph of VMs, to the new one, implemented as a graph of tasks, we can solve both the flakiness and slowness.**

In this blog post I’ll explore why this is the case, and how you can do it by using Nx Cloud.

---

## History of CI

It’s easy to forget that Continuous Integration has been around for only 20 years. For reference, UI frameworks have been around since the 1970s.

![](/blog/images/2024-03-21/bodyimg1.webp)

The innovation in the CI space has been primarily in where the CI process is described and how the configuration is written. How the CI actually works has largely remained the same.

## How CI works

A traditional CI execution is a directed acyclic graph (DAG) of virtual machines (VMs). Each VM (often called a job) installs dependencies, restores NPM cache, and then runs the necessary steps to verify that, say, some tests pass.

![](/blog/images/2024-03-21/bodyimg2.webp)

**This CI execution is a distributed process, and a poorly designed one. It works reasonably well only when the number of jobs/VMs is very small and falls apart when the number gets larger.**

---

## Why does the current system not work?

**Every distributed system needs efficient communication between nodes and the ability to tolerate failure.**

The traditional CI execution model offers **very basic** means of communication: the status code propagation and ad-hoc ways of uploading/downloading files. Because the communication is effortful, in practice, **it’s either not done at all or very minimally.**

To understand why the traditional CI execution model fails to handle failures, let’s review the types of failures we can have.

Failures can be:

- hard _(npm fails to install, nothing can run)_
- soft _(a test takes a lot longer than it should because, perhaps, due to an out-of-memory issue)_

Focusing on the latter is just as important as focusing on the former. **Slow CI is broken CI.**

Tasks can fail:

- legitimately _(a broken build)_
- for external reasons _(npm install fails cause npm is down)_
- for unknown reasons _(a flaky test)_

**The traditional CI execution model doesn’t tolerate any of these failures.**

## Problem in numbers

Let’s see how varying a few parameters affects the probability of the CI execution failing.

| Number of VMS | Avg Tests per VM | Flaky Test Probability | Slow Test Probability | Broken CI Builds (Flaky) | Slow CI Builds |
| ------------- | ---------------- | ---------------------- | --------------------- | ------------------------ | -------------- |
| 5             | 10               | 0.1%                   | 0.3%                  | 5%                       | 15%            |
| 10            | 10               | 0.1%                   | 0.3%                  | 10%                      | 26%            |
| 50            | 10               | 0.1%                   | 0.3%                  | 39%                      | 78%            |
| 5             | 10               | 0.5%                   | 1%                    | 23%                      | 41%            |
| 10            | 10               | 0.5%                   | 1%                    | 40%                      | 65%            |
| 50            | 10               | 0.5%                   | 1%                    | 92%                      | 99%            |

**The result is much worse than most intuitively expect.** For instance, assuming that an **e2e test has 1 in 1000 chance (0.1%) of failing** for a flaky reason, when the number of e2e tests reaches 500, **the probability of the CI failing for a flaky reason reaches 39%**, and the vast majority of CI executions are slowed down. Note, this is an exceptionally stable test suite. The bottom part of the table is more representative of a typical e2e suite, and the CI becomes “broken” at a much smaller scale.

One can try to fix it by increasing the robustness of the tests, but at some point, doing this is costly. If an e2e test has a 10% chance of a flaky failure, it’s relatively easy to bring this number to 1%. Going from 1% to 0.5% is harder. Going from 0.5% to 0.1% is exceptionally hard and may be practically impossible. Testing complex systems is simply a difficult task.

This is the formula for the failed CI run:

![100 * (1 - chanceThatTestRunsWithoutFlakes ^ (avgTestsPerVm * numberOfVms))](/blog/images/2024-03-21/bodyimg3.webp)

**As you can see, as the number of tests grows, the exponent will make more and more CI executions fail for flaky reasons. In this model, the only way to combat it is by increasing $chanceThatTestRunsWithoutFlakes$, but the more tests you have, the more challenging this becomes.** That's why a lot of projects move away from e2e tests or run them nightly (where they always fail).

**It's not the team's fault. It's simply a losing battle with the current CI execution model.**

We focused on the tests but the issue is more general.

VMs sometimes fail to execute their setup steps (e.g., some package fails to install), and in this model it results in a failed CI execution.

One of the setup steps can take a lot longer. Because the probabilities multiply, when the number of agents is high enough, this will happen frequently and will slow down a large number of CI executions. This is the formula for this case:

![100 * (1 - chanceSetupIsFast ^ numberOfVms)](/blog/images/2024-03-21/bodyimg4.webp)

For instance, with 50 agents, if there is a **1% chance that NPM install will take an extra 5 minutes, 40% of CI executions will be affected by it**, and your CI execution time goes from, say, **20m to 25m**. The slowness doesn't amortize across agents.

---

## Solution: Change the model

**There is only that much gain to be had by optimizing the effectiveness and robustness of small units. Instead, we should focus on creating the systems we can use to achieve incredible performance and resilience with ordinary small units.**

The CI model above has a fundamental problem: it is static. It defines a fixed number of VM, where each has a unique job to do. The VMs aren't interchangeable. If one of them fails or is slow, no other VM can help it.

Nx Cloud introduces an entirely different model. Instead of the graph of VMs, the CI execution is expressed as a graph of tasks.

By adding the following line…

```shell
npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js"
```

... you are telling Nx Cloud to create five Nx Agents to execute all the tasks from all the commands that will follow.

![](/blog/images/2024-03-21/bodyimg5.webp)

**Nx Agents** are essentially VMs, but they are different from the ones in the traditional CI execution model.

You can imagine the **traditional CI** model as a team where every member is given a **unique set of tasks.** If a team member gets sick, their work won't be completed, and the **CI execution will fail.** If a team member is slow, **no one can help them.** Everyone will just have to wait for them to complete their assignment.

The **Nx Agent model** is a team where the **work doesn't get assigned ahead of time.** Instead, there is a pile of work in the middle of the room, and every **team member can take any piece of work** and do it. Once they are done with one piece of work, they can take another one. If a member gets sick, **a slightly smaller team can complete the job.** If a member is **slow**, the **other members will split the work.** In practice, it is even better than this. If an Nx Agent fails, another one will be started in its place.

![](/blog/images/2024-03-21/bodyimg6.webp)

## Solution in numbers

Let's examine the two cases above.

First, `npm install` **failing will not break the build.** Nx Cloud will simply spawn another Nx Agent in its place.

The slowness of the `npm install` will affect the CI execution but in a very different way because it will be **amortized across agents.** So with 50 agents executing, adding 5 minutes to an `npm install` of one of the agents, will only increase the CI execution time by 6 seconds _(5 _ 60 / 50)\*.

Second, **[Nx Cloud knows what specific tests are flaky](/ci/features/flaky-tasks), and if they fail, it will rerun them on a separate agent.** Rerunning them on a separate agent is crucial. Often flaky failures will continue to fail when rerun on the same agent.

This is the formula:

![chanceThatTestRunsWithoutFlakesUsingNx = 1 - (1 - chanceThatTestRunsWithoutFlakes) ^ numberOfTries](/blog/images/2024-03-21/bodyimg7.webp)

If we examine the case above, where the test flaky happened 1 in 1000, two retries will result in _1 - (1–0.999)^3^ = 0.999999999_, which **brings the likelihood of the CI failing for a flaky reason to 0.000005%.**

**The Nx Cloud model handles both hard and soft failures. Your agents can crush or be slow - doesn't matter. Your tests can fail or be slow - doesn't matter. Your CI will complete fast.**

---

## Can we fix the traditional model?

It's possible to make the traditional CI model more reliable but the solution isn't adequate for large workspaces.

For instance, in principle, it is possible to add retrying logic to every CI step. It's cumbersome and widely-used CI steps (e.g., popular Github Actions) don't do it. But even if you manage to wrap every step, this isn't bulletproof because many failures are unrecoverable.

**Slow setup steps simply cannot be fixed or amortized.**

One can add rerunning the same e2e test multiple times on the same machine to deal with flakes but there are numerous problems with this.

**One of the most common reasons why e2e tests are flaky is because they create side effects.** For instance, they can create records in the db. They have some logic to clean it up, but it is imperfect. Or tests can assume that some fixture will be modified once. Ideally, this would never happen, but in practice it happens all the time. **Nx Cloud will always retry the same task on a different agent to avoid this problem.**

**Don't forget, you actually need to know which tests are flaky. Most of your failures will be legitimate so rerunning all the tests will make you CI slow. And those reruns cannot be amortized.**

There are other practical problems. If you have enough VMs, rebuilding the app under test on each of them becomes impractical, so you need to build it once and send it to all your VMs. Your e2e tests have to be partitioned into small units to allow for efficient distribution. And the list of problems goes on.

**The traditional CI model is not really fixable because it makes no assumptions about its execution steps and, as a result, it cannot do anything automatically.**

**The Nx Cloud model only works when your build system and CI are built for each other.** The CI needs to know the task graph, what a task requires, what files it creates. Without this information, nothing can be distributed, nothing can be rerun or deflaked. Nx and Nx Cloud (with Nx Agents) fit together. Nx can run tasks locally or can pass this metadata to Nx Cloud which will orchestrate the same computation across many VMs. Nx Cloud will move the right files to the right agents, split large e2e test suites, and deflake the tests automatically. This only works because of the assumptions made by the CI and the build tool.

---

## Performance

The focus of this post is robustness. But the Nx Cloud model is also significantly faster and more efficient. Because Nx Agents are interchangeable, Nx Cloud will use a different number of agents depending on the size of the code change. It can split the work more effectively across agents, reduce the number of npm installs required, split large e2e suites into smaller units and more.

## Summary

The spirit of this post is similar to Alan Kay's quote, "A change of perspective is worth 80 IQ points". By changing the CI execution model, Nx Cloud makes some difficult, almost unsolvable, problems easy.

---

You can learn more about Nx Cloud on [nx.app](https://nx.app) and Nx open source on [nx.dev](https://nx.dev).

**Nx Cloud Pro includes a 2-month free trial** that is definitely worth trying out if you're curious what Cloud Pro can do for your CI. You can try out Nx Agents, e2e test splitting, deflaking and more. [Learn more about Nx Cloud Pro.](https://nx.app/campaigns/pro)

We also have a **Pro for Startups** plan which offers agents that are 3.5x cheaper than analogous VMs on CircleCI or Github Actions. [Learn more about Nx Pro for Startups.](https://nx.app/campaigns/pro-for-startups)


Reliable CI. A new execution model fixing both flakiness and slowness

---
title: Monorepos - Why Speed Matters
authors: ['Katerina Skroumpelou']
tags: nx, nxdevtools, speed, ci
cover_image: '/blog/images/2024-03-20/featured_img.png'
---

In the ever-evolving landscape of software development, efficiency and speed are vital. As projects grow in complexity, developers and teams need tools that can keep up without sacrificing quality or performance.

Nx is a suite of powerful tools designed to optimize your development workflow, which sets the [building blocks for a fast CI](/ci/concepts/building-blocks-fast-ci). Nx is always innovating in many ways to make developers’ lives easier, but this post is exclusively focused on the things Nx has done in the past year to make development faster and faster.

## Why speed matters

The ability to iterate quickly and efficiently is vital for any software project. Speed in the development process offers several critical advantages:

- **Faster feedback loops:** Quick iterations mean immediate feedback, allowing teams to adapt, learn, and improve their work on the fly.
- **Reduced time to market:** Accelerating the development process can significantly cut down the overall time to market, providing a competitive edge which reclaims revenue that would have otherwise been lost.
- **Decreased developer frustration:** [No more waiting for builds and tests to complete](/ci/concepts/reduce-waste). A streamlined workflow keeps morale high and productivity higher.

If you’re using Nx already, you’re already familiar with

- [**Affected**](/ci/features/affected) - identifying and running tasks only on projects impacted by code changes,
- [**Nx Replay**](/ci/features/remote-cache) - our powerful cache and
- [**Nx Agents**](/ci/features/distribute-task-execution) - the concept of [Parallelization and Distribution](/ci/concepts/parallelization-distribution).

But let’s see all the extra things we did this past year to make everything faster.

## Speed at the core

### Rustifying Nx

The Nx daemon has seen significant enhancements, notably through the use of Rust to calculate file hashes behind the scenes. This improvement not only speeds up the start-up times but also optimizes performance even without the daemon, especially on CI environments where the daemon isn't used. The benchmark results at [this repo](https://github.com/vsavkin/large-monorepo) showcase the remarkable speed improvements, making Nx competitive with native code solutions while maintaining the accessibility and flexibility of Node.js. Nx is still Node-first, so contributions are easier and only the most performance-critical parts of Nx are native code.

### **Task Hasher and archive file innovations**

The introduction of a task hasher written in Rust, alongside the use of an archive file to store workspace file hashes (`.nx/cache`), has significantly reduced the need for repetitive file system accesses. This innovation means that running multiple Nx commands in CI is much faster, as file hashing becomes unnecessary after the initial run.

**The Archive file**

The archive file is a binary file that contains the workspace file hashes with their last modified time. Every time Nx starts (ie, running `nx run project:target`) it gets all the files with their last modified time, and compares it to the archive. If the file exists in the archive, then Nx does not access the file system to read the file to hash (reading individual files is slower than just getting a list of files from a directory). So running multiple nx commands in CI is quick to start because Nx does not need to constantly hash files.

### Nx Replay

![](/blog/images/2024-03-20/bodyimg1.webp)

Nx Replay enables caching and reusing of task results. It’s our well known Nx remote cache! It allows developers to avoid re-running expensive tasks by retrieving the cached results from a remote cache. This significantly improves build and test performance, as well as developer productivity. Nx Replay is also critical to the functioning of Nx Agents, which rely on the remote cache to ensure that the results of a task will be shared with every agent that needs them. By using Nx Replay, developers can optimize their workflows and reduce the time spent waiting for tasks to complete.

With Nx Replay, you can see significant speed improvements in your CI pipelines for modified PRs. What’s also important is that if a task has been executed in CI, a developer running that same task locally can reuse the task result instead of actually running the task. So you will also see improvements locally.

### **Nx Agents**

![](/blog/images/2024-03-20/bodyimg2.avif)

[Nx Agents](/ci/features/distribute-task-execution) represent the pinnacle of task distribution optimization, ensuring that tasks are executed as efficiently as possible based on the specific requirements of each change. Some features that make up this effort are:

- [Easy integration with existing providers](/ci/features/distribute-task-execution#cicd-guides)
  - Distribution is handled on the Nx Cloud infrastructure and all you need is a single line. What’s more, all results are played back to your original CI provider script which triggers the Nx Cloud distribution, so that you can make use of the resulting artifacts
- [Efficient task distribution](/ci/features/dynamic-agents)
  - Save compute resources and reduce costs, minimizing idle time and compute waste
  - Dynamic sizing based on PR size
- [Tusky](https://nx.app/products/tusky) - our AI solution - coming soon
  - You set your desired cost/speed ratio, and you forget about any more configuration. We ensure maximum speed up to limits you set yourself.

You can read more about Nx Agents [here](https://nx.app/products/agents#content).

### **Atomizer**

The [Atomizer](/ci/features/split-e2e-tasks) splits your Cypress or Playwright e2e tests by file. This significantly enhances granularity for caching, parallel execution, and flaky test identification. This granular approach ensures that individual test results can be cached and only the necessary tests rerun, greatly reducing CI pipeline times and facilitating more accurate flaky test detection.

{% youtube src="https://www.youtube.com/watch?v=0YxcxIR7QU0" /%}

### **Addressing flaky tests with test deflaking**

Flaky tests can be a significant bottleneck in the CI process. Nx tackles this issue head-on by intelligently [re-running only the flaky tasks](/ci/features/flaky-tasks), rather than the entire pipeline. This approach not only saves time but also provides developers with more confidence in their CI pipeline's reliability.

![](/blog/images/2024-03-20/bodyimg3.avif)

Nx creates a hash of all the inputs for a task whenever it is run. If it encounters a task that fails with a particular set of inputs and then succeeds with those same inputs, Nx knows for a fact that the task is flaky.

## New Nx features that tie in with our core speed improvements

### Module Federation

With the help of Nx and the Module Federation setup that Nx offers, you can split up large Angular apps into smaller “vertical slices”. This can significantly speed up your builds and app startup time. Nx has revolutionized the use of Module Federation, especially in how static remotes are built and served. We make use of Nx’s task orchestration, allowing users to fine tune the number of builds happening in parallel to improve local startup time, manage machine resources better, allow for scaling.

### First-Class Playwright support

With first-class support for Playwright through **`@nx/playwright`**, Nx offers out-of-the-box generators to run Playwright tests efficiently. This integration is especially powerful with features like Atomizer, enhancing the testing process's speed and reliability.

## Conclusion

Nx provides an unparalleled toolkit for developers and teams looking to optimize their development workflows, and we keep making it faster. By intelligently leveraging modern technologies and innovative optimizations, Nx delivers speed, efficiency, and reliability, allowing teams to focus on what matters most: building great software.

---

## Learn more

- [Nx Docs](/getting-started/intro)
- [X / Twitter](https://twitter.com/nxdevtools)
- [LinkedIn](https://www.linkedin.com/company/nrwl)
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Community Discord](/community)
- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- [Speed up your CI](https://nx.app)


Monorepos - Why Speed Matters

---
title: Launch Nx Week Recap
authors: [Zack DeRose]
cover_image: '/blog/images/2024-02-15/featured_img.png'
tags: [nx, nx-cloud, releases, changelog]
---

We just finished wrapping up [Launch Nx Week](/launch-nx), which ran from February 5–9, including a full conference on Thursday!

In this article, we’re going to recap all the things launched during Launch Nx Conf, as well as all the talks given during the conference! Here’s a set of links so you can fast-forward to the stuff you’re most interested in if you want!

**Prefer a video?**

{% youtube src="https://www.youtube.com/embed/Ed1ZCNqWF1Q?si=m8LRyeJy_ZbCODJP" title="Launch Nx Week Recap" /%}

---

- [Nx 18.0 && Project Crystal](#nx-180-project-crystal)
  - [Project Crystal — By Juri Strumpflohner](#conference-talk-project-crystal)
  - [Project Crystal + .NET in Action — By Craigory Coppola](#conference-talk-project-crystal-net-in-action)
- [New Plugin: @nx/nuxt](#new-plugin-nxnuxt)
- [Nx Agents](#nx-agents-launched)
  - [Nx Agents Walkthrough: Effortlessly Fast CI Built for Monorepos — By Rares Matei](#conference-talk-nx-agents-walkthrough-effortlessly-fast-ci-built-for-monorepos)
  - [Solving E2E Tests — By Altan Stalker](#conference-talk-solving-e2e-tests)
- [Tusky](#tusky)
- [Nx Release](#nx-release-is-stable)
  - [Releasing Nx Release — By James Henry](#conference-talk-releasing-nx-release)

## Nx 18.0 && Project Crystal

Exciting news!! We’ve broken our standard release cadence of publishing a new major version every 6 months to release Nx 18, just 3 months after releasing Nx 17 in December 2024.

Juri announced launched Project Crystal with this video:

{% youtube src="https://www.youtube.com/embed/Ed1ZCNqWF1Q?si=m8LRyeJy_ZbCODJP" title="Nx Project Crystal" /%}

The short version is: Nx project crystal means Nx plugins make your codebases work more seemlessly with less config.

For the long version, checkout this blog post by Juri where he describes [how Nx plugins are now more like VsCode Extentions](/blog/2024-02-05-nx-18-project-crystal)!

And don’t miss our two conference talks on this subject:

### Conference Talk: Project Crystal

**Speaker:** [Juri Strumpflohner](https://twitter.com/juristr) | [slides](https://drive.google.com/file/d/1q6M0drdssU7Zb-4Y_f99fuupuOl1KYQN/view)

{% youtube src="https://www.youtube.com/embed/PzCgpM7qtTU?si=U5aEC7XjeS1NeKbT" title="Juri Conference Talk Project Crystal" /%}

### Conference Talk: Project Crystal + .NET in Action

**Speaker:** [Craigory Coppola](https://twitter.com/enderagent) | [slides](https://docs.google.com/presentation/d/1uveIe6HB7xwSkh7FBGZfF8Unh5YZzm5X/edit?usp=sharing&ouid=109667724870581513512&rtpof=true&sd=true) | [example repo](https://github.com/AgentEnder/nx-launch-conf-demos)

{% youtube src="https://www.youtube.com/embed/fh-yzOuQGE8?si=a-XRXJfaBCerz3i-" title="Craigory Conference Talk Project Crystal + .Net" /%}

## New Plugin: @nx/nuxt

On Tuesday we launched our newest plugin, and our first plugin to be :gem:crystalized:gem: from it’s very beginning: @nx/nuxt!

Zack explains Nuxt and how to use the new plugin in this video:

{% youtube src="https://www.youtube.com/embed/1L-bDvEemoc?si=wHQvuTDfXFs3vjaC" title="Zack explaining new plugin @nx/nuxt" /%}

To add @nx/nuxt to your codebase, use the command:

```shell
> nx add @nx/nuxt
```

Huge thanks to [Katerina](https://twitter.com/psybercity) for her work on the plugin, and Nuxt maintainer, [Daniel Roe](https://twitter.com/danielcroe), for helping to guide the project!

Zack, Katerina, and Daniel got together to live code a working tic-tac-toe app using the new Nuxt plugin and [partykit](https://www.partykit.io/) in this livestream:

{% youtube src="https://www.youtube.com/embed/uHwUxFYX2DY?si=lyYg3XPIx688k8HY" title="@nx/nuxt with Nuxt maintainer, Daniel Roe!" /%}

## Nx Agents Launched

Nx Agents are here!! We launched Nx Agents on Wednesday, and it climbed into the top 20 on [Product Hunt](https://www.producthunt.com/products/nx-cloud#nx-agents)!

We’re very excited about Nx Agents because we think that in its current state, Continuous Integration/Deployment is broken, and we think that Nx paired with Nx Agents fixes Continuous Integration. Zack explains more in this video:

{% youtube src="https://www.youtube.com/embed/_FSHQIwITic?si=jDpwTVXLYFXiHEm0" title="Nx Agents" /%}

Be sure to also checkout the [blog post from Isaac on Nx Agents](/blog/2024-02-07-fast-effortless-ci), including explanations of exclusive features like auto-detection and retrying for flaky tasks and automatically splitting lengthy end-to-end tests!

You can [signup for Nx Agents NOW](https://nx.app/products/agents#content), and find out [more of the details in our docs](/ci/features/distribute-task-execution)!

Rares and Altan are on the team building Nx Cloud, and during the conference, they dove deeper into some of these topics:

### Conference Talk: Nx Agents Walkthrough: Effortlessly Fast CI Built for Monorepos

**Speaker:** [Rares Matei](https://twitter.com/__rares) | [slides](https://drive.google.com/file/d/1k-cGCJUMP4axcCWoeih8n3dvo1oO_i_X/view?usp=sharing) | [example repo](https://github.com/rarmatei/shops-workflows/pulls) | [failed runs example](https://cloud.nx.app/cipes/65b27cf6d3ef5934decad746?utm_source=pull-request&utm_medium=comment) | [nx agents full run](https://cloud.nx.app/cipes/65b38179d3ef5934dede74c2?utm_source=pull-request&utm_medium=comment)

{% youtube src="https://www.youtube.com/embed/XS-exYYP_Gg?si=skZTGYPEVJG7BrYZ" title="Nx Agents Walkthrough" /%}

### Conference Talk: Solving E2E Tests

**Speaker:** [Altan Stalker](https://twitter.com/StalkAltan)

{% youtube src="https://www.youtube.com/embed/EO_tGa0Nx1s?si=3AvGaJkJaCeEjz1r" title="Solving E2E Tests" /%}

## Tusky

Thursday, we had a surprise announcement for our newest product on Nx Cloud: Tusky.

{% youtube src="https://www.youtube.com/embed/Xfvv09wSoM8?si=jnzyLHtdWBLwx_U0" title="Tusky" /%}

Tusky is an Artificial Intelligence for your codebase, and it will be available on Nx Cloud soon — starting in Spring of 2024.

In the teaser video, you can see some ways Tusky will be integrated into Nx Cloud to provide explainations on failed tasks, or cache misses.

The more exciting features of Tusky though includes the ability to perfectly optimize the number of agents used per PR — even spinning up and tearing down agents mid-pipeline! This is a huge optimization for task distribution, and will help optimize both walltime of your CI, as well as compute costs!

Tusky will also be able to provide organizational-level insights to your codebase, including automatically detecting development groups (like lines of business) inside your codebase based on commit history, and providing statistical insights on their commit patterns. We’re also excited about Tusky being able to make suggestions on things you can do to further optimize your codebase — like generating a PR to introduce [Codeowners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) to the repo!

## Nx Release Is Stable

Versioning and publishing packages is always a bit tricky. Mix in the added complexity of having multiple packages — sometimes with different versioning or publishing strategies — inside the same codebase, and things can get weird quick!

For a long time, Nx has been purposefully versioning and publishing agnostic, but given our time spent as [stewards of Lerna](https://blog.nrwl.io/lerna-is-dead-long-live-lerna-61259f97dbd9) (the OG Javascript monorepo tool), we’ve been able to take alot of that experience and finally feel confident creating our own versioning and publishing implementation.

Therefore, we’ve been working on a new command to the Nx CLI: [nx release](/recipes/nx-release/get-started-with-nx-release#get-started-with-nx-release). We launched this on Friday of our Launch Nx week!

Juri goes into [full details in this blog post](/blog/2024-02-09-versioning-and-releasing-packages), and James Henry — our Director of Engineering and the primary engineer responsible for both maintaining Lerna and creating Nx Release — expands further in his conference talk:

### Conference Talk: Releasing Nx Release

**Speaker:** [James Henry](https://twitter.com/MrJamesHenry) | [example repo](https://github.com/JamesHenry/nx-release-cmd)

{% youtube src="https://www.youtube.com/embed/KjZKFGu3_9I?si=83DjaHhpBSP7NP4n" title="Releasing Nx Release" /%}

## Wrapping up

Juri, Zack, and Victor wrapped up the week with a livestream recapping the launches from the week — including answering your questions live:

{% youtube src="https://www.youtube.com/embed/xjLrFvEcxZw?si=O70JD4NgseP0lknA" title="Launch Nx Week Wrap Up" /%}

That’s all for now folks! We’re just starting up a new iteration of development on Nx, so be sure to subscribe to [our YouTube channel](https://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!

---

## Learn more

- [Nx Docs](/getting-started/intro)
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](/community)
- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- [Speed up your CI](https://nx.app/)


Launch Nx Week Recap

---
title: Versioning and Releasing Packages in a Monorepo
authors: [Juri Strumpflohner]
cover_image: '/blog/images/2024-02-09/featured_img.png'
tags: [nx, nx-cloud, releases, changelog]
---

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, and it can leverage the information it has about your project dependencies and relationships to optimize your task runs.

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

![@tuskdesign/demo relies on @tuskdesign/forms and @tuskdesign/buttons, and @tuskdesign/forms also depends on @tuskdesign/buttons](/blog/images/2024-02-09/bodyimg1.webp)

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?**

{% youtube src="https://www.youtube.com/embed/KjZKFGu3_9I?si=L-8oRzy-hV-WF_pS" title="Versioning and Releasing Packages in a Monorepo" /%}

---

## Table Of Contents

- [Adding Nx](#adding-nx)
- [Installing the JavaScript/TypeScript versioning Package](#installing-the-javascripttypescript-versioning-package)
- [Running Nx Release](#running-nx-release)
- [Excluding Packages](#excluding-packages)
- [Running the Versioning and Changelog Generation](#running-the-versioning-and-changelog-generation)
- [Versioning using Conventional Commits](#versioning-using-conventional-commits)
- [Generating a GitHub Release](#generating-a-github-release)
- [Programmatic Mode](#programmatic-mode)
- [Wrapping Up](#wrapping-up)
- [Learn more](#learn-more)

## Adding Nx

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

```shell
pnpm dlx nx@latest init
```

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

This brings up a couple of questions including whether to install [Project Crystal plugins](/blog/2024-02-05-nx-18-project-crystal).

![](/blog/images/2024-02-09/bodyimg2.webp)

It gives you some additional benefits ([you can read more here](/blog/2024-02-05-nx-18-project-crystal)), 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.

```shell
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:

```shell
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.

![](/blog/images/2024-02-09/bodyimg3.webp)

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:

![Error message that reads: "> NX Unable to determine the previous git tag. If this is the first release of your workspace, use the --first-release option or set the "release.changelog.automaticFromRef" config property in nx.json to generate a changelog from the first commit. Otherwise, be sure to configure the "release. releaseTagPattern" property in nx.json to match the structure of your repository's git tags.](/blog/images/2024-02-09/bodyimg4.webp)

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`

```shell
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:

![](/blog/images/2024-02-09/bodyimg5.png)

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`

![](/blog/images/2024-02-09/bodyimg6.png)

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:

```json {% fileName="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](https://www.conventionalcommits.org/en/v1.0.0/) 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:

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

If you now run...

```shell
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.

![](/blog/images/2024-02-09/bodyimg7.webp)

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

```shell
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).

![](/blog/images/2024-02-09/bodyimg8.webp)

It also generates a nice `CHANGELOG.md` for us:

```shell
## 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](https://github.com/nrwl/nx/releases)).

```json {% fileName="nx.json" %}
Use the `createRelease` property and set it to `github`.
{
    ...
    "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 in our docs](/features/manage-releases#using-the-programmatic-api-for-nx-release) 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](/features/manage-releases#using-the-programmatic-api-for-nx-release):

```ts
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](https://github.com/privatenumber/tsx) or [tsnode](https://www.npmjs.com/package/ts-node).

```
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:

- moving 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.
- setting up fully automated releases on CI, including enabling provenance support. Our docs have [more details on how to set that up](/recipes/nx-release/publish-in-ci-cd) 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](/features/manage-releases) as well as our [release-related recipes](/recipes/nx-release).

Here are some example repositories already leveraging Nx release:

- [Our own Nx Repo](https://github.com/nrwl/nx/blob/master/scripts/nx-release.ts)
- [RxJS repo](https://github.com/ReactiveX/rxjs/tree/master/scripts)
- [Typescript-eslint](https://github.com/typescript-eslint/typescript-eslint/blob/main/tools/release/release.mts)
- [Watch the live stream](https://www.youtube.com/watch?v=lYNa6Ct4RkY) with [Kent](https://twitter.com/kentcdodds) and [James](https://twitter.com/MrJamesHenry) as they enable Nx Release on the [EpicWeb workshop app repository](https://github.com/epicweb-dev/kcdshop)

---

## Learn more

- [Nx Docs](/getting-started/intro)
- [X / Twitter](https://twitter.com/nxdevtools) — [LinkedIn](https://www.linkedin.com/company/nrwl/)
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- [Speed up your CI](https://nx.app/)


Versioning and Releasing Packages in a Monorepo

---
title: Fast, Effortless CI
authors: [Isaac Mann]
cover_image: '/blog/images/2024-02-07/featured_img.png'
tags: [nx, nx-cloud, release]
reposts: []
---

## From 90-minute to 10-minute CI Pipelines

{% youtube src="https://www.youtube.com/embed/_FSHQIwITic?si=GaAz4B0nYUEzVftN" title="Fast, Effortless CI" /%}

> TL;DR; Nx is releasing a new product called Nx Agents that dramatically improves the speed and maintainability of your CI pipeline.

In 2014, the state of the art for running tests and builds in your repository were tools like Gulp and Grunt. They were good enough to get the job done, but they were fundamentally **low-level** build tools. That is, they did exactly what they were programmed to do and no more. That approach works well in a single project where the configuration does not change frequently, but becomes problematic in a monorepo environment where there are multiple applications and multiple teams working in the same repository.

Nx was created in 2017 to address this problem. Nx is a build system that operates on a **higher level** where developers define the relationships between tasks and then Nx to decides the optimal way to run those tasks. In the same way, developers can define the inputs and outputs of tasks, then Nx automatically caches those task results. Developers tell Nx what a task does and then Nx can decide how best to run that task.

With [Nx Agents](/ci/features/distribute-task-execution), Nx is applying this same mindset to the problem of slow and costly CI pipelines. Nx gives you both **Smart Monorepos** and **Fast CI**.

## Why is CI So Hard?

Just like build tools from the last decade, CI pipelines are defined in a low-level, machine-oriented way. Each step in the pipeline is defined explicitly. It is up to the CI developer to ensure that all pre-requisites are available for each new step in the pipeline. If tasks need to be run in parallel on multiple machines, all the assets needed by each of those tasks need to be copied over to those machines before the tasks are run. Then, if the task dependencies ever change, the CI pipeline configuration needs to be updated to account for those changes.

The script below is a very simple example with only three tasks and one file being shared between them, but you can already see the complexity inherent in the system.

```yaml
jobs:
  build_base:
    steps:
      - run: npm run build-base
      - name: Save assets for use by other jobs
        uses: actions/upload-artifact@v4
        with:
          name: base_output
          path: base/output.ts

  build_app1:
    needs: build_base
    steps:
      - name: Download base output
        uses: actions/download-artifact@v4
        with:
          name: base_output
      - run: npm run build-app1

  build_app2:
    needs: build_base
    steps:
      - name: Download base output
        uses: actions/download-artifact@v4
        with:
          name: base_output
      - run: npm run build-app2
```

At any point in the future, if a task is added to the system or there is a change to the output files of build_base, this pipeline will need to be updated.

## A Build System That Runs Your CI

Part of the reason CI is so difficult to maintain is that it has no knowledge of your repository. Your CI provider can’t optimize your pipeline because it doesn’t even know the language you’re using, let alone relationships between your projects. A build system, on the other hand, must know all that information in order to properly function.

The key that unlocks all the power of Nx Agents is this architectural shift:

> Rather than the traditional approach where your CI provider invokes a build tool, the Nx build system will manage your CI pipeline.

Nx already knows how your repository is structured and the best way to run tasks locally. Nx can use that exact same knowledge to run tasks in the best way on multiple machines in CI.

## Distribute Tasks with Nx Agents

When using Nx Agents, distributing tasks across multiple machines becomes as simple as running those tasks on your local machine. This is because any task artifacts will automatically be copied to the agent machines where they are needed.

Instead of explicitly defining what order to run tasks, your CI pipeline only needs to tell Nx **what** needs to be accomplished and Nx will figure out **how** best to do it.

![](/blog/images/2024-02-07/bodyimg1.webp)

The pipeline configuration below will work no matter how many projects are in the repository or how complex the dependencies between those projects are.

```yaml
jobs:
  main:
    # Tell Nx Cloud how many agents to use and the name of the last task
    - run: |
        nx-cloud start-ci-run \
          --distribute-on="3 linux-medium-js" \
          --stop-agents-after="e2e-ci"
    # Run tasks the same way you would locally
    - run: nx affected -t lint test build --parallel=3
    - run: nx affected -t e2e-ci --parallel=1
```

The only reason to modify this file is if you need to change the number of agent machines or there is another type of task that needs to run in CI.

The `linux-medium-js` name in the CI configuration refers to a built-in launch template that Nx provides. If you can not find a template in [the default list](https://github.com/nrwl/nx-cloud-workflows/blob/main/launch-templates/linux.yaml) that meets your needs, you can provide your own. [With a single yaml file](/ci/features/distribute-task-execution#launch-templates), you can set up your agent environment in exactly the way you want with your own launch template.

## Dynamically Allocate Agents

Nx understands that some CI pipelines need more resources than others. To account for this, Nx Agents gives you the ability to [define three different classes of agent allocation configurations](/ci/features/dynamic-agents). You can use fewer agents for smaller PRs and more agents for larger PRs. This allows you to save money where possible and use the full power of Nx Agents when needed.

![](/blog/images/2024-02-07/bodyimg2.webp)

## Automatically Split E2E Tasks by File

Typically, e2e tests are the tasks that take the longest in CI. In order to take advantage of parallelization and task distribution, these large tasks would need to be split into smaller tasks, but doing this manually would involve duplicating a lot of configuration code and making sure to keep that configuration synchronized. Nx 18’s [Project Crystal](/blog/2024-02-05-nx-18-project-crystal) allows you to [automatically create separate Cypress and Playwright tasks](/ci/features/split-e2e-tasks) for each spec file in the e2e project. These individual tasks can all be triggered by running the `e2e-ci` task. What was once a tedious manual process can now be done for you automatically.

![](/blog/images/2024-02-07/bodyimg3.webp)

## Identify and Re-run Flaky Tasks

There are some tasks that will fail or succeed in CI without any changes to the task’s code. These are flaky tasks and in order to merge a change in unrelated code, developers need to manually re-run the entire pipeline until that flaky task succeeds. Because Nx is already tracking inputs and outputs of tasks, it knows when a task is flaky. Now, Nx Cloud will [automatically re-run a flaky task if it fails](/ci/features/flaky-tasks), without a developer needing to manually trigger it.

![](/blog/images/2024-02-07/bodyimg4.webp)

## Run Some Tasks on Another CI Provider

If you have a task that can’t be run on Nx Agents for some reason, you can easily [flag it to run directly on the main CI job](/ci/reference/nx-cloud-cli#enablingdisabling-distribution). Add a `--no-agents` flag to the command and Nx will not run it on an agent.

---

## Learn more

- [Nx Docs](/getting-started/intro)
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](/community)
- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- [Speed up your CI](https://nx.app/)


Fast, Effortless CI

---
title: Introducing @nx/nuxt Enhanced Nuxt.js Support in Nx
cover_image: '/blog/images/2024-02-06/featured_img.png'
authors: ['Katerina Skroumpelou']
tags: [devtools, javascript, monorepos, nuxt]
---

We're excited to introduce a new way to enhance your [Nuxt](https://nuxt.com/) development workflow! After the Vue plugin, we're introducing our new Nx plugin for Nuxt, `@nx/nuxt`. Designed for Nuxt developers and existing Nx users alike, this integration brings the best of both worlds into your development ecosystem, enabling you to leverage Nx's powerful capabilities seamlessly within your Nuxt projects.

## Why Consider Nx for Your Nuxt Projects?

Using Nx with your Nuxt.js projects presents the following advantages:

- **Monorepo Management**: Simplify the management of multiple projects within a single repository, facilitating code sharing and reducing overhead.
- **Modular Development**: Break down your Nuxt app into manageable, independent modules that can be developed, tested, and deployed in isolation.
- **Enhanced Caching**: Accelerate your development with Nx's intelligent caching, automatically configured for your Nuxt projects.
- **Nx generators**: Nx provides generators for scaffolding new Nuxt applications, with support for Jest, Storybook, and e2e test generation with Cypress or Playwright.
- **Automated upgrades**: Nx offers a set of migrators that help you upgrade your projects.

## Getting Started with Nx and Nuxt.js

Whether you're initiating a new project or integrating into an existing one, `@nx/nuxt` offers a straightforward setup process:

### Starting a New Nx Workspace with Nuxt

Creating a new Nx workspace optimized for Nuxt is as simple as running:

```shell
npx create-nx-workspace@latest --preset=nuxt
```

Our setup wizard will guide you through the initial configuration, ensuring your workspace is tailored to your needs:

```shell
npx create-nx-workspace@latest

 >  NX   Let's create a new workspace [/getting-started/intro)/getting-started/intro]

✔ Where would you like to create your workspace? · my-org
✔ Which stack do you want to use? · vue
✔ What framework would you like to use? · nuxt
✔ Integrated monorepo, or standalone project? · integrated
✔ Application name · my-app
✔ Test runner to use for end to end (E2E) tests · playwright (also cypress)
✔ Default stylesheet format · scss (also css, less)
✔ Set up CI with caching, distribution and test deflaking · github
```

This command will create a new Nx workspace with a single Nuxt application, complete with essential features and ready for development.

## Enhancing an Existing Nuxt Project with Nx

Integrating Nx into an existing Nuxt.js project has never been easier, with the help of the `nx init` command. This command will add Nx to your project without the need to disrupt your current setup.

### How It Works

When you run `nx init` in your existing Nuxt.js project, Nx does the following:

- **Installs @nx/nuxt**: Adds the necessary Nx and @nx/nuxt dependencies to your project, enabling Nx's features while keeping your existing setup intact.
- **Understands Existing Configurations**: Nx automatically recognizes your nuxt.config.js or nuxt.config.ts file, ensuring that all your custom configurations, scripts, and commands are preserved and utilized.
- **Minimal Configuration**: Only a minimal `nx.json` file is added to your project. This file is used to configure the `@nx/nuxt` plugin if needed, but in most cases, your existing Nuxt.js configurations will suffice.

To begin the integration process, simply navigate to the root of your existing Nuxt.js project and run:

```shell
npx nx init
```

This approach offers several key benefits for teams looking to adopt Nx:

- **Zero Disruption**: Your project will continue to use its existing configurations, and the existing configuration entrypoint files. There's no need to learn new configuration syntaxes or reconfigure your project to start using Nx.
- **Immediate Value**: Instantly gain access to Nx's powerful developer tools and build system, without significant changes to your project.
- **Future Flexibility**: As your project grows, Nx is ready to scale with you. You can gradually adopt more Nx features and plugins over time, at a pace that suits your team.

## Using Nx to run your Nuxt app

Nx scans your workspace to look for Nuxt configuration files (eg. `nuxt.config.ts`). It uses these files to understand where your Nuxt projects live, and uses them to set up tasks that can be invoked through Nx, like `serve` and `build`. So, in your Nx workspace, you can then run:

```shell
nx serve my-nuxt-app
```

and

```shell
nx build my-nuxt-app
```

and these commands will call the `nuxt` CLI under the hood, enhanced with Nx's features.

You can see a visual representation of your task dependencies by running

```shell
nx graph
```

![Task graph - build](/blog/images/2024-02-06/bodyimg1.png)

You can also see how Nx configures your tasks, by running:

```shell
nx show project my-nuxt-app --web
```

![Project details](/blog/images/2024-02-06/bodyimg2.png)

![Project details - individual task details](/blog/images/2024-02-06/bodyimg3.png)

### Using Nx Console

You get access to all these features through our VSCode and WebStorm [Nx Console extension](/getting-started/editor-setup).

You can use Nx Console to visualize tasks, and understand where each inferred task (like `build` and `serve` in Nuxt's case) is coming from, with our codelens-like feature, as an alternative to the `--web` flag on the `nx show project` command.

Nx Console is also very convenient for generating code and running tasks, since it offers a graphical user interface for all the amazing features of the Nx CLI.

## What Does Nx Bring to Your Nuxt Development?

With `@nx/nuxt`, your Nuxt projects gain automatic recognition of `build` and `serve` processes. There's no need to deal with unfamiliar configurations; Nx intuitively understands your Nuxt project structure and optimizes accordingly.

### Modularize and Scale with Ease

One of the most compelling aspects of using Nx with Nuxt.js is the ability to modularize large applications into manageable libraries or components. This not only makes your codebase more organized and maintainable but also significantly enhances your development workflow and CI processes.

#### Breaking Down a Monolithic Nuxt App

Large Nuxt applications can become challenging to maintain and scale over time. By adopting Nx, you can structure your Nuxt app as a collection of smaller, focused libraries. Each library can encapsulate specific functionalities or features, such as UI components, utilities, or business logic.

#### Independent Development and Testing

This modular structure allows teams to work on different aspects of the application in parallel, reducing bottlenecks and improving collaboration. Furthermore, you can run tests, linters, and other checks independently for each library, making your development process more efficient and targeted.

For instance, if you want to create a new Vue UI library, you can use the following command:

```shell
nx generate @nx/vue:lib my-shared-ui
```

This command creates a my-shared-ui library within your workspace, which can then be used across your Nuxt app and potentially other applications within the same workspace.

#### Enhancing CI with Modular Builds

On the CI front, Nx's modular approach makes things much faster. You can configure your CI pipeline to build, test, and deploy only the affected libraries and applications, thanks to Nx's advanced dependency graph analysis. This results in faster CI runs and more efficient resource utilization.

#### Sharing Code Between Applications

Nx's workspace model facilitates code sharing between projects, which is particularly useful in monorepos containing multiple front-end projects. With Nx, sharing UI components, utilities, or services between these applications becomes straightforward.
To share code, simply import the library into your Nuxt and Vue applications as needed. Nx takes care of the rest, ensuring that dependencies are correctly managed and that your applications remain buildable and testable.

Imagine a scenario where your workspace contains a Nuxt application for your public-facing website and a Vue application for an internal tool. You can create a shared library for common UI components, such as buttons, inputs, and modals, and use these components in both applications. This not only reduces duplication but also ensures consistency across your projects.

```ts
// Importing a shared UI component in your Nuxt app
import { MyButton } from '@my-org/my-shared-ui';
```

```ts
// Importing the same component in your Vue app
import { MyButton } from '@my-org/my-shared-ui';
```

### Visualizing Your Project Structure

Nx provides a clear overview of your project's structure and dependencies, making it easier to manage complex applications. The Nx Console extension for VSCode, for instance, offers a graphical interface to visualize and run tasks, enhancing your development experience.

In your workspace, you can run

```shell
nx graph
```

and see the structure of your projects:

![A project graph](/blog/images/2024-02-06/bodyimg4.png)

## Embracing Nx in Your Nuxt Journey

Whether you're starting a new Nuxt project or looking to enhance an existing one, Nx offers a compelling set of tools and features to streamline your development process. From modularization to caching, the integration of Nx into your Nuxt projects promises a more efficient, scalable, and enjoyable development experience. By embracing Nx's capabilities in your Nuxt development, you're not just optimizing your current workflow; you're future-proofing your development process. As your projects grow and evolve, Nx's modular architecture and powerful tooling will continue to provide value, making your development experience more enjoyable and productive.

---

## Learn more

- [Nx Docs](/getting-started/intro)
- [X / Twitter](https://twitter.com/nxdevtools) - [LinkedIn](https://www.linkedin.com/company/nrwl)
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Community Discord](/community)
- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- [Speed up your CI](https://nx.app)


Introducing @nx/nuxt Enhanced Nuxt.js Support in Nx

---
title: What if Nx Plugins Were More Like VSCode Extensions
authors: [Juri Strumpflohner]
cover_image: '/blog/images/2024-02-05/featured_img.png'
tags: [nx, releases]
reposts: []
---

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](#adding-nx-to-an-existing-monorepo)
- [Project Crystal](#project-crystal)
- [Project Crystal Plugins in an Nx Monorepo](#project-crystal-plugins-in-an-nx-monorepo)
  - [Inferred Targets](#inferred-targets)
  - [Visualizing Inferred Targets](#visualizing-inferred-targets)
- [More Transparency and a Single Source of Truth](#more-transparency-and-a-single-source-of-truth)
- [Enhancing existing Monorepos with Nx Plugins](#enhancing-existing-monorepos-with-nx-plugins)
- [This is just the Beginning](#this-is-just-the-beginning)
- [Learn more](#learn-more)

---

**Prefer a video? We’ve got you covered!**
{% youtube src="https://www.youtube.com/embed/wADNsVItnsM?si=sQ3-Dlx6KBRBUMkE" title="What if Nx Plugins Were More Like VSCode Extensions" /%}

Also, make sure to check out [Launch Nx Conf](/launch-nx) on Thursday, Feb 8th, where we’ll have 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.

![](/blog/images/2024-02-05/bodyimg1.webp)
_The Playwright VSCode extension enhancing the developer experience_

## Adding Nx to an Existing Monorepo

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

```shell
npx nx@latest init
```

You’ll get an `nx` package installed and an `nx.json` allowing you to define [task dependencies](/recipes/running-tasks/defining-task-pipeline) 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](https://dev.to/nx/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx-1eem).

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.

![](/blog/images/2024-02-05/bodyimg2.webp)

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

```shell
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:

```json {% fileName="project.json" }
{
  "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](/concepts/inferred-tasks). If we open the `nx.json`, you'll see a new property, `plugins`:

```json {% fileName="nx.json" %}
{
  ...
  "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:

```shell
npx nx show project reactapp --web
```

This opens your browser with the following view:

![Browser view reads "reactapp, root: apps/reactapp, type: application" and shows a list of targets.](/blog/images/2024-02-05/bodyimg3.webp)
_Browser view of the inferred targets_

Option 2 is [Nx Console](/getting-started/editor-setup), 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.

![](/blog/images/2024-02-05/bodyimg4.webp)
_Nx Console showing the inferred targets in a dedicated view_

## 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.

![](/blog/images/2024-02-05/bodyimg5.webp)

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.

![](/blog/images/2024-02-05/bodyimg6.webp)
_Asking about installing plugins based on your monorepo tooling_

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:

```shell
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

- [Nx Docs](/getting-started/intro)
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](/community)
- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- [Speed up your CI](https://nx.app/)


What if Nx Plugins Were More Like VSCode Extensions

Nx — Highlights of 2023

---
title: Nx 17.2 Update
authors: [Zack DeRose]
cover_image: '/blog/images/2023-12-20/featured_img.png'
tags: [nx, changelog, release]
---

It’s been a bit since we launched [Nx 17](/blog/2023-10-20-nx-17-release)! In this article, we’ll go over some of the new developments and improvements that have landed in Nx 17.2:

- [Nx Closes In On 4 Million Weekly NPM Downloads!!](#nx-closes-in-on-4-million-weekly-npm-downloads)
- [New Simplified Project Configuration On the Way](#new-simplified-project-configuration-on-the-way)
- [Rust for Speed, Typescript for Extensibility](#rust-for-speed-typescript-for-extensibility)
- [Module Federation Updates](#module-federation-updates)
- [Nx Release Updates](#nx-release-updates)
- [Angular 17 (AND NgRx 17) Support](#angular-17-and-ngrx-17-support)
- [Smart Monorepos — Fast CI](#smart-monorepos-fast-ci)
- [New Canary Releases](#new-canary-releases)
- [Upcoming Release Livestream](#upcoming-release-livestream)
- [Automatically Update Nx](#automatically-update-nx)

## Nx Closes In On 4 Million Weekly NPM Downloads!!

2023 has been a great year for Nx! We worked with a lot of the teams out there building fantastic open source tools. And you can see the results: we made [Vite](https://vitejs.dev/) a first class citizen in many of our Nx plugins, we added support for [Rspack](https://www.youtube.com/watch?v=jGTE7xAcg24), streamlined our Node experience by adding an Nx team maintained [Fastify plugin](https://www.youtube.com/watch?si=P5MPIiD_mxTpQStY&v=LHLW0b4fr2w&feature=youtu.be), support for Storybook interaction testing, welcomed Playwright to the family and much more, continuing our missing to push developer productivity to the limits!

And our downloads on NPM keep confirming this. We are about to cross 4 million downloads per week.

![](/blog/images/2023-12-20/bodyimg1.webp)

If this made you curious, keep an eye on [our blog](/blog) or [X/Twitter](https://twitter.com/nxdevtools) as we’re going to release a 2023 year recap blog post next week.

## New Simplified Project Configuration On the Way

Adoption is crucial, and simplicity is the driver for adoption. Last year we heavily optimized how you can use Nx in an existing project. Just drop the `nx` package (or run `nx init`) and that's it. Nx understands your workspace and efficiently runs your `package.json` scripts.

Using Nx at that level is definitely useful as you get intelligent parallelization, task pipelines and caching. But it is just the tip of the iceberg of what Nx is actually capable of. Nx plugins provide much more, especially in terms of DX and developer productivity by taking away some of the burden of configuring your monorepo tooling. But many devs new to Nx found it harder to get started with them initially and incrementally migrating to Nx plugins wasn’t as straightforward as we’d wanted it to be.

This is something that’s gonna change drastically in 2024. And we’ve layed the first cornerstone for that. But it is behind a feature flag still as we’re streamlining the last bits. The goal?

- Going almost configuration-less (good defaults, you customize when you need to)
- Allowing easy drop-in of Nx plugins into existing workspaces (provides immediate productivity gains, but stays out of your way)

This opens up a series of possibilities which we’re already super excited about. You’ll hear more about this in the new year ;)

## Rust for Speed, Typescript for Extensibility

At Nx, we’ve heavily embraced Typescript from the beginning, and we’ve been very happy with that decision.

If you’ve been paying attention to previous release announcements though, you’ve probably noticed that we’ve been moving more and more of the computationally intensive and performance critical pieces of the core of Nx from Typescript to Rust.

That trend continues in Nx 17.2 with Nx [using Rust for its task hashing by default](https://github.com/nrwl/nx/pull/19617). There’s no adjustments needed for this change, and Nx will continue to behave the same way, just faster!

{% tweet url="https://twitter.com/victorsavkin/status/1724464283227234420" /%}

## Module Federation Updates

Module Federation has been a particularly hot topic lately, and 17.2 is coming in with some great enhancements to Nx’s already best-in-class support for Module Federation!

To start, we’ve greatly reduced the CPU and memory used for standing up your Module Federation “web” locally. These enhancements should be great news to larger workspaces using a Module Federation approach, where there were heavy CPU and memory costs to serving your entire federation locally.

We accomplished these improvements by batching any applications that are not being watched for changes (listed with the `--devRemotes` option) to a single server, rather than a unique server for each application. We also parallelized the builds of these static applications when you start up your serve! You can now use the `--parallel={number}` option to specify how many builds you want going at any given time.

In addition to performance improvements, we’ve brought the concept of dynamic federation to our React module federation support. Dynamic federation allows a host application to dynamically load remotes via the manifest file.

You can generate your react module federation workspace now to use dyanmic federation via the `--dynamic` flag:

```shell
nx generate @nx/react:host acme --remotes=nx --dynamic
```

Or you can use the utility itself by importing from `@nx/react/mf`:

```ts
import { loadRemoteModule } from '@nx/react/mf';
```

Lastly, we have an [example repo](https://github.com/jaysoo/nx-react-vite-module-federation) available now to illustrate how to create a plugin for Module Federation using Nx with Vite! This is something that we are monitoring and may provide an out-of-the-box solution to this in a future release!

## Nx Release Updates

Nx 17 launched with the new `nx release` capability in the Nx CLI. Since then we've been streamlining the experience, accounting for various edge cases and release scenarios. (extensive docs are being worked on rn ;)

To give you full flexibility, in 17.2, we’ve added a programmatic API, which will allow you to easily write custom release scripts:

```ts
import { releaseChangelog, releasePublish, releaseVersion } from 'nx/release';

(async () => {
  const { workspaceVersion, projectsVersionData } = await releaseVersion({
    specifier: 'minor',
  });
  await releaseChangelog({
    versionData: projectsVersionData,
    version: workspaceVersion,
  });
  await releasePublish();
  process.exit(0);
})();
```

This script above demonstrates how you can use this API to create your own script for updating your workspace’s version, then creating a changelog, and then publishing your package!

We’ve also added first class support for independently released projects, meaning you can now target a specific project for release with the `--projects` command. For example, you can create a new version for just one project in your workspace with the command:

```shell
nx release version patch --project=my-project
```

## Angular 17 (AND NgRx 17) Support

![](/blog/images/2023-12-20/bodyimg2.webp)

[Angular](https://angular.dev/) is in the middle of [a HUGE renaissance](https://blog.angular.io/introducing-angular-v17-4d7033312e4b), between their new logo, new docs site, and introduction of some awesome features like Signals.

Nx is here to support the transition! Nx has always been a great fit for Angular, and now supports Angular 17 as well as NgRx 17.

To automatically migrate existing workspaces to Angular v17, run the commands:

```shell
nx migrate latest
nx migrate --run-migrations
```

You can also use the `--interactive` flag if you want to migrate your workspace to the latest version of Nx while staying on your current version of Angular:

```shell
> nx migrate latest --interactive
✔ Do you want to update to TypeScript v5.2? (Y/n) · true
✔ Do you want to update the Angular version to v17? (Y/n) · false

 >  NX   The migrate command has run successfully.

   - package.json has been updated.
   - migrations.json has been generated.

 >  NX   Next steps:

   - Run 'nx migrate --run-migrations'
```

## Smart Monorepos — Fast CI

We just gave our Nx homepage a small facelift, including a new tagline, subtagline and illustration to better reflect Nx’s mission statement.

![](/blog/images/2023-12-20/bodyimg3.webp)

When you enter the monorepo space, having good local development experience and tooling to support you is one thing, scaling is the other. And scaling comes with multiple challenges, from scaling teams working on the monorepo to maintaining high throughput on CI.

The latter is a common headache and we’ve seen companies struggle. With Nx we’re moving into the direction of becoming your e2e solution for monorepos, where we don’t just cover your local dev experience, but also provide robust and scalable solutions on CI.

![](/blog/images/2023-12-20/bodyimg4.webp)

We’re super excited to have launched “Nx Agents” to Early Access. If you haven’t seen Victor’s video yet about how he reduced e2e tests from 90 minutes to 10, then make sure to [check it out](/ci/features/distribute-task-execution).

**“Nx Agents”** are the next iteration of DTE, providing a more flexible, cost effective and more performant approach to distribution on CI. This includes things like being able to dynamically allocate machines based on the size of the PR and flaky task detection and re-running. Also, it can be configured with a single line:

```yaml
- name: Start CI run
  run: 'npx nx-cloud start-ci-run --distributes-on="8 linux-medium-js"'
  ...
```

You can run Nx Agents on any CI provider. If you’re curious, [sign up for early access](https://go.nx.dev/nx-agents-ea)!

## New Canary Releases

We’ve added a new npm release tag: canary!

![](/blog/images/2023-12-20/bodyimg5.webp)

This canary release is created via a [cron job](https://github.com/nrwl/nx/blob/master/.github/workflows/publish.yml#L5C61-L5C61) that will regularly publish the current contents of the master branch of Nx.

You can give the canary version a try new for a new workspace using the command:

```shell
npx create-nx-workspace@canary
```

This should be useful for previewing new not-yet released features!

## Upcoming Release Livestream

{% youtube src="https://www.youtube.com/embed/OXXTUjSO1hs?si=iDFETYdpg-0BrAIP" title="Nx 17.2 Release Livestream" /%}

We’re going live in January with the Nx team to go over these updates as well! Be sure to click the link to get notified when we go live! And feel free to come with your questions in the chat!

## Automatically Update Nx

Updating Nx and its plugins is easy as we ship an [automated migration command](/features/automate-updating-dependencies).

```shell
npx nx migrate latest
```

After updating your dependencies, run any necessary migrations.

```shell
npx nx migrate --run-migrations

```

## Wrapping up

That’s all for now folks! We’re just starting up a new iteration of development on Nx, so be sure to subscribe to our [YouTube channel](https://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!

---

## Learn more

- [Nx Docs](/getting-started/intro)
- [X/Twitter](https://twitter.com/nxdevtools) -- [LinkedIn](https://www.linkedin.com/company/nrwl/)
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](/community)
- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- [Speed up your CI](https://nx.app/)


Nx 17.2 Update

---
title: 'Nx 17 has Landed'
authors: ['Juri Strumpflohner', 'Zack DeRose']
cover_image: '/blog/images/2023-10-20/featured_img.png'
tags: [nx, design]
---

{% youtube src="https://www.youtube.com/embed/1Z0iA9K1o8M?si=9XxIboXSZ5yxFpIt" /%}

We’re excited to announce the release of Nx version 17!

This article will cover the main things you need to know to get the most out of Nx 17!

Here’s a Table of Contents so you can skip straight to the updates you care about the most:

- [It's a Vue-tiful Day for Nx](#its-a-vuetiful-day-for-nx)
- [Enhancements to Module Federation Support](#enhancements-to-module-federation-support)
- [More Consistent Generator Paths](#more-consistent-generator-paths)
- [The NEW Nx AI Chatbot](#the-new-nx-ai-chatbot)
- [More Seamless Integration With Nx Cloud](#more-seamless-integration-with-nx-cloud)
- [`nx.json` Simplification](#simplification)
- [Nx Repo Begins Dog-Fooding Nx Workflows](#nx-repo-dogfooding-nx-workflows)
- [Task Graphing Improvements](#task-graphing-improvements)
- [`@nx/linter` Renames to `@nx/eslint`](#renamed-to)
- [New Experimental Feature: Nx Release](#new-experimental-feature-nx-release)
- [Experimental: Nx Project Inference API v2](#experimental-nx-project-inference-api-v2)
- [20k Github Stars!!](#20k-github-stars)

## It’s a Vue-tiful Day for Nx!

Ever since we added Vite as a first-class citizen to Nx workspaces (see `@nx/vite`), we started falling in love with the Vue community. The only logical next step: Nx now provides a brand new Vue plugin that is being maintained by the Nx team! (And we're already working on a [Nuxt](https://nuxt.com/) plugin 🤫)

The first place you might notice this new support is in the `create-nx-workspace` script:

![](/blog/images/2023-10-20/bodyimg1.webp)

This option will create a new Nx workspace with a fresh Vue application, all set up and ready to develop! To add new Vue projects to your existing Nx workspaces, add our new @nx/vue package as a dev dependency to your workspace, e.g.:

```shell
> npm add -D @nx/vue
```

And you’ll have access to Nx generators so that you can generate Vue applications, libraries, components, and more in your workspace:

![](/blog/images/2023-10-20/bodyimg2.gif)

We’re very excited for this support to land, and we’re eager to get it into our user’s hands and see what Nx can do to help Vue developers so we can continue to refine our support and make Vue with Nx an excellent developer experience.

If you’re eager to learn more, make sure to check out our new [Vue standalone tutorial](https://nx.dev/getting-started/tutorials/vue-standalone-tutorial).

## Enhancements to Module Federation Support

Nx already had great support for Module Federation — Nx 17 improves on this support:

### NEW: Typesafe Config

Projects created with Nx’s generators for module federation will now be created with a `module-federation.config.ts` file (as opposed to a `.js` file). A new `ModuleFederationConfig` interface is also exported from the `@nx/webpack` plugin.

### Better Typesafety Across Modules

Nx 17 improves type-safety across modules, so proper type-safety is currently supported across dynamic imports.

![](/blog/images/2023-10-20/bodyimg3.gif)

### NEW GENERATOR: Federate ANYTHING.

The `@nx/react` and `@nx/angular` now include a `federate-module` generator. This will allow you to create a federated module from any Nx project.

To run this generator, use the command:

```shell
> nx g federate-module <module name> --path=<path to module to be exposed> --remote=<name of remote exposing module>
```

This will add a new module to the `exposes` map in the specified `remote` application, such that it can be consumed by a `host` application.

### Managing Module Versions

Nx now supports targeted versioning for federated modules.

To create versions for a given project, you can use the `version` property of that project's `package.json` file and then build that project to create the version locally.

Then, when consuming this library, you can use the `shared` method of the `ModuleFederationConfig`:

```ts
import { ModuleFederationConfig } from '@nx/webpack';

const config: ModuleFederationConfig = {
  name: 'my-remote',
  exposes: {
    './Module': 'apps/my-remote/src/app/remote-entry/entry.module.ts',
  },
  remotes: ['federated-is-odd'],
  shared: (libName, configuration) => {
    if (libName === 'is-odd') {
      return {
        singleton: true,
        strictVersion: true,
        requiredVersion: '0.0.1',
      };
    }
    return configuration;
  },
};

export default config;
```

This config will ensure that version `0.0.1` of the `is-odd` is used.

## More Consistent Generator Paths

Similar to the [adjustments we made in 16.8](https://www.youtube.com/watch?v=bw8pRh0iC4A&t=14s) for most of our project-creating generators, v17 brings updates to how component generators work. These updates aim to give you more control over the name and file location of your components.

Towards this end, we’ve added a new `--nameAndDirectoryFormat` option that you can set to either `as-provided` or `derived`.

When set to `as-provided`, the generator will use the `name` option for the name of your component and the `directory` option to determine where on your file system to add the component. `as-provided` will be used by default if none is specified.

When set to `derived`, the generator will try to determine where to create your component based on the `project` option - which will mainly operate how component generators do now.

In addition, component generators now follow any given casing for component files. For example, let’s say we have an integrated monorepo with a react application called “my-app” and want to add a “Home” component. With Nx 17, you can run the command:

```shell
> nx g component Home --directory=apps/my-app/src/app
```

And a `Home.tsx` file will be added in the `apps/my-app/src/app` directory.

You can now also build your directory path right into the generator command. For example, the same “Home” component would be created via:

```shell
> nx g component apps/my-app/src/app/Home
```

Finally, generators will now factory in your current working directory, so you can also create this “Home” component via:

```shell
> cd apps/my-app/src/app
> nx g component Home
```

## The NEW Nx AI ChatBot

We’ve added a new AI ChatBot to our docs site. You can access it now at [https://nx.dev/ai-chat](https://nx.dev/ai-chat).

![](/blog/images/2023-10-20/bodyimg4.gif)

This feature is still in beta, so please use the thumbs up/thumbs down buttons to provide feedback on whether the chatbot is accurate and helpful!

## More Seamless Integration With Nx Cloud

After running the `nx migrate` command to upgrade to Nx 17 and using Nx Cloud, you may have observed the removal of `nx-cloud` from your dev dependencies. Don't worry - Nx Cloud is not only still around but thriving. Instead of having a standalone package, we've integrated the Nx Cloud communication layer directly into the `nx` package. This ensures a seamless connection whenever you opt in and eliminates potential version misalignment concerns with our API endpoint.

## `nx.json` Simplification

Our Nx Cloud updates come alongside configuration changes in your `nx.json` file and project configuration.

Specifically, we’ve added an optional `nxCloudAccessToken` to the `nx.json` file - as long as a token is provided here, we'll make sure that you take advantage of the currently deployed version of Nx Cloud when running commands with Nx.

We’ve also removed the need to specify `cacheableOperations` at the task-runner level. From now on, every `target` configured in your `project.json` can be defined as cacheable using the `cache` property.

```json {% fileName="nx.json" %}
{
    "targetDefaults": {
        "build": {
            "cache": true,
            ...
        }
    }
}
```

If you use the `nx migrate` command, all updates will be handled for you using the `targetDefaults` in your `nx.json` file. [More in the docs.](https://nx.dev/features/cache-task-results)

We’ve been working hard at reducing and simplifying all the configuration required for your Nx workspaces. Checkout our latest guide on how to [Reduce Repetitive Configuration](https://nx.dev/recipes/running-tasks/reduce-repetitive-configuration) for more, and stay tuned as we’ve got new efforts underway to make this simplification even more appealing!

## Nx Repo Dog-Fooding Nx Workflows

At Nx Conf in New York City, we unveiled the next big step for Nx: **Nx Workflows**.

If you missed it, Simon Critchley walks you through in his [Nx Conf](https://dev.to/nx/nx-conf-2023-recap-53ep) talk:

{% youtube src="https://www.youtube.com/embed/JG1FWfZFByM?si=7_NzxJP8nA7RbFhl" /%}

Put simply, Nx Workflows represents Nx entering the CI provider arena, where Nx can now provide you with Cloud Computation to run your CI tasks. This creates the foundation for a whole new class of Nx Cloud features that we’re excited to work on in the coming cycles.

The Nx repo itself is now “dog-fooding” this latest feature (dog-fooding refers to using our tool in our own projects, or “eating our own dog food”), and you can see how it’s going now on our [public Nx Cloud workspace](https://staging.nx.app/orgs/62d013d4d26f260059f7765e/workspaces/62d013ea0852fe0a2df74438/overview).

![](/blog/images/2023-10-20/bodyimg5.webp)

Nx Workflows are still in the experimental phase. We’re running pilots with our enterprise clients and are excited to open this up for everyone soon!

## Task Graphing Improvements

Task Caching in Nx is based on a set of “input” files calculated for a given task. You can specify specific files or patterns of files in your project.json for a particular task or in the `targetDefaults` of your `nx.json` to set the default file sets for your inputs.

There have been some difficulties in determining precisely which files were included and which weren’t for a given task. This is where our latest update to the task graph comes in:

![](/blog/images/2023-10-20/bodyimg6.webp)

You can open this graph using the command:

```shell
> nx graph
```

And then selecting “Task” from the “Project”/”Task” graph dropdown in the top left. Clicking on a specific task now allows you to see a comprehensive list of all files that were factored in as inputs for this task:

![](/blog/images/2023-10-20/bodyimg7.webp)

## `@nx/linter` Renamed to `@nx/eslint`

After running `nx migrate`, you may have noticed that the `@nx/linter` plugin was removed and replaced with `@nx/eslint`.

In Nx 17, we removed any remaining traces of `tslint` from our linter package, so this is mainly a simple rename to more accurately describe the package (and to remove any confusion that this package is intended to support linting for other languages/platforms).

## New Experimental Feature: Nx Release

`nx release` is a new top level command on the Nx CLI which is designed to help you with versioning, changelog generation, and publishing of your projects:

- `nx release version` - Determine and apply version updates to projects and their dependents
- `nx release changelog` - Generate CHANGELOG.md files and optional Github releases based on git commits
- `nx release publish` - Take the freshly versioned projects and publish them to a remote registry

`nx release` is still experiment and therefore subject to change, but the Nx repo itself is now using these commands to version itself, as well as generate changelogs, [Github releases](https://github.com/nrwl/nx/releases/tag/17.0.3), and publish our packages to npm.

As we solidify this command, we intend to bring robust support for various versioning and publishing strategies, as well as built-in support for publishing packages or modules to a variety of languages, registries, and platforms.

For more [checkout our API docs](https://nx.dev/nx-api/nx/documents/release), and be sure to catch James Henry’s announcement of this new command at [Nx Conf](https://dev.to/nx/nx-conf-2023-recap-53ep):

{% youtube src="https://www.youtube.com/embed/p5qW5-2nKqI?si=FzpGMJwPVINc1hgL" /%}

## Experimental: Nx Project Inference API v2

At Nx, we’re OBSESSED with building a better, more robust experience for our developers. Towards this end, we’re now in [v2 of our Project Inference API](https://nx.dev/extending-nx/recipes/project-graph-plugins).

This API is a way of extending the Nx project graph, which can be particularly helpful for extending Nx to support other languages, allowing Nx to determine where to find and draw boundaries around projects in your workspace. A great example is our very own [Vue plugin](https://nx.dev/getting-started/tutorials/vue-standalone-tutorial).

Interestingly, v2 includes support for dynamic targets as well. This opens up exciting new doors to reducing configuration, and we hope to expand on this to better support our first-party plugins in the near future.

For most developers, the main thing you need to know is that plugins may now add additional targets that you won’t see in your `project.json` file. To see your actual project configuration, you can now use the command:

```shell
> nx show project <project_name>
```

For plugin authors, check out the [v2 documentation](https://nx.dev/extending-nx/recipes/project-graph-plugins) to see how you can take advantage of the new API to deliver a better experience to your users.

## 20k Github Stars!!

Nx is SOOO CLOSE to 20,000 stars on github! If Nx has been helpful to you, [please help us get there](https://github.com/nrwl/nx)!

![](/blog/images/2023-10-20/bodyimg8.webp)

## How to Update Nx

Nx is known to [help you automatically migrate](https://nx.dev/features/automate-updating-dependencies) to the new version (including potentially breaking changes). To update simply run:

```shell
> npx nx migrate latest
```

This will update your Nx workspace dependencies, configuration and code to the latest version. After updating your dependencies, run any necessary migrations:

```shell
> npx nx migrate --run-migrations
```

## Wrapping up

That’s all for now folks! We’re just starting up a new iteration of development on Nx, so be sure to subscribe to our [YouTube channel](https://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!

---

## Learn more

- [Nx Docs](https://nx.dev/getting-started/intro)
- [X/Twitter](https://twitter.com/nxdevtools) -- [LinkedIn](https://www.linkedin.com/company/nrwl/)
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- [Speed up your CI](https://nx.app/)


Blog

More blogs