Nx helps architect, test, and build at any scale:
integrations with modern frameworks, distributed task execution, computation caching, smart rebuilds of affected projects, powerful code generators, editor support, GitHub apps, and more.

Learn Nx

In a monorepo, all of your apps and packages reside in a single repo. Structuring your code this way has many organizational benefits. You can more easily manage your dependencies, and you can maintain more consistency across your various apps. 

But, if you attempted to do this with just yarn or pnpm alone, you'll quickly start running into productivity issues. Your build times will be very long, and you'll have to make sure to run builds for any internal packages an app is depending on.

That's where Nx comes in.

Combining the speed of pnpm with the efficiency of Nx gives you an amazingly performant monorepo setup.

Nx builds a graph of your workspace and all of the connected dependencies. If there is a change anywhere, Nx will know about it and everything that is affected by it. 

Which means that Nx is able to use caching to prevent unnecessary builds when nothing has changed. Nx's caching features enable blazing fast <10ms build times 🔥

You get to have all the advantages of the monorepo with none of the performance issues! 

So start watching this course and learn how to achieve these speeds today. 

A Monorepo is where you have multiple projects inside a singular repository.

monorepo

Build High-Speed Monorepos with Nx and pnpm Workspaces

On the surface, starting a project sounds easy. First you make some directories, install some dependencies, then you write some code.

But there's a bit more to it than just those three steps.

The type of project you're working on impacts the decisions you make. It gets more complicated when you're working on multiple projects that are related. For example, maybe you have a customer-facing frontend app, an admin dashboard app, and a single backend used for both.

How does this change your directory structures? How should you share code between projects? What happens when you add a Design System into the mix?

It can get hard to keep things straight in your head.

Nx is a tool that aims to solve these problems for you, whether you're working solo on a small full-stack app or on a dev team of thousands.

It's not just an opinionated folder structure. When you create an app with Nx, it generates unit and e2e test setups as well as preparing bundling and code-splitting with Webpack, and stubbing out common features like routing.

One of the coolest features of Nx is its Dependency Graph. The graph can visually show you the relationship between the parts of your application, and is optimized to ensure that compiling, testing, and linting only happens in the affected areas of your project.

In this course, Juri Strumpflohner demonstrates these features and more through the iterative creation of a React + Storybook + Express app. Don't worry if this isn't your preferred stack! Nx supports the most popular frameworks & libraries on the web.

More importantly, the focus of this course is more on the workflow than the implementation.

Watch Juri's course, and see if the Nx tooling & workflow is right for you and your team!

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Scale React Development with Nx

Tailwind is a utility-first CSS framework for rapidly building custom user interfaces.

tailwind

Architect an Extensible Digital Garden with Next.js, Tailwind, and Nx

In an Nx monorepo, you typically have multiple applications and lots of libraries. When we configure [Vercel](https://vercel.com) for deployment, we set one Vercel deployment for each app in our monorepo. However, we would want to make sure that not all the apps are being deployed all the time, but only if the app was really affected by the change. [Nx affected commands](https://nx.dev/l/r/core-extended/affected#rebuilding-and-retesting-what-is-affected) can help here.

In this lesson we're going to create a simple script, that leverages the Nx affected commands to determine whether we should cancel or continue a given Vercel deployment.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/publishing-a-next-js-app-to-vercel-with-nx-df81916548f5).

Only Deploy to Vercel What has Been Affected Using Nx

If you work in a monorepo you want to make sure to have tooling that supports that. [Nx](https://nx.dev) comes with those baked in, allowing you to grow your monorepo from a single to multiple apps. One way Nx tackles this is by providing so-called [affected commands](https://nx.dev/l/r/core-extended/affected#rebuilding-and-retesting-what-is-affected).

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/publishing-a-next-js-app-to-vercel-with-nx-df81916548f5).

Only Build What Changed with Nx Affected Commands

In this lesson, we're going to have a look at how to add [Nx](https://nx.dev) to a Yarn / NPM / PNPM monorepo for achieving faster task scheduling abilities. In particular, we also see how [Lerna](https://lerna.js.org) v5.1+ comes with an easy `useNx: true` opt-in flag, allowing to use Nx to run tasks, but keeping the old Lerna commands.

Add Nx to a Lerna based monorepo

Learn the difference between application-centric and package-centric projects then create a new pnpm workspace with an application-centric structure.

Create a pnpm Workspace

You can use pnpm's --filter flag to run scripts in any app in your monorepo from the root of the project. 

All you have to do is ensure that each of your app's have `name` set in their `package.json` file. Then you can run, for example, `pnpm --filter my-remix-app dev`.

Use pnpm Filter Commands to Run App Scripts From the Workspace Root

You can create private libraries in your monorepo that you can share between your other packages and applications. 

To do this all you need to do is create a new folder containing a package.json in your packages directory. You can then use pnpm filter commands to add external libraries to your package without ever having to cd into it! 

Then just make sure to create an entry point and set the `main` field in your package.json to where your code will compile when built. 

Create a Shared Library in a pnpm Workspace

Remix is a full stack web framework that focuses on web standards and the server/client model so that you can develop the features your users want and need without being bogged down in over-abstractions. When you get good with Remix, you actually get good at the foundations of web development.

remix

In your pnpm monorepo, you can easily create new applications under your apps folder. 

Here, you'll create a new Remix app by running the command `pnpx create-remix@latest`. The app you generate functions just like any other full featured Remix app!

Add a Remix App to a pnpm Workspace Monorepo

As your workspace grows you may need to start using more advanced optimizations. 

A great option that Nx provides are "affected commands". These use git to determine the changes between your current branch and the base branch, and **run a command on all projects that were affected by the changes**

Further Optimize Your Nx Workspace with Affected Commands

Since dependencies on other local packages in the workspace are really just symlinks to those projects, we'll run into issues if we haven't ran their build script. 

We can make sure that this happens automatically by using Nx's task pipeline features. In our `nx.json` we can add a `dependsOn` field and set the commands that need to be ran within a project's dependencies. 

Use the Nx Task Pipeline to Run Commands Within Local Dependencies

By default, Nx considers all the files in the project as inputs to the cache, so any changes will invalidate it. But, that might not be the behavior we want. Especially if we are just doing something like updating a README.

To selectively ignore certain files, we can specify an inputs field where we are configuring the custom output. There, we can use a glob pattern to define the files you'd like to ignore. 

Configure Nx Cache to Ignore Changes to Specified Files

In this course we'll be focusing on a package-based monorepo setup. 

Basically, we have a collection of packages, each with their own `package.json`. We'll then use pnpm workspaces to set up a monorepo that allows us to share these packages between each other locally. 

As our app grows we'll bring in Nx to get more advanced features such as build pipelines and caching.

So let's dive right in! If you have any questions don't hesitate to leave a comment. 

Introduction to Build High-Speed Monorepos with Nx and pnpm Workspaces

By default Nx stores the cache locally. We can gain additional benefits if we distribute our cache so a CI or our coworkers may benefit from it. 

The easiest way to set it up is to just run this command `pnpx nx connect-to-nx-cloud`

Distribute Your Cache with Nx Cloud

Not only do you get excellent speed and caching features, you also get a really cool graph from Nx that lets you see a visual representation of your workspace.

Use the Nx Graph to Visualize Your Workspace

Sometimes you might want to use a pattern you defined for a certain input in a different one somewhere else in your nx.json confg. 

You can do that by defining a `namedInputs` object field and setting your named input's name as the key, and the glob pattern as the value. 

Use Nx Named Inputs to Reuse Glob Patterns Across Inputs

Nx has some default settings when restoring the cache. When you create a custom build output in your `tsconfig` for example, Nx won't automatically know about it. 

But, Nx gives you some really easy to use options for configuring these settings. On the project level you can tell Nx about your custom output target in the `package.json` 

You can also set a default for all the projects in the workspace in your `nx.json` config!

Configure the Nx Cache Output Location

It's a waste of computation resources to run your build scripts if there haven't been any changes. 

Nx's caching features save you time and resources. Get started by just running the `nx init` command and then setting the scripts you want to cache in the generated `nx.json`  

Configure Nx Caching

You can run multiple projects using the `run-many` command from Nx and setting a `--target` flag with the command you want to run.

For example `npx nx run-many --target=build`

Use Nx run-many to Run Commands in Multiple Projects

Nx provides you with a more convenient syntax to run commands within your workspace projects. 

Either `nx <target> <project>` or `nx run <project>:<target>` will work, but usually the first one is more convenient to use.

Topics

Instructors

Content Type

Nx