Compare commits
48 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Craigory Coppola
|
4fc0a47a7a | ||
|
Colum Ferry
|
0bf114eb11 | ||
|
James Henry
|
76b3f57823 | ||
|
Jonathan Cammisuli
|
525bcca0a0 | ||
|
Leosvel Pérez Espinosa
|
6176d3a504 | ||
|
Jason Jean
|
c19e6b8ce0 | ||
|
Jason Jean
|
d8ad991ae7 | ||
|
Craigory Coppola
|
98d3354855 | ||
|
Jason Jean
|
6f9cce78ac | ||
|
Jason Jean
|
0d53604b5a | ||
|
Robby Rabbitman
|
b65216387e | ||
|
James Henry
|
9b2eed2662 | ||
|
Jason Jean
|
68426f6adb | ||
|
Nicholas Cunningham
|
3b3b320ff7 | ||
|
Jason Jean
|
480a20e3c5 | ||
|
Jack Hsu
|
3b19cf6811 | ||
|
Caleb Ukle
|
e118210e7f | ||
|
Leosvel Pérez Espinosa
|
e6a3d77db3 | ||
|
Isaac Mann
|
30a7709d71 | ||
|
Nicolas Beaussart
|
a944c8cd54 | ||
|
Benjamin Cabanes
|
05c9d0d24f | ||
|
Benjamin Cabanes
|
42a9a2c51a | ||
|
James Henry
|
71de122579 | ||
|
Colum Ferry
|
ba6d324645 | ||
|
Isaac Mann
|
ea40d04e70 | ||
|
Nacho Vazquez
|
9ae68a7c0d | ||
|
Colum Ferry
|
678965da21 | ||
|
Philip Fulcher
|
d8cf187dbc | ||
|
Colum Ferry
|
ee276413b8 | ||
|
Philip Fulcher
|
a36aaacef6 | ||
|
Isaac Mann
|
72a0ef541f | ||
|
Jack Hsu
|
382bd6eb2c | ||
|
Jason Jean
|
5eefe8575a | ||
|
Jason Jean
|
5cd09f97ff | ||
|
James Henry
|
e2b27b849b | ||
|
Nicholas Cunningham
|
265bb0b4bb | ||
|
James Henry
|
37dea94062 | ||
|
James Henry
|
0402e85d87 | ||
|
Craigory Coppola
|
9fe487c0f3 | ||
|
Nicholas Cunningham
|
ce64f85069 | ||
|
Jordan
|
fb6c2ca5f0 | ||
|
Jason Jean
|
cc1f655e99 | ||
|
Jason Jean
|
02ba546ad7 | ||
|
Isaac Mann
|
2cb0fa2b55 | ||
|
Josh VanAllen
|
675e6ed8ec | ||
|
Emily Xiong
|
70cec4b41a | ||
|
Craigory Coppola
|
6e12a821df | ||
|
Craigory Coppola
|
c2321a3489 |
@@ -94,7 +94,7 @@ jobs:
|
||||
pnpm nx run-many -t check-imports check-commit check-lock-files check-codeowners --parallel=1 --no-dte &
|
||||
pids+=($!)
|
||||
|
||||
pnpm nx affected --targets=lint,test,build,e2e,e2e-ci,format-native &
|
||||
pnpm nx affected --targets=lint,test,build,e2e,e2e-ci,format-native,lint-native &
|
||||
pids+=($!)
|
||||
|
||||
for pid in "${pids[@]}"; do
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
name: E2E matrix
|
||||
|
||||
on:
|
||||
schedule:
|
||||
- cron: "0 5 * * *"
|
||||
# schedule:
|
||||
# - cron: "0 5 * * *"
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
debug_enabled:
|
||||
|
||||
+1
-5
@@ -1,5 +1 @@
|
||||
pnpm check-lock-files
|
||||
pnpm check-commit
|
||||
pnpm documentation
|
||||
pnpm pretty-quick --check
|
||||
pnpm nx format-native nx
|
||||
pnpm nx prepush --parallel 8 --tuiAutoExit 0
|
||||
|
||||
Generated
+46
-28
@@ -2202,13 +2202,14 @@ dependencies = [
|
||||
"sysinfo",
|
||||
"tar",
|
||||
"tempfile",
|
||||
"terminal-colorsaurus",
|
||||
"thiserror",
|
||||
"tokio",
|
||||
"tokio-util",
|
||||
"tracing",
|
||||
"tracing-appender",
|
||||
"tracing-subscriber",
|
||||
"tui-term",
|
||||
"tui-term 0.2.0 (git+https://github.com/JamesHenry/tui-term?rev=88e3b61425c97220c528ef76c188df10032a75dd)",
|
||||
"vt100-ctt",
|
||||
"walkdir",
|
||||
"watchexec",
|
||||
@@ -3550,6 +3551,32 @@ dependencies = [
|
||||
"windows-sys 0.59.0",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "terminal-colorsaurus"
|
||||
version = "0.4.8"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "b7afe4c174a3cbfb52ebcb11b28965daf74fe9111d4e07e40689d05af06e26e8"
|
||||
dependencies = [
|
||||
"cfg-if",
|
||||
"libc",
|
||||
"memchr",
|
||||
"mio 1.0.3",
|
||||
"terminal-trx",
|
||||
"windows-sys 0.59.0",
|
||||
"xterm-color",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "terminal-trx"
|
||||
version = "0.2.4"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "975b4233aefa1b02456d5e53b22c61653c743e308c51cf4181191d8ce41753ab"
|
||||
dependencies = [
|
||||
"cfg-if",
|
||||
"libc",
|
||||
"windows-sys 0.59.0",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "termios"
|
||||
version = "0.2.2"
|
||||
@@ -3851,7 +3878,15 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "72af159125ce32b02ceaced6cffae6394b0e6b6dfd4dc164a6c59a2db9b3c0b0"
|
||||
dependencies = [
|
||||
"ratatui",
|
||||
"vt100",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "tui-term"
|
||||
version = "0.2.0"
|
||||
source = "git+https://github.com/JamesHenry/tui-term?rev=88e3b61425c97220c528ef76c188df10032a75dd#88e3b61425c97220c528ef76c188df10032a75dd"
|
||||
dependencies = [
|
||||
"ratatui",
|
||||
"vt100-ctt",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
@@ -3969,40 +4004,17 @@ version = "0.9.4"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "49874b5167b65d7193b8aba1567f5c7d93d001cafc34600cee003eda787e483f"
|
||||
|
||||
[[package]]
|
||||
name = "vt100"
|
||||
version = "0.15.2"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "84cd863bf0db7e392ba3bd04994be3473491b31e66340672af5d11943c6274de"
|
||||
dependencies = [
|
||||
"itoa",
|
||||
"log",
|
||||
"unicode-width 0.1.11",
|
||||
"vte 0.11.1",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "vt100-ctt"
|
||||
version = "0.16.0"
|
||||
source = "git+https://github.com/JamesHenry/vt100-rust?rev=1de895505fe9f697aadac585e4075b8fb45c880d#1de895505fe9f697aadac585e4075b8fb45c880d"
|
||||
source = "git+https://github.com/JamesHenry/vt100-rust?rev=b15dc3b0f7db94167a9c584f1d403899c0cc871d#b15dc3b0f7db94167a9c584f1d403899c0cc871d"
|
||||
dependencies = [
|
||||
"itoa",
|
||||
"log",
|
||||
"ratatui",
|
||||
"tui-term",
|
||||
"tui-term 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
|
||||
"unicode-width 0.2.0",
|
||||
"vte 0.13.1",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "vte"
|
||||
version = "0.11.1"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "f5022b5fbf9407086c180e9557be968742d839e68346af7792b8592489732197"
|
||||
dependencies = [
|
||||
"arrayvec",
|
||||
"utf8parse",
|
||||
"vte_generate_state_changes",
|
||||
"vte",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
@@ -4651,6 +4663,12 @@ dependencies = [
|
||||
"rustix 1.0.5",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "xterm-color"
|
||||
version = "1.0.1"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "4de5f056fb9dc8b7908754867544e26145767187aaac5a98495e88ad7cb8a80f"
|
||||
|
||||
[[package]]
|
||||
name = "xxhash-rust"
|
||||
version = "0.8.10"
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
disallowed-types = [
|
||||
# We need to ensure adjustments for light and dark themes are applied appropriately
|
||||
{ path = "ratatui::style::Color", reason = "Use our utils from crate::native::tui::colors instead to ensure appropriate light/dark theme support" },
|
||||
]
|
||||
@@ -464,6 +464,11 @@
|
||||
"description": "Nx plugin for Cloudflare, in particular Cloudflare workers. It allows to generate build and run Cloudflare workers in your Nx workspace.",
|
||||
"url": "https://github.com/naxodev/oss/tree/main/packages/nx-cloudflare"
|
||||
},
|
||||
{
|
||||
"name": "@naxodev/gonx",
|
||||
"description": "Modern Nx plugin to use Go in a Nx workspace. Forked from @nx-go/nx-go",
|
||||
"url": "https://github.com/naxodev/oss/tree/main/packages/gonx"
|
||||
},
|
||||
{
|
||||
"name": "@ziacik/azure-func",
|
||||
"description": "Generating, serving and publishing Azure Functions 4 apps.",
|
||||
@@ -519,6 +524,11 @@
|
||||
"description": "Foundry generators and inferred tasks for Nx",
|
||||
"url": "https://github.com/juliangsibecas/nx-foundry"
|
||||
},
|
||||
{
|
||||
"name": "@robby-rabbitman/nx-plus-web-test-runner",
|
||||
"description": "Web Test Runner plugin for Nx workspaces.",
|
||||
"url": "https://github.com/RobbyRabbitman/nx-plus/tree/main/libs/web-test-runner"
|
||||
},
|
||||
{
|
||||
"name": "@aws/nx-plugin",
|
||||
"description": "Nx Plugin for AWS: Accelerate building cloud-native applications with AWS",
|
||||
|
||||
@@ -50,8 +50,8 @@ There will be more content around choosing which style and even how to mix the t
|
||||
|
||||
We also updated our docs to have two super short tutorials that illustrate the two approaches:
|
||||
|
||||
- [/getting-started/tutorials/typescript-packages-tutorial](/getting-started/tutorials/typescript-packages-tutorial)
|
||||
- [/getting-started/tutorials/react-monorepo-tutorial](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
- [/tutorials/1-ts-packages/1t-introduction/1-welcome](/tutorials/1-ts-packages/1t-introduction/1-welcome)
|
||||
- [/tutorials/2-react-monorepo/1r-introduction/1-welcome](/tutorials/2-react-monorepo/1r-introduction/1-welcome)
|
||||
|
||||
You can also read more about the concept here: [/deprecated/integrated-vs-package-based](/deprecated/integrated-vs-package-based)
|
||||
|
||||
@@ -179,9 +179,9 @@ It is an ongoing process, and we have a lot of content to cover! We follow the [
|
||||
- you want to learn something new ("Tutorial" section) or
|
||||
- you want a solution to a specific problem ("Recipes" section).
|
||||
|
||||
Besides the two new [package-based](/getting-started/tutorials/typescript-packages-tutorial) and [integrated style tutorials](/getting-started/tutorials/react-monorepo-tutorial) we also have two brand new reworked tutorials
|
||||
Besides the two new [package-based](/tutorials/1-ts-packages/1t-introduction/1-welcome) and [integrated style tutorials](/tutorials/2-react-monorepo/1r-introduction/1-welcome) we also have two brand new reworked tutorials
|
||||
|
||||
- [/getting-started/tutorials](/getting-started/tutorials)
|
||||
- [/tutorials](/tutorials)
|
||||
|
||||
Stay tuned for more updates to come.
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ You can pass `--vite=false` if you still want to keep the Webpack configuration
|
||||
|
||||
## Generating a Tailwind Setup
|
||||
|
||||
Once you have a [Nx-based React](/getting-started/tutorials/react-monorepo-tutorial) setup, adding Tailwind is as easy as running:
|
||||
Once you have a [Nx-based React](/tutorials/2-react-monorepo/1r-introduction/1-welcome) setup, adding Tailwind is as easy as running:
|
||||
|
||||
```shell
|
||||
$ npx nx g @nrwl/react:setup-tailwind
|
||||
@@ -79,7 +79,7 @@ You'll get
|
||||
|
||||
You should be all setup and ready now! Here are some related resources to explore:
|
||||
|
||||
- [Nx docs: React Monorepo tutorial](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
- [Nx docs: React Monorepo tutorial](/tutorials/2-react-monorepo/1r-introduction/1-welcome)
|
||||
- [Youtube: Is CRA Dead](https://youtu.be/fkTz6KJxhhE)
|
||||
- [Nx docs: Migrate CRA to React and Vite](/recipes/adopting-nx/adding-to-existing-project)
|
||||
|
||||
|
||||
@@ -636,7 +636,7 @@ This should give you a good insight into how to get started. But there's more to
|
||||
- We could also include "[executors](/extending-nx/recipes/local-executors)", which are wrappers around tasks to abstract the lower-level details of it
|
||||
- etc.
|
||||
|
||||
Now clearly this was a simple example of how you could build your own CRA using Nx. If you want to see a real-world React setup powered by Nx, check out our React Tutorial: [/getting-started/tutorials/react-monorepo-tutorial](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
Now clearly this was a simple example of how you could build your own CRA using Nx. If you want to see a real-world React setup powered by Nx, check out our React Tutorial: [/tutorials/2-react-monorepo/1r-introduction/1-welcome](/tutorials/2-react-monorepo/1r-introduction/1-welcome)
|
||||
|
||||
## Learn more
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ Juri also dives deeper into efforts from the team to provide high quality educat
|
||||
|
||||
|
||||
|
||||
This makes it easier to find keep the content organized and focused and makes it easier for the reader to choose between solution-oriented [recipes](/recipes) vs learning-oriented [tutorials](/getting-started/tutorials).
|
||||
This makes it easier to find keep the content organized and focused and makes it easier for the reader to choose between solution-oriented [recipes](/recipes) vs learning-oriented [tutorials](/tutorials).
|
||||
|
||||
The Nx team not only produces written content, but also video content mainly on the [Nx YouTube Channel](https://www.youtube.com/@nxdevtools). Juri shows some of the growth stats, with the channel now having more than 14k subscribers and around 3.7k hours of watch time per month. The channel serves mostly short-form videos about new releases, highlighting new features as well as longer-form tutorial videos.
|
||||
|
||||
|
||||
@@ -315,7 +315,7 @@ We also poured a lot of [effort into the docs](/getting-started/intro). We restr
|
||||
|
||||
- [**Concept docs**](/concepts) — which explain some of the inner workings and mental model behind certain features. Like [how caching works](/concepts/how-caching-works).
|
||||
- [**Recipes**](/recipes) — which are solution oriented. You already know how to cook, we provide the exact recipe for it.
|
||||
- [**Tutorials**](/getting-started/tutorials) — for when you just want to sit down and follow along, step by step to learn how to use Nx in a certain context.
|
||||
- [**Tutorials**](/tutorials) — for when you just want to sit down and follow along, step by step to learn how to use Nx in a certain context.
|
||||
- [**Reference**](/reference) and [**API docs**](/nx-api) — pure, raw and to the point.
|
||||
|
||||
We created a brand new ["Why Nx"](/getting-started/why-nx) page explaining the overall architecture of Nx including a [brand new video](https://www.youtube.com/watch?v=-_4WMl-Fn0w) giving you a holistic overview of what Nx is capable of.
|
||||
|
||||
@@ -52,7 +52,7 @@ Emily, the engineer that worked on this effort, posted an entire article where y
|
||||
|
||||
Thanks to the benefits of Project Crystal - which allows us to determine information to create Nx Tasks based on the way your Gradle projects are setup - by adding this plugin, it makes it easy to add Gradle into an existing workspace without needing any Nx-specific configuration.
|
||||
|
||||
In addition, you can now find [a new tutorial on using Nx with Gradle](/getting-started/tutorials/gradle-tutorial) which will expand on the [Spring framework](https://spring.io/)'s tutorial for multi-module projects and show you how Nx further enhances the developer experience of that workspace. This tutorial takes you all the way through setting up your CI pipeline with Nx Cloud, so be sure to check it out!
|
||||
In addition, you can now find [a new tutorial on using Nx with Gradle](/tutorials/4-gradle/1g-introduction/1-welcome) which will expand on the [Spring framework](https://spring.io/)'s tutorial for multi-module projects and show you how Nx further enhances the developer experience of that workspace. This tutorial takes you all the way through setting up your CI pipeline with Nx Cloud, so be sure to check it out!
|
||||
|
||||
As an editorial note, this Gradle plugin is a big step for Nx, as it represents the first major step we're taking outside of the Javascript ecosystem. This has always been the goal: to robustly support monorepos and full-stack development, even across language and ecosystem barriers. We're using this Gradle plugin internally for our closed-sourced projects (in particular Nx Cloud) and in [Nx Console](https://github.com/nrwl/nx-console/blob/master/package.json#L74) and we're very proud of this plugin and all that it represents.
|
||||
|
||||
|
||||
@@ -130,7 +130,7 @@ Read all about how to [configure Codeowners for your project in our docs](/nx-en
|
||||
|
||||
We're releasing the `@nx/conformance` plugin in an early preview. This new package focuses specifically on the maintainability of your monorepo. It allows you to encode your organization's standards so they can be enforced automatically. In this first version, the workspace conformance package ships with:
|
||||
|
||||
- [Enforce Module Boundaries](/nx-api/conformance#enforce-module-boundaries): Similar to the Nx ESLint [Enforce Module Boundaries rule](https://nx-dev-git-docs-powerpack-nrwl.vercel.app/features/enforce-module-boundaries), but enforces boundaries on every project dependency, not just those created from TypeScript imports or `package.json` dependencies.
|
||||
- [Enforce Module Boundaries](/nx-api/conformance#enforce-module-boundaries): Similar to the Nx ESLint [Enforce Module Boundaries rule](/features/enforce-module-boundaries), but enforces boundaries on every project dependency, not just those created from TypeScript imports or `package.json` dependencies.
|
||||
- [Ensure Owners](/nx-api/conformance#ensure-owners): Requires every project to have an owner defined for the `@nx/owners` plugin.
|
||||
|
||||
To get started, install the following package:
|
||||
|
||||
@@ -103,7 +103,7 @@ Gradle projects were traditionally tricky to manage alongside JavaScript librari
|
||||
|
||||
**Composite Build Support** takes this further by pulling in dependencies from composite builds and reflecting them in the task graph. This release reflects our larger goal of breaking down barriers between ecosystems. Nx aims to enable efficient workflows across different languages and technologies, moving closer to a seamless polyglot monorepo experience.
|
||||
|
||||
For more details, check out the blog post ["Manage Your Gradle Project using Nx"](/blog/manage-your-gradle-project-using-nx) and our [Gradle tutorial](/getting-started/tutorials/gradle-tutorial).
|
||||
For more details, check out the blog post ["Manage Your Gradle Project using Nx"](/blog/manage-your-gradle-project-using-nx) and our [Gradle tutorial](/tutorials/4-gradle/1g-introduction/1-welcome).
|
||||
|
||||
### Nx Import
|
||||
|
||||
|
||||
@@ -206,14 +206,14 @@ Given that the primary goal for Angular Rspack is to provide a faster build syst
|
||||
|
||||
The following are known limitations and missing features of Angular Rspack:
|
||||
|
||||
- Static Site Generation (SSG) is not supported.
|
||||
- Angular's built-in support for Internationalization (i18n) is not supported.
|
||||
- Static Site Generation (SSG) is not supported. _**UPDATE**: As of Angular Rspack version 20.9, SSG is supported._
|
||||
- Angular's built-in support for Internationalization (i18n) is not supported. _**UPDATE**: As of Angular Rspack version 20.8, i18n is supported._
|
||||
- Server Routing is not supported - still experimental in Angular currently.
|
||||
- App Engine APIs are not supported - still experimental in Angular currently.
|
||||
- Optimization is not currently 1:1 with Angular's optimization - however, there are still great optimizations that are made.
|
||||
- Styles optimization for `inline-critical` and `remove-special-comments` are not yet implemented.
|
||||
- Inlining of fonts is not yet implemented.
|
||||
- Web Workers are not fully supported.
|
||||
- Web Workers are not fully supported. _**UPDATE**: As of Angular Rspack version 20.8, Web Workers are supported._
|
||||
- Hot Module Replacement (HMR) is partially supported.
|
||||
|
||||
If you have any other missing features or limitations, please [let us know](https://github.com/nrwl/angular-rspack/issues/new).
|
||||
|
||||
@@ -131,6 +131,9 @@ It’s been great to see the progress on Angular Rspack so far, but it’s not d
|
||||
- Static Site Generation (SSG) support
|
||||
- and more!
|
||||
|
||||
**[UPDATE - 2025-04-25]** - We've released version 20.8 of Angular Rspack that includes support for i18n.
|
||||
**[UPDATE - 2025-05-06]** - We've released version 20.9 of Angular Rspack that includes support for SSG.
|
||||
|
||||
Stay tuned to our socials to stay up to date on the latest Angular Rspack news!
|
||||
|
||||
- 🧠 [**Nx Docs**](/getting-started/intro)
|
||||
|
||||
@@ -0,0 +1,195 @@
|
||||
---
|
||||
title: 'Nx 21 Release: Continuous tasks and Terminal UI lead the way'
|
||||
slug: nx-21-release
|
||||
authors: ['Philip Fulcher']
|
||||
tags: ['nx', 'release']
|
||||
cover_image: /blog/images/2025-05-05/header.avif
|
||||
description: 'Discover the latest in Nx 21, featuring continuous tasks and the new Terminal UI'
|
||||
youtubeUrl: https://youtu.be/9zsncTxfcl4
|
||||
---
|
||||
|
||||
{% callout type="deepdive" title="Nx 21 Launch Week" expanded=true %}
|
||||
|
||||
This article is part of the Nx 21 Launch Week series:
|
||||
|
||||
- **Nx 21 Release: Continuous tasks and Terminal UI lead the way**
|
||||
- [Introducing Migrate UI in Nx Console](/blog/migrate-ui)
|
||||
- [New and Improved Module Federation Experience](/blog/improved-module-federation)
|
||||
- Continuous tasks are a huge DX improvement
|
||||
- A New UI For The Humble Terminal
|
||||
|
||||
{% /callout %}
|
||||
|
||||
Welcome to Nx 21 Launch Week! Nx 21 is here with some of the highest-impact changes we've ever built. We're really excited to share what we've been cooking up, so we'll be following up with more details throughout the week.
|
||||
|
||||
{% toc /%}
|
||||
|
||||
## ICYMI: Updates from Nx 20
|
||||
|
||||
Before we dive into the newest features of Nx 21, make sure you catch these updates that happened during Nx 20:
|
||||
|
||||
- [TypeScript Project References](/blog/new-nx-experience-for-typescript-monorepos) for Monorepos
|
||||
- [`@nx/rspack` graduates from labs](/blog/announcing-nx-20#nxrspack-graduates-from-labs)
|
||||
- [@nx/rspack-angular enables rspack builds for Angular](/blog/using-rspack-with-angular)
|
||||
- [nx import](/blog/announcing-nx-20#importing-existing-projects) allows you to import existing projects into an Nx workspace
|
||||
- [Local caching is now database-driven](/blog/announcing-nx-20#caching-now-with-databases)
|
||||
- [MCP server released](/blog/nx-mcp-vscode-copilot)
|
||||
|
||||
## Continuous tasks
|
||||
|
||||
During the development of Nx 20, we started an [RFC for continuous tasks](https://github.com/nrwl/nx/discussions/29025). After gathering feedback from the community, continuous tasks are here to make many workflows in your workspace much easier to implement.
|
||||
|
||||
Many of the tasks in your workspace are finite: they run, produce an output, and shut down on their own. **Continuous tasks** are long-lived tasks: they run until interrupted by an outside input. These are tasks like serving your application or running tests in watch mode. While Nx has always supported running these tasks, you couldn't [configure a task pipeline](/concepts/task-pipeline-configuration). For example, you could serve your backend and frontend separately, but you couldn't easily configure your backend to be served whenever your frontend is served. There are always options like opening two separate terminals to run the tasks or setting up a specific script or task for running these in parallel. But the DX has always been lacking.
|
||||
|
||||
Now, tasks can be marked as continuous, and other tasks can depend on them. Nx will no longer wait for these tasks to shut down before invoking the tasks that depend on them. Let's wire one up as an example: a frontend that depends on a backend running to function. Assuming we run a `dev` target from our `frontend` project, and a `serve` target from our `api` project, we configure this on the frontend project like this:
|
||||
|
||||
```json {% fileName="apps/myfrontendapp/package.json" %}
|
||||
{
|
||||
"nx": {
|
||||
"name": "frontend",
|
||||
"targets": {
|
||||
"dev": {
|
||||
"dependsOn": [{ "projects": ["api"], "target": "serve" }]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The `frontend:dev` task now depends on `api:serve`. We must also ensure the `api:serve` target is flagged as continuous. We've already flagged tasks as continuous if you're using [inferred tasks](/concepts/inferred-tasks).
|
||||
|
||||
If your target uses an executor, you need to flag those targets as continuous yourself. This is as easy as adding `continuous: true` to the target configuration like so:
|
||||
|
||||
```json {% fileName="apps/myfrontendapp/package.json" %}
|
||||
{
|
||||
"nx": {
|
||||
"targets": {
|
||||
"serve": {
|
||||
"executor": "@nx/esbuild:esbuild",
|
||||
"continuous": true,
|
||||
...
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Or if your target uses a custom command:
|
||||
|
||||
```json {% fileName="apps/myfrontendapp/package.json" %}
|
||||
{
|
||||
"nx": {
|
||||
"targets": {
|
||||
"serve": {
|
||||
"command": "astro dev",
|
||||
"continuous": true
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Now serve the frontend with `nx serve frontend`. You'll see the `backend` project spin-up in parallel with the frontend.
|
||||
|
||||
This opens up tons of opportunities to better configure your task pipelines, such as:
|
||||
|
||||
- Start servers required for an e2e test suite to run (both frontend and backend)
|
||||
- For any application, `serve` can depend on code generator tasks in watch mode
|
||||
- `serve` can also depend on `watch-deps` in order to watch buildable libraries for changes
|
||||
|
||||
We'll have more details on this as part of our Nx 21 Launch Week, so keep your eyes open for more.
|
||||
|
||||
## Terminal UI
|
||||
|
||||
|
||||
|
||||
Continuous tasks are a massive improvement to your DX in a monorepo. Still, they also bring a challenge: now that we're running multiple tasks in parallel, how do we handle the logs from those continuous tasks?
|
||||
|
||||
You've encountered a similar problem using `affected` or `run-many`. When you run multiple tasks simultaneously, finding the logs for one particular task can be tricky. Nx Cloud has previously solved this problem with its structured logs, but continuous tasks demanded a new solution that lives in your terminal. Enter the Terminal UI.
|
||||
|
||||
Our new Terminal UI (TUI) takes over whenever you run a task in Nx. Rather than just seeing an output of logs, you'll see the currently running tasks in one panel with log outputs for the selected task appearing in a separate panel. You can navigate the TUI with the arrow keys or h/j/k/l Vim-style navigation. Pressing the `?` will bring up the keyboard shortcut list, and pressing `q` will exit the TUI.
|
||||
|
||||
This is one of the most significant changes to how users interact with Nx daily, and we're excited to share more about it later this week.
|
||||
|
||||
{% callout type="note" title="Windows Compatibility" %}
|
||||
The initial Nx 21 release disables the Terminal UI on Windows. We are currently working on Windows support, so stay tuned.
|
||||
{% /callout %}
|
||||
|
||||
## @nx/gradle is blazingly fast
|
||||
|
||||
We've been iterating on our `@nx/gradle` plugin for a while now. We're bringing two considerable enhancements to this plugin that make it perform better than ever before.
|
||||
|
||||
First, we've introduced a Gradle plugin that provides Nx with project graph information. Previously, we relied on the Project Report plugin for Gradle to provide this information. However, this tool didn't provide enough information for Nx, and it also had a static output. Our new project graph plugin is built from the ground up to support what Nx needs faster than before.
|
||||
|
||||
Secondly, Nx now sends tasks to Gradle in batches rather than one by one. This speeds up task execution and better aligns with how Gradle expects to run things.
|
||||
|
||||
To test how performance improved, we forked the Spring Boot repo and converted it to use Nx. With the latest version of our plugin, we were able to **reduce CI times from 1 hour 44 minutes to 42 minutes, a 59.6% reduction in time**.
|
||||
|
||||
These two changes make the `@nx/gradle` plugin better than ever for managing your Gradle plugins. Be sure to explore this new plugin if you're using Gradle, and watch out for what else we're bringing to the Java ecosystem, later this year.
|
||||
|
||||
[Check out the docs for more details.](/nx-api/gradle)
|
||||
|
||||
## Migrate UI in Nx Console makes migrations easier than ever
|
||||
|
||||
|
||||
|
||||
[Automated migrations](/features/automate-updating-dependencies) have always been a massively valuable part of Nx. Previously, we [added migration docs](/nx-api/angular/migrations) to better inform you of what's happening during these migrations. Now, we're bringing the migration process to the Nx Console so that you can step through migrations even easier than before.
|
||||
|
||||
After updating to the latest version of Nx Console, you'll see a **new Migrate UI panel**. Through this, you'll be able to start a migration, install packages, and then individually approve different migrations. You'll be able to see the change before approving and moving on to the next one. This allows for better visibility into each change and helps you stay informed. As always, you'll have an option to commit after each change or squash them together into a single commit.
|
||||
|
||||
This is another item we're excited to talk about more later this week.
|
||||
|
||||
## React Router plugin
|
||||
|
||||
[React Router 7](https://reactrouter.com/) is a big step for the library, bringing in some of the best ideas from Remix. Version 7 introduces "[modes,](https://reactrouter.com/start/modes)” which allow users to use increasingly rich feature sets. The declarative and data modes can be used as a library and built using any existing React build pipeline you have. The new framework mode is closer to Remix and needs a specific build tool.
|
||||
|
||||
If you're using React Router in declarative or data mode, you can continue using the existing workflows that build your React app.
|
||||
|
||||
However, if you're ready to start a new app using the framework mode in React Router or need to migrate a Remix app to React Router, we've got you covered. Our new [inferred task plugin](/recipes/react/react-router) will handle running the React Router CLI based on projects with a React Router config file. If you're migrating from Remix, follow the React Router team's [migration guidance](https://reactrouter.com/upgrading/remix). Once migrated, you can remove the Remix plugin and use the React Router plugin.
|
||||
|
||||
## Updated release versioning
|
||||
|
||||
In Nx 21, the implementation details of versioning were rewritten to enhance flexibility and allow for better cross-ecosystem support. This rewrite has been primarily made to make the implementation more flexible and more extensible. Now you can define custom version actions to provide Nx release versioning support for non-JavaScript packages, whether that's Java, Go, Rust, or other languages. The new APIs are flexible enough that you can even run versioning across different packages written in different technologies in the monorepo. So this new update is really a door-opener for polyglot workspaces.
|
||||
|
||||
An automated migration will update your configuration to the new format. You can still opt into the old versioning by setting `release.version.useLegacyVersioning` to `true`, which will keep the original configuration structure and behavior. In Nx 22, the legacy versioning implementation will be removed entirely, so this should only be done temporarily to ease the transition.
|
||||
|
||||
This is just the first release with these new APIs, and we're going to talk more about it and provide more examples in the coming months. [Check out the docs for more details.](/recipes/nx-release/updating-version-references)
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
### Minimum version of Node is now 20.19
|
||||
|
||||
With Node 18 entering end-of-life, we have increased the minimum version of Node to 20.19.
|
||||
|
||||
### Older task runners API removed
|
||||
|
||||
Nx 21 [removes the deprecated custom task runners API](/deprecated/custom-tasks-runner), replacing it with the [`preTasksExecution` and `postTaskExecution` hooks](/recipes/nx-release/updating-version-references).
|
||||
|
||||
This allows you to still hook into the task running pipeline, but in a well-defined way that provides enough flexibility to the Nx core to rewrite internal implementations and apply performance optimizations to the task running pipeline.
|
||||
|
||||
We're aware that some organizations leveraged custom task runners for implementing self-hosted distributed caches. For these cases, we have provided a free alternative. Visit [our remote caching page](/remote-cache) for more details.
|
||||
|
||||
Read more about [the deprecated custom task runners API](/deprecated/custom-tasks-runner) and the [self-hosted caching options](/recipes/running-tasks/self-hosted-caching) in our docs.
|
||||
|
||||
### `useLegacyCache` removed
|
||||
|
||||
As [announced previously](/blog/announcing-nx-20#caching-now-with-databases), the `useLegacyCache` option has been removed. All workspaces will be migrated to remove this option and use the new database-powered local cache.
|
||||
|
||||
### `createNodesV1` removed
|
||||
|
||||
If you're [creating Nx plugins that infer tasks](/extending-nx/recipes/project-graph-plugins), be sure they're migrated to `createNodesV2` to support newer versions of Nx.
|
||||
|
||||
## What comes next
|
||||
|
||||
As always, there are far too many updates to talk about every single one. Check our full [release notes](https://github.com/nrwl/nx/releases/tag/21.0.0) on GitHub for all the nitty gritty details.
|
||||
|
||||
For the rest of Launch Week, we'll be doing deep dives on some of our biggest features. You won't want to miss it, so keep an eye on our [socials](/community) and [YouTube channel](https://www.youtube.com/@nxdevtools).
|
||||
|
||||
Learn more:
|
||||
|
||||
- 🧠 [Nx AI Docs](/features/enhance-AI)
|
||||
- 🌩️ [Nx Cloud](/nx-cloud)
|
||||
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
|
||||
- 👩💻 [Nx Console GitHub](https://github.com/nrwl/nx-console)
|
||||
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
|
||||
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: 'A New UI for Nx Migration'
|
||||
slug: migrate-ui
|
||||
authors: ['Jack Hsu']
|
||||
tags: ['nx', 'nx-console']
|
||||
cover_image: /blog/images/2025-05-07/migrate-ui-header.avif
|
||||
description: 'Introducing the new Migrate UI in Nx Console, a visual interface that simplifies the migration process.'
|
||||
youtubeUrl: 'https://youtu.be/5xe9ziAV3zg'
|
||||
---
|
||||
|
||||
{% callout type="deepdive" title="Nx 21 Launch Week" expanded=true %}
|
||||
|
||||
This article is part of the Nx 21 Launch Week series:
|
||||
|
||||
- [Nx 21 Release: Continuous tasks and Terminal UI lead the way](/blog/nx-21-release)
|
||||
- **Introducing Migrate UI in Nx Console**
|
||||
- [New and Improved Module Federation Experience](/blog/improved-module-federation)
|
||||
- Continuous tasks are a huge DX improvement
|
||||
- A New UI For The Humble Terminal
|
||||
|
||||
{% /callout %}
|
||||
|
||||
Keeping your dependencies up to date is crucial for maintaining a healthy codebase. Nx provides the [`migrate`](/features/automate-updating-dependencies) command to help with this important part of the development process. And although it is a [very powerful and flexible tool](/recipes/tips-n-tricks/advanced-update), most users may not be fully aware of its capabilities.
|
||||
|
||||
We're excited to introduce the [**Migrate UI**](/recipes/nx-console/console-migrate-ui) in Nx Console, a new feature that simplifies the migration process. This visual interface guides you through each step of the migration, giving you full visibility and control over what's happening to your codebase.
|
||||
|
||||
## Why We Built the Migrate UI
|
||||
|
||||
Automated migrations have always been a core strength of Nx. Migrations help you update packages, configuration files, and even your source code to match new versions. However, running them from the command line is not always straightforward. The simplest way to update your workspace is to run the following commands:
|
||||
|
||||
```plaintext
|
||||
# Check the latest version of Nx and update package.json
|
||||
# Nx creates the `migrations.json` that contains pending migrations
|
||||
nx migrate latest
|
||||
|
||||
# Accept the `package.json` changes by running install
|
||||
npm install
|
||||
|
||||
# Run all migrations in the generated `migrations.json` file
|
||||
nx migrate --run-migrations
|
||||
```
|
||||
|
||||
After running the above, you are left with updated packages and file changes. If you encounter any issues, it might take some investigation to figure out which migration caused the problem.
|
||||
|
||||
The Migrate UI makes this process easier by:
|
||||
|
||||
1. **Visualizing the process**: See what files are affected by each migration in isolation
|
||||
2. **Providing control**: Review, verify, and approve each migration step before committing it
|
||||
3. **Simplifying troubleshooting**: Get clear error messages when something goes wrong, with a link to bring up the migration source code
|
||||
|
||||
## How the Migrate UI Works
|
||||
|
||||
### Starting a Migration
|
||||
|
||||
When an update to Nx is available, a badge appears on the Nx Console icon in your Activity Bar. From the Nx Console view, you'll see a "Nx Migrate" section in the sidebar. Clicking "Start Migration" begins the process.
|
||||
|
||||
|
||||
|
||||
By default, the migration upgrades to the recommended Nx version (the latest version of the next major release). This method ensures you upgrade one major version at a time to avoid potential breakages. You can also customize the target version by clicking the pencil icon and providing a specific version.
|
||||
|
||||
### Reviewing Package Changes
|
||||
|
||||
The first step in any migration is updating your `package.json`. Once you start the migration, Nx Console runs the `nx migrate` command to update your dependency versions and generate a `migrations.json` file. Before proceeding, the Migrate UI shows you exactly what changes will be made to your dependencies.
|
||||
|
||||
|
||||
|
||||
This review step gives you a chance to inspect and confirm these changes before anything is installed, ensuring there are no surprises. You can see which packages will be updated and to what versions, helping you make an informed decision about proceeding with the migration.
|
||||
|
||||
### Step-by-Step Migration
|
||||
|
||||
After confirming the `package.json` changes, the Migrate UI opens and guides you through each migration action. Each migration will be executed in the order they appear in the `migrations.json` file.
|
||||
|
||||
|
||||
|
||||
For each migration step:
|
||||
|
||||
1. You'll see a description of what the migration does and which package it belongs to, as well as a link to the migration's source code
|
||||
2. If the migration makes file changes, they will be listed with links to to view the diff
|
||||
3. You can choose to `Accept` the changes to proceed or `Undo` them if something doesn't look right
|
||||
4. If there's an error, the process pauses so you can inspect the error details and choose to fix or skip the migration
|
||||
|
||||
This step-by-step approach means you're never left wondering what's happening to your codebase. You can see each change, understand its purpose, and make informed decisions about whether to apply it. The visual diff view is particularly helpful for understanding complex or larger code changes.
|
||||
|
||||
The step-by-step approach also allows you to check that projects continue to function correctly. If something is wrong, the changeset is much smaller than if all migrations were applied at once, making debugging easier.
|
||||
|
||||
### Finalizing with Confidence
|
||||
|
||||
When all migrations are complete, you can finish the process with a single click. The Migrate UI provides options for how to finalize your migration.
|
||||
|
||||
|
||||
|
||||
By default, all commits created during the migration are squashed together into a single commit, which keeps your git history clean. However, you can also opt to preserve the individual commits if you prefer a more detailed history of the changes made.
|
||||
|
||||
You'll be prompted for a final git commit message. Once entered, the migration process is completed and ready for a pull-request.
|
||||
|
||||
## Getting Started with Migrate UI
|
||||
|
||||
The Migrate UI is available now in the latest version of Nx Console for VSCode and Cursor editors. To use it, make sure you have the latest version of [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) installed.
|
||||
|
||||
We'd love to hear your feedback on the Migrate UI! Try it out and let us know what you think through [GitHub issues](https://github.com/nrwl/nx-console/issues) or our [community channels](/community).
|
||||
@@ -0,0 +1,141 @@
|
||||
---
|
||||
title: 'New and Improved Module Federation Experience with Nx'
|
||||
slug: improved-module-federation
|
||||
authors: ['Colum Ferry']
|
||||
tags: ['nx', 'module-federation']
|
||||
cover_image: /blog/images/2025-05-08/module-federation.avif
|
||||
description: 'Nx 21 introduces native support for Module Federation with Inferred Tasks and Continuous Tasks, enabling streamlined Rspack configs and seamless multi-app serving for improved developer experience.'
|
||||
---
|
||||
|
||||
{% callout type="deepdive" title="Nx 21 Launch Week" expanded=true %}
|
||||
|
||||
- [Nx 21 Release: Continuous tasks and Terminal UI lead the way](/blog/nx-21-release)
|
||||
- [Introducing Migrate UI in Nx Console](/blog/migrate-ui)
|
||||
- **New and Improved Module Federation Experience**
|
||||
- Continuous tasks are a huge DX improvement
|
||||
- A New UI For The Humble Terminal
|
||||
|
||||
{% /callout %}
|
||||
|
||||
Nx 21 saw the introduction of many new and exciting features. [Continuous Tasks](/reference/project-configuration#continuous) was one such feature that I found particularly exciting because of what it could mean for the Developer Experience (DX) with Module Federation.
|
||||
|
||||
However, before even being able to contemplate that, a different feature needed to be completed first: the ability to use Module Federation with Nx’s [Inferred Tasks](/concepts/inferred-tasks).
|
||||
|
||||
{% toc /%}
|
||||
|
||||
## Inferred Tasks with Module Federation
|
||||
|
||||
We have introduced three new [Rspack](https://rspack.dev) Plugins for Module Federation that can be used with Nx.
|
||||
|
||||
- [NxModuleFederationPlugin](/nx-api/module-federation/documents/nx-module-federation-plugin): Gathers information from the Nx Workspace to correctly configure `rspack.ModuleFederationPlugin`
|
||||
- [NxModuleFederationDevServerPlugin](/nx-api/module-federation/documents/nx-module-federation-dev-server-plugin): Used to handle the static-serving of non-dev remotes for CSR applications
|
||||
- [NxModuleFederationSSRDevServerPlugin](/nx-api/module-federation/documents/nx-module-federation-dev-server-plugin#server-side-rendering): Used to handle the static-serving of non-dev remotes for SSR applications
|
||||
|
||||
These are true Rspack Plugins that should be added to the `plugins: []` of an `rspack.config` file.
|
||||
|
||||
Their intention is to replace `withModuleFederation` helpers and `module-federation-dev-server` executors we used to provide the Nx Module Federation Experience previously.
|
||||
|
||||
With these plugins, we can now set up a very standard `rspack.config` file that can be used with the `@nx/rspack/plugin` Inference Plugin - or you could even just run `rspack build` or `rspack serve`.
|
||||
|
||||
Not only does this mean that the config files that we create for your Module Federation projects are now compliant with the underlying tooling, but it has enabled us to take full advantage of Continuous Tasks.
|
||||
|
||||
## Continuous Tasks with Module Federation
|
||||
|
||||
This is where things get interesting. Continuous Tasks in Nx allows for tasks to depend on tasks that may not end. The Nx Module Federation Experience has always relied on the serving of multiple applications.
|
||||
|
||||
Previously, you would run `nx serve shell --devRemotes=remote1` where `shell` is your host application and `remote1` is the remote application that you or a feature team would be currently working on to allow for HMR with `remote1`.
|
||||
|
||||
Under the hood this would start up the `webpack-dev-server` for both `shell` and `remote1`.
|
||||
|
||||
However, it always felt _slightly_ strange for individual contributors on feature teams to be told they cannot run “their" application by simply running `nx serve remote1` .
|
||||
|
||||
Well, now they can!
|
||||
|
||||
With Continuous Tasks and the new `NxModuleFederationDevServer` plugins, we can generate remote applications that `dependsOn["shell:serve"]`.
|
||||
|
||||
Running `nx serve remote1` will serve **both** `remote1` and `shell`!
|
||||
|
||||
The `NxModuleFederationDevServer` plugin for the `shell` application will check which remotes are already running and simply ignore them - serving only the remotes that are not already served.
|
||||
|
||||
## Getting Started with the New Nx Module Federation Experience
|
||||
|
||||
### 1. Create a new Nx Workspace
|
||||
|
||||
```plaintext {% command="npx create-nx-workspace@latest myorg" path="~/" %}
|
||||
|
||||
NX Let's create a new workspace [[https://nx.dev/getting-started/intro](/getting-started/intro)]
|
||||
|
||||
✔ Which stack do you want to use? · none
|
||||
✔ Would you like to use Prettier for code formatting? · Yes
|
||||
✔ Which CI provider would you like to use? · skip
|
||||
✔ Would you like remote caching to make your build faster? · skip
|
||||
|
||||
NX Creating your v21.0.0 workspace.
|
||||
|
||||
✔ Installing dependencies with npm
|
||||
✔ Successfully created the workspace: myorg.
|
||||
|
||||
NX Welcome to the Nx community! 👋
|
||||
|
||||
🌟 Star Nx on GitHub: [https://github.com/nrwl/nx](https://github.com/nrwl/nx)
|
||||
📢 Stay up to date on X: [https://x.com/nxdevtools](https://x.com/nxdevtools)
|
||||
💬 Discuss Nx on Discord: [https://go.nx.dev/community](https://go.nx.dev/community)
|
||||
|
||||
```
|
||||
|
||||
### 2. Add the `@nx/react` Plugin
|
||||
|
||||
```plaintext {% command="npx nx add @nx/react" path="~/myorg" %}
|
||||
|
||||
✔ Installing @nx/react@21.0.0
|
||||
|
||||
NX Generating @nx/react:init
|
||||
|
||||
UPDATE package.json
|
||||
UPDATE nx.json
|
||||
|
||||
added 3 packages in 1s
|
||||
|
||||
91 packages are looking for funding
|
||||
run `npm fund` for details
|
||||
✔ Initializing @nx/react...
|
||||
|
||||
NX Package @nx/react added successfully.
|
||||
|
||||
```
|
||||
|
||||
### 3. Generate Host and Remote Applications
|
||||
|
||||
```plaintext {% command="npx nx g @nx/react:host apps/shell --remotes=remote1,remote2 --bundler=rspack" path="~/myorg" %}
|
||||
|
||||
NX Generating @nx/react:host
|
||||
|
||||
✔ Which stylesheet format would you like to use? · css
|
||||
✔ Which E2E test runner would you like to use? · none
|
||||
Fetching @nx/rspack...
|
||||
Fetching @nx/jest...
|
||||
|
||||
UPDATE nx.json
|
||||
UPDATE package.json
|
||||
CREATE apps/shell/src/app/app.spec.tsx
|
||||
CREATE apps/shell/src/assets/.gitkeep
|
||||
CREATE …
|
||||
|
||||
```
|
||||
|
||||
### 4. Serve the Remote Application for Development
|
||||
|
||||
`npx nx serve remote1`
|
||||
|
||||
|
||||
|
||||
With the new [Terminal UI](/recipes/running-tasks/terminal-ui) you can very easily see the logs for each application in specific frames also.
|
||||
|
||||
## Further Reading
|
||||
|
||||
- [Module Federation and Nx](/concepts/module-federation/module-federation-and-nx)
|
||||
- [Nx Module Federation Technical Overview](/concepts/module-federation/nx-module-federation-technical-overview)
|
||||
- 🧠 [**Nx Docs**](/getting-started/intro)
|
||||
- 👩💻 [**Nx GitHub**](https://github.com/nrwl/nx)
|
||||
- 💬 [**Nx Official Discord Server**](https://go.nx.dev/community)
|
||||
- 📹 [**Nx Youtube Channel**](https://www.youtube.com/@nxdevtools)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 338 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 105 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 348 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 112 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
@@ -99,7 +99,7 @@ Print the task graph to the console:
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--output-style` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--outputStyle` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--runner` | string | This is the name of the tasks runner configured in nx.json. |
|
||||
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
|
||||
|
||||
@@ -128,7 +128,7 @@ nx release publish
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--otp` | number | A one-time password for publishing to a registry that requires 2FA. |
|
||||
| `--output-style` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--outputStyle` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--projects`, `--p` | string | Projects to run. (comma/space delimited project names and/or patterns). |
|
||||
| `--registry` | string | The registry to publish to. |
|
||||
|
||||
@@ -102,7 +102,7 @@ Print the task graph to the console:
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--output-style` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--outputStyle` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--projects`, `--p` | string | Projects to run. (comma/space delimited project names and/or patterns). |
|
||||
| `--runner` | string | This is the name of the tasks runner configured in nx.json. |
|
||||
|
||||
+19
-19
@@ -67,22 +67,22 @@ Run's a target named build:test for the myapp project. Note the quotes around th
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ------------------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--batch` | boolean | Run task(s) in batches for executors which support batches. (Default: `false`) |
|
||||
| `--configuration`, `--c` | string | This is the configuration to use when performing tasks on projects. |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--excludeTaskDependencies` | boolean | Skips running dependent tasks first. (Default: `false`) |
|
||||
| `--graph` | string | Show the task graph of the command. Pass a file path to save the graph data instead of viewing it in the browser. Pass "stdout" to print the results to the terminal. |
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--output-style` | `tui`, `dynamic`, `dynamic-legacy`, `static`, `stream`, `stream-without-prefixes`, `compact` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--project` | string | Target project. |
|
||||
| `--runner` | string | This is the name of the tasks runner configured in nx.json. |
|
||||
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
| Option | Type | Description |
|
||||
| ------------------------------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--batch` | boolean | Run task(s) in batches for executors which support batches. (Default: `false`) |
|
||||
| `--configuration`, `--c` | string | This is the configuration to use when performing tasks on projects. |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--excludeTaskDependencies` | boolean | Skips running dependent tasks first. (Default: `false`) |
|
||||
| `--graph` | string | Show the task graph of the command. Pass a file path to save the graph data instead of viewing it in the browser. Pass "stdout" to print the results to the terminal. |
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--outputStyle` | `tui`, `dynamic`, `dynamic-legacy`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--project` | string | Target project. |
|
||||
| `--runner` | string | This is the name of the tasks runner configured in nx.json. |
|
||||
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||
@@ -42,39 +42,39 @@
|
||||
},
|
||||
{
|
||||
"name": "Tutorials",
|
||||
"path": "/getting-started/tutorials",
|
||||
"path": "/tutorials",
|
||||
"id": "tutorials",
|
||||
"isExternal": false,
|
||||
"children": [
|
||||
{
|
||||
"name": "TypeScript Monorepo",
|
||||
"path": "/getting-started/tutorials/typescript-packages-tutorial",
|
||||
"path": "/tutorials/1-ts-packages/1t-introduction/1-welcome",
|
||||
"id": "typescript-packages-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "React Monorepo",
|
||||
"path": "/getting-started/tutorials/react-monorepo-tutorial",
|
||||
"path": "/tutorials/2-react-monorepo/1r-introduction/1-welcome",
|
||||
"id": "react-monorepo-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Angular Monorepo",
|
||||
"path": "/getting-started/tutorials/angular-monorepo-tutorial",
|
||||
"path": "/tutorials/3-angular-monorepo/1a-introduction/1-welcome",
|
||||
"id": "angular-monorepo-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Gradle Monorepo",
|
||||
"path": "/getting-started/tutorials/gradle-tutorial",
|
||||
"path": "/tutorials/4-gradle/1g-introduction/1-welcome",
|
||||
"id": "gradle-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
}
|
||||
@@ -118,39 +118,39 @@
|
||||
},
|
||||
{
|
||||
"name": "Tutorials",
|
||||
"path": "/getting-started/tutorials",
|
||||
"path": "/tutorials",
|
||||
"id": "tutorials",
|
||||
"isExternal": false,
|
||||
"children": [
|
||||
{
|
||||
"name": "TypeScript Monorepo",
|
||||
"path": "/getting-started/tutorials/typescript-packages-tutorial",
|
||||
"path": "/tutorials/1-ts-packages/1t-introduction/1-welcome",
|
||||
"id": "typescript-packages-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "React Monorepo",
|
||||
"path": "/getting-started/tutorials/react-monorepo-tutorial",
|
||||
"path": "/tutorials/2-react-monorepo/1r-introduction/1-welcome",
|
||||
"id": "react-monorepo-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Angular Monorepo",
|
||||
"path": "/getting-started/tutorials/angular-monorepo-tutorial",
|
||||
"path": "/tutorials/3-angular-monorepo/1a-introduction/1-welcome",
|
||||
"id": "angular-monorepo-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Gradle Monorepo",
|
||||
"path": "/getting-started/tutorials/gradle-tutorial",
|
||||
"path": "/tutorials/4-gradle/1g-introduction/1-welcome",
|
||||
"id": "gradle-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
}
|
||||
@@ -159,33 +159,33 @@
|
||||
},
|
||||
{
|
||||
"name": "TypeScript Monorepo",
|
||||
"path": "/getting-started/tutorials/typescript-packages-tutorial",
|
||||
"path": "/tutorials/1-ts-packages/1t-introduction/1-welcome",
|
||||
"id": "typescript-packages-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "React Monorepo",
|
||||
"path": "/getting-started/tutorials/react-monorepo-tutorial",
|
||||
"path": "/tutorials/2-react-monorepo/1r-introduction/1-welcome",
|
||||
"id": "react-monorepo-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Angular Monorepo",
|
||||
"path": "/getting-started/tutorials/angular-monorepo-tutorial",
|
||||
"path": "/tutorials/3-angular-monorepo/1a-introduction/1-welcome",
|
||||
"id": "angular-monorepo-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
{
|
||||
"name": "Gradle Monorepo",
|
||||
"path": "/getting-started/tutorials/gradle-tutorial",
|
||||
"path": "/tutorials/4-gradle/1g-introduction/1-welcome",
|
||||
"id": "gradle-tutorial",
|
||||
"isExternal": false,
|
||||
"isExternal": true,
|
||||
"children": [],
|
||||
"disableCollapsible": false
|
||||
},
|
||||
|
||||
@@ -4751,6 +4751,16 @@
|
||||
}
|
||||
},
|
||||
"migrations": {
|
||||
"/nx-api/rspack/migrations/21.0.1-package-updates": {
|
||||
"description": "",
|
||||
"file": "generated/packages/rspack/migrations/21.0.1-package-updates.json",
|
||||
"hidden": false,
|
||||
"name": "21.0.1-package-updates",
|
||||
"version": "21.0.1-beta.0",
|
||||
"originalFilePath": "/packages/rspack",
|
||||
"path": "/nx-api/rspack/migrations/21.0.1-package-updates",
|
||||
"type": "migration"
|
||||
},
|
||||
"/nx-api/rspack/migrations/20.5.0-package-updates": {
|
||||
"description": "",
|
||||
"file": "generated/packages/rspack/migrations/20.5.0-package-updates.json",
|
||||
|
||||
@@ -62,10 +62,10 @@
|
||||
"name": "TypeScript Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/typescript-packages",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/typescript-packages-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/1-ts-packages/1t-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
@@ -73,10 +73,10 @@
|
||||
"name": "React Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/react-monorepo",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/react-monorepo-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/2-react-monorepo/1r-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
@@ -84,10 +84,10 @@
|
||||
"name": "Angular Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/angular-monorepo",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/angular-monorepo-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/3-angular-monorepo/1a-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
@@ -95,15 +95,15 @@
|
||||
"name": "Gradle Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/gradle",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/gradle-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/4-gradle/1g-introduction/1-welcome",
|
||||
"tags": []
|
||||
}
|
||||
],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials",
|
||||
"path": "/tutorials",
|
||||
"tags": []
|
||||
}
|
||||
],
|
||||
@@ -155,7 +155,7 @@
|
||||
"path": "/getting-started/editor-setup",
|
||||
"tags": ["editor-setup"]
|
||||
},
|
||||
"/getting-started/tutorials": {
|
||||
"/tutorials": {
|
||||
"id": "tutorials",
|
||||
"name": "Tutorials",
|
||||
"description": "Get started with basic information, concepts and tutorials.",
|
||||
@@ -167,10 +167,10 @@
|
||||
"name": "TypeScript Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/typescript-packages",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/typescript-packages-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/1-ts-packages/1t-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
@@ -178,10 +178,10 @@
|
||||
"name": "React Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/react-monorepo",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/react-monorepo-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/2-react-monorepo/1r-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
@@ -189,10 +189,10 @@
|
||||
"name": "Angular Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/angular-monorepo",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/angular-monorepo-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/3-angular-monorepo/1a-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
{
|
||||
@@ -200,59 +200,59 @@
|
||||
"name": "Gradle Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/gradle",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/gradle-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/4-gradle/1g-introduction/1-welcome",
|
||||
"tags": []
|
||||
}
|
||||
],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials",
|
||||
"path": "/tutorials",
|
||||
"tags": []
|
||||
},
|
||||
"/getting-started/tutorials/typescript-packages-tutorial": {
|
||||
"/tutorials/1-ts-packages/1t-introduction/1-welcome": {
|
||||
"id": "typescript-packages-tutorial",
|
||||
"name": "TypeScript Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/typescript-packages",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/typescript-packages-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/1-ts-packages/1t-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
"/getting-started/tutorials/react-monorepo-tutorial": {
|
||||
"/tutorials/2-react-monorepo/1r-introduction/1-welcome": {
|
||||
"id": "react-monorepo-tutorial",
|
||||
"name": "React Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/react-monorepo",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/react-monorepo-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/2-react-monorepo/1r-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
"/getting-started/tutorials/angular-monorepo-tutorial": {
|
||||
"/tutorials/3-angular-monorepo/1a-introduction/1-welcome": {
|
||||
"id": "angular-monorepo-tutorial",
|
||||
"name": "Angular Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/angular-monorepo",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/angular-monorepo-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/3-angular-monorepo/1a-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
"/getting-started/tutorials/gradle-tutorial": {
|
||||
"/tutorials/4-gradle/1g-introduction/1-welcome": {
|
||||
"id": "gradle-tutorial",
|
||||
"name": "Gradle Monorepo",
|
||||
"description": "",
|
||||
"mediaImage": "",
|
||||
"file": "shared/tutorials/gradle",
|
||||
"file": "",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/getting-started/tutorials/gradle-tutorial",
|
||||
"isExternal": true,
|
||||
"path": "/tutorials/4-gradle/1g-introduction/1-welcome",
|
||||
"tags": []
|
||||
},
|
||||
"/features": {
|
||||
|
||||
@@ -4719,6 +4719,16 @@
|
||||
}
|
||||
],
|
||||
"migrations": [
|
||||
{
|
||||
"description": "",
|
||||
"file": "generated/packages/rspack/migrations/21.0.1-package-updates.json",
|
||||
"hidden": false,
|
||||
"name": "21.0.1-package-updates",
|
||||
"version": "21.0.1-beta.0",
|
||||
"originalFilePath": "/packages/rspack",
|
||||
"path": "rspack/migrations/21.0.1-package-updates",
|
||||
"type": "migration"
|
||||
},
|
||||
{
|
||||
"description": "",
|
||||
"file": "generated/packages/rspack/migrations/20.5.0-package-updates.json",
|
||||
|
||||
@@ -53,5 +53,6 @@ Below is a reference table that matches versions of [Angular Rspack](/recipes/an
|
||||
|
||||
| Angular Rspack | Angular | Nx |
|
||||
| -------------- | ----------- | ------------------- |
|
||||
| ~20.8.0 | **~19.2.0** | >= 20.8.1 <= latest |
|
||||
| ~20.7.0 | **~19.2.0** | >= 20.8.1 <= latest |
|
||||
| ~20.6.0 | **~19.2.0** | >= 20.6.0 <= latest |
|
||||
|
||||
@@ -41,7 +41,7 @@ Here's a quick side-by-side overview comparing the features between the Angular
|
||||
| Advanced Generators (e.g. Module Federation, Tailwind,...) | ❌ | ✅ |
|
||||
| Integrated Tooling (Jest, Cypress, Playwright etc.) | ❌ | ✅ |
|
||||
| Support for single-project Workspaces | ✅ | ✅ |
|
||||
| First-Class [Monorepo Support](/getting-started/tutorials/angular-monorepo-tutorial) | ❌\* | ✅ |
|
||||
| First-Class [Monorepo Support](/tutorials/3-angular-monorepo/1a-introduction/1-welcome) | ❌\* | ✅ |
|
||||
| [Enforced Module Boundaries](/features/enforce-module-boundaries) | ❌ | ✅ |
|
||||
| Interactive [Project Graph](/features/explore-graph) | ❌ | ✅ |
|
||||
| Task Graph | ❌ | ✅ |
|
||||
@@ -411,4 +411,4 @@ There is also a guide describing how to [consolidate multiple Angular CLI projec
|
||||
|
||||
You can learn more about Angular & Nx by following our dedicated tutorials:
|
||||
|
||||
- [Tutorial: Building Angular Apps in an Nx Monorepo](/getting-started/tutorials/angular-monorepo-tutorial)
|
||||
- [Tutorial: Building Angular Apps in an Nx Monorepo](/tutorials/3-angular-monorepo/1a-introduction/1-welcome)
|
||||
|
||||
@@ -46,7 +46,7 @@ nx add @nx/angular
|
||||
This will install the correct version of `@nx/angular`.
|
||||
|
||||
{% callout type="note" title="Angular Tutorial" %}
|
||||
For a full tutorial experience, follow the [Angular Monorepo Tutorial](/getting-started/tutorials/angular-monorepo-tutorial)
|
||||
For a full tutorial experience, follow the [Angular Monorepo Tutorial](/tutorials/3-angular-monorepo/1a-introduction/1-welcome)
|
||||
{% /callout %}
|
||||
|
||||
## Using the Angular Plugin
|
||||
@@ -113,7 +113,7 @@ nx g @nx/angular:service apps/appName/src/lib/my-service/my-service
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [Angular Monorepo Tutorial](/getting-started/tutorials/angular-monorepo-tutorial)
|
||||
- [Angular Monorepo Tutorial](/tutorials/3-angular-monorepo/1a-introduction/1-welcome)
|
||||
- [Migrating from the Angular CLI](/recipes/angular/migration/angular)
|
||||
- [Setup Module Federation with Angular and Nx](/concepts/module-federation/faster-builds-with-module-federation)
|
||||
- [Using Tailwind CSS with Angular projects](/recipes/angular/using-tailwind-css-with-angular-projects)
|
||||
|
||||
@@ -170,7 +170,7 @@ The `@nx/gradle` plugin will automatically split your testing tasks by test clas
|
||||
|
||||
### Continuous Tasks
|
||||
|
||||
Gradle doesn't have a standard way to identify tasks which are [continuous](https://nx-dev-git-docs-gradle-publish-nrwl.vercel.app/reference/project-configuration#continuous), like `bootRun` for serving a Spring Boot project. To ensure Nx handles these continuous tasks correctly, you can explicitly mark them as continuous.
|
||||
Gradle doesn't have a standard way to identify tasks which are [continuous](/reference/project-configuration#continuous), like `bootRun` for serving a Spring Boot project. To ensure Nx handles these continuous tasks correctly, you can explicitly mark them as continuous.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="nx.json" %}
|
||||
|
||||
@@ -79,6 +79,12 @@
|
||||
"runtimeTsconfigFileName": {
|
||||
"type": "string",
|
||||
"description": "The name of the project's tsconfig file that includes the runtime source files. If not provided, it will default to `tsconfig.lib.json` for libraries and `tsconfig.app.json` for applications."
|
||||
},
|
||||
"keepExistingVersions": {
|
||||
"type": "boolean",
|
||||
"x-priority": "internal",
|
||||
"description": "Keep existing dependencies versions",
|
||||
"default": true
|
||||
}
|
||||
},
|
||||
"required": [],
|
||||
|
||||
@@ -99,7 +99,7 @@ Print the task graph to the console:
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--output-style` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--outputStyle` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--runner` | string | This is the name of the tasks runner configured in nx.json. |
|
||||
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
|
||||
|
||||
@@ -128,7 +128,7 @@ nx release publish
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--otp` | number | A one-time password for publishing to a registry that requires 2FA. |
|
||||
| `--output-style` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--outputStyle` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--projects`, `--p` | string | Projects to run. (comma/space delimited project names and/or patterns). |
|
||||
| `--registry` | string | The registry to publish to. |
|
||||
|
||||
@@ -102,7 +102,7 @@ Print the task graph to the console:
|
||||
| `--help` | boolean | Show help. |
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--output-style` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--outputStyle` | `dynamic-legacy`, `dynamic`, `tui`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--projects`, `--p` | string | Projects to run. (comma/space delimited project names and/or patterns). |
|
||||
| `--runner` | string | This is the name of the tasks runner configured in nx.json. |
|
||||
|
||||
@@ -67,22 +67,22 @@ Run's a target named build:test for the myapp project. Note the quotes around th
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Type | Description |
|
||||
| ------------------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--batch` | boolean | Run task(s) in batches for executors which support batches. (Default: `false`) |
|
||||
| `--configuration`, `--c` | string | This is the configuration to use when performing tasks on projects. |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--excludeTaskDependencies` | boolean | Skips running dependent tasks first. (Default: `false`) |
|
||||
| `--graph` | string | Show the task graph of the command. Pass a file path to save the graph data instead of viewing it in the browser. Pass "stdout" to print the results to the terminal. |
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--output-style` | `tui`, `dynamic`, `dynamic-legacy`, `static`, `stream`, `stream-without-prefixes`, `compact` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--project` | string | Target project. |
|
||||
| `--runner` | string | This is the name of the tasks runner configured in nx.json. |
|
||||
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
| Option | Type | Description |
|
||||
| ------------------------------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--batch` | boolean | Run task(s) in batches for executors which support batches. (Default: `false`) |
|
||||
| `--configuration`, `--c` | string | This is the configuration to use when performing tasks on projects. |
|
||||
| `--exclude` | string | Exclude certain projects from being processed. |
|
||||
| `--excludeTaskDependencies` | boolean | Skips running dependent tasks first. (Default: `false`) |
|
||||
| `--graph` | string | Show the task graph of the command. Pass a file path to save the graph data instead of viewing it in the browser. Pass "stdout" to print the results to the terminal. |
|
||||
| `--nxBail` | boolean | Stop command execution after the first failed task. (Default: `false`) |
|
||||
| `--nxIgnoreCycles` | boolean | Ignore cycles in the task graph. (Default: `false`) |
|
||||
| `--outputStyle` | `tui`, `dynamic`, `dynamic-legacy`, `static`, `stream`, `stream-without-prefixes` | Defines how Nx emits outputs tasks logs. **tui**: enables the Nx Terminal UI, recommended for local development environments. **dynamic-legacy**: use dynamic-legacy output life cycle, previous content is overwritten or modified as new outputs are added, display minimal logs by default, always show errors. This output format is recommended for local development environments where tui is not supported. **static**: uses static output life cycle, no previous content is rewritten or modified as new outputs are added. This output format is recommened for CI environments. **stream**: nx by default logs output to an internal output stream, enable this option to stream logs to stdout / stderr. **stream-without-prefixes**: nx prefixes the project name the target is running on, use this option remove the project name prefix from output. |
|
||||
| `--parallel` | string | Max number of parallel processes [default is 3]. |
|
||||
| `--project` | string | Target project. |
|
||||
| `--runner` | string | This is the name of the tasks runner configured in nx.json. |
|
||||
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
|
||||
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
|
||||
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
|
||||
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
|
||||
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
|
||||
| `--version` | boolean | Show version number. |
|
||||
|
||||
@@ -19,7 +19,7 @@ It provides:
|
||||
To create a new workspace with React, run `npx create-nx-workspace@latest --preset=react-standalone`.
|
||||
|
||||
{% callout type="note" title="React Tutorial" %}
|
||||
For a full tutorial experience, follow the [React Monorepo Tutorial](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
For a full tutorial experience, follow the [React Monorepo Tutorial](/tutorials/2-react-monorepo/1r-introduction/1-welcome)
|
||||
{% /callout %}
|
||||
|
||||
### Installation
|
||||
@@ -135,7 +135,7 @@ The library in `dist` is publishable to npm or a private registry.
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [React Monorepo Tutorial](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
- [React Monorepo Tutorial](/tutorials/2-react-monorepo/1r-introduction/1-welcome)
|
||||
- [Using Cypress](/nx-api/cypress)
|
||||
- [Using Jest](/nx-api/jest)
|
||||
- [Using Storybook](/recipes/storybook/overview-react)
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
{
|
||||
"name": "21.0.1-package-updates",
|
||||
"version": "21.0.1-beta.0",
|
||||
"packages": {
|
||||
"@rspack/core": { "version": "^1.3.8", "alwaysAddToPackageJson": false },
|
||||
"@rspack/dev-server": {
|
||||
"version": "^1.1.1",
|
||||
"alwaysAddToPackageJson": false
|
||||
}
|
||||
},
|
||||
"aliases": [],
|
||||
"description": "",
|
||||
"hidden": false,
|
||||
"implementation": "",
|
||||
"path": "/packages/rspack",
|
||||
"schema": null,
|
||||
"type": "migration"
|
||||
}
|
||||
+13
-4
@@ -39,26 +39,35 @@
|
||||
"name": "Tutorials",
|
||||
"id": "tutorials",
|
||||
"description": "Get started with basic information, concepts and tutorials.",
|
||||
"path": "/tutorials",
|
||||
"itemList": [
|
||||
{
|
||||
"name": "TypeScript Monorepo",
|
||||
"id": "typescript-packages-tutorial",
|
||||
"file": "shared/tutorials/typescript-packages"
|
||||
"file": "",
|
||||
"path": "/tutorials/1-ts-packages/1t-introduction/1-welcome",
|
||||
"isExternal": true
|
||||
},
|
||||
{
|
||||
"name": "React Monorepo",
|
||||
"id": "react-monorepo-tutorial",
|
||||
"file": "shared/tutorials/react-monorepo"
|
||||
"file": "",
|
||||
"path": "/tutorials/2-react-monorepo/1r-introduction/1-welcome",
|
||||
"isExternal": true
|
||||
},
|
||||
{
|
||||
"name": "Angular Monorepo",
|
||||
"id": "angular-monorepo-tutorial",
|
||||
"file": "shared/tutorials/angular-monorepo"
|
||||
"file": "",
|
||||
"path": "/tutorials/3-angular-monorepo/1a-introduction/1-welcome",
|
||||
"isExternal": true
|
||||
},
|
||||
{
|
||||
"name": "Gradle Monorepo",
|
||||
"id": "gradle-tutorial",
|
||||
"file": "shared/tutorials/gradle"
|
||||
"file": "",
|
||||
"path": "/tutorials/4-gradle/1g-introduction/1-welcome",
|
||||
"isExternal": true
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -53,6 +53,13 @@ nx add @nx/playwright
|
||||
nx add @nx/jest
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
{% tab label="Gradle" %}
|
||||
|
||||
```shell {% skipRescope=true %}
|
||||
nx add @nx/gradle
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
@@ -75,6 +82,7 @@ If you are already using the `@nx/cypress`, `@nx/playwright`, or `@nx/jest` plug
|
||||
- [Configure Cypress Task Splitting](/nx-api/cypress#nxcypress-configuration)
|
||||
- [Configure Playwright Task Splitting](/nx-api/playwright#nxplaywright-configuration)
|
||||
- [Configure Jest Task Splitting](/nx-api/jest#splitting-e2e-tests)
|
||||
- [Configure Gradle Testing Task Splitting](/nx-api/gradle#splitting-tests)
|
||||
|
||||
## Verify Automated Task Splitting Works
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@ Someone who appreciates the flexibility of a package-based repository will be mo
|
||||
- Easily create new projects or tools with [code generators](/features/generate-code)
|
||||
|
||||
{% cards %}
|
||||
{% card title="TypeScript Monorepo Tutorial" description="Add Nx to an existing TypeScript repo" type="documentation" url="/getting-started/tutorials/typescript-packages-tutorial" /%}
|
||||
{% card title="TypeScript Monorepo Tutorial" description="Add Nx to an existing TypeScript repo" type="documentation" url="/tutorials/1-ts-packages/1t-introduction/1-welcome" /%}
|
||||
{% /cards %}
|
||||
|
||||
## Integrated Repos
|
||||
@@ -52,8 +52,8 @@ Someone who appreciates the structure and consistency of an integrated repositor
|
||||
- [Automate updating dependencies](/features/automate-updating-dependencies) of the entire toolchain
|
||||
|
||||
{% cards %}
|
||||
{% card title="Tutorial: React Monorepo" description="Create a React monorepo with Nx" type="documentation" url="/getting-started/tutorials/react-monorepo-tutorial" /%}
|
||||
{% card title="Tutorial: Angular Monorepo" description="Create an Angular monorepo with Nx" type="documentation" url="/getting-started/tutorials/angular-monorepo-tutorial" /%}
|
||||
{% card title="Tutorial: React Monorepo" description="Create a React monorepo with Nx" type="documentation" url="/tutorials/2-react-monorepo/1r-introduction/1-welcome" /%}
|
||||
{% card title="Tutorial: Angular Monorepo" description="Create an Angular monorepo with Nx" type="documentation" url="/tutorials/3-angular-monorepo/1a-introduction/1-welcome" /%}
|
||||
{% /cards %}
|
||||
|
||||
## Standalone Applications
|
||||
|
||||
@@ -156,9 +156,9 @@ To avoid potential issues, it is [recommended to update one major version of Nx
|
||||
|
||||
Try one of these tutorials for a full walkthrough of what to do after you install Nx
|
||||
|
||||
- [TypeScript Monorepo Tutorial](/getting-started/tutorials/typescript-packages-tutorial)
|
||||
- [React Monorepo Tutorial](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
- [Angular Monorepo Tutorial](/getting-started/tutorials/angular-monorepo-tutorial)
|
||||
- [TypeScript Monorepo Tutorial](/tutorials/1-ts-packages/1t-introduction/1-welcome)
|
||||
- [React Monorepo Tutorial](/tutorials/2-react-monorepo/1r-introduction/1-welcome)
|
||||
- [Angular Monorepo Tutorial](/tutorials/3-angular-monorepo/1a-introduction/1-welcome)
|
||||
|
||||
## More Documentation
|
||||
|
||||
|
||||
@@ -66,13 +66,13 @@ Also, here are some recipes that give you more details based on the technology s
|
||||
|
||||
{% cards cols="2" lgCols="4" mdCols="4" smCols="2" %}
|
||||
|
||||
{% link-card title="TypeScript Monorepo" type="tutorial" url="/getting-started/tutorials/typescript-packages-tutorial" icon="jsMono" /%}
|
||||
{% link-card title="TypeScript Monorepo" type="tutorial" isExternal="true" url="/tutorials/1-ts-packages/1t-introduction/1-welcome" icon="jsMono" /%}
|
||||
|
||||
{% link-card title="React Monorepo" type="tutorial" url="/getting-started/tutorials/react-monorepo-tutorial" icon="reactMono" /%}
|
||||
{% link-card title="React Monorepo" type="tutorial" isExternal="true" url="/tutorials/2-react-monorepo/1r-introduction/1-welcome" icon="reactMono" /%}
|
||||
|
||||
{% link-card title="Angular Monorepo" type="tutorial" url="/getting-started/tutorials/angular-monorepo-tutorial" icon="angularMono" /%}
|
||||
{% link-card title="Angular Monorepo" type="tutorial" isExternal="true" url="/tutorials/3-angular-monorepo/1a-introduction/1-welcome" icon="angularMono" /%}
|
||||
|
||||
{% link-card title="Gradle Monorepo" type="tutorial" url="/getting-started/tutorials/gradle-tutorial" icon="gradle" /%}
|
||||
{% link-card title="Gradle Monorepo" type="tutorial" isExternal="true" url="/tutorials/4-gradle/1g-introduction/1-welcome" icon="gradle" /%}
|
||||
|
||||
{% /cards %}
|
||||
|
||||
|
||||
@@ -39,13 +39,11 @@ Please not that Angular Rspack support is still experimental and is not yet cons
|
||||
|
||||
The following are known limitations and missing features of Angular Rspack:
|
||||
|
||||
- Static Site Generation (SSG) is not supported.
|
||||
- Server Routing is not supported - still experimental in Angular currently.
|
||||
- App Engine APIs are not supported - still experimental in Angular currently.
|
||||
- Optimization is not currently 1:1 with Angular's optimization - however, there are still great optimizations that are made.
|
||||
- Styles optimization for `inline-critical` and `remove-special-comments` are not yet implemented.
|
||||
- Inlining of fonts is not yet implemented.
|
||||
- Web Workers are not fully supported.
|
||||
- Hot Module Replacement (HMR) is partially supported.
|
||||
|
||||
If you have any other missing features or limitations, please [let us know](https://github.com/nrwl/angular-rspack/issues/new).
|
||||
|
||||
@@ -41,7 +41,7 @@ Here's a quick side-by-side overview comparing the features between the Angular
|
||||
| Advanced Generators (e.g. Module Federation, Tailwind,...) | ❌ | ✅ |
|
||||
| Integrated Tooling (Jest, Cypress, Playwright etc.) | ❌ | ✅ |
|
||||
| Support for single-project Workspaces | ✅ | ✅ |
|
||||
| First-Class [Monorepo Support](/getting-started/tutorials/angular-monorepo-tutorial) | ❌\* | ✅ |
|
||||
| First-Class [Monorepo Support](/tutorials/3-angular-monorepo/1a-introduction/1-welcome) | ❌\* | ✅ |
|
||||
| [Enforced Module Boundaries](/features/enforce-module-boundaries) | ❌ | ✅ |
|
||||
| Interactive [Project Graph](/features/explore-graph) | ❌ | ✅ |
|
||||
| Task Graph | ❌ | ✅ |
|
||||
@@ -411,4 +411,4 @@ There is also a guide describing how to [consolidate multiple Angular CLI projec
|
||||
|
||||
You can learn more about Angular & Nx by following our dedicated tutorials:
|
||||
|
||||
- [Tutorial: Building Angular Apps in an Nx Monorepo](/getting-started/tutorials/angular-monorepo-tutorial)
|
||||
- [Tutorial: Building Angular Apps in an Nx Monorepo](/tutorials/3-angular-monorepo/1a-introduction/1-welcome)
|
||||
|
||||
@@ -11,7 +11,7 @@ powering Nx underneath. As a result, Lerna gets all the modern features such as
|
||||
on [https://lerna.js.org/upgrade](https://lerna.js.org/upgrade).
|
||||
{% /callout %}
|
||||
|
||||
Nx has first-class support for [monorepos](/getting-started/tutorials/typescript-packages-tutorial). If you have
|
||||
Nx has first-class support for [monorepos](/tutorials/1-ts-packages/1t-introduction/1-welcome). If you have
|
||||
an existing NPM/Yarn or PNPM-based monorepo setup, you can easily add Nx to get
|
||||
|
||||
- fast [task scheduling](/features/run-tasks)
|
||||
|
||||
@@ -53,5 +53,6 @@ Below is a reference table that matches versions of [Angular Rspack](/recipes/an
|
||||
|
||||
| Angular Rspack | Angular | Nx |
|
||||
| -------------- | ----------- | ------------------- |
|
||||
| ~20.8.0 | **~19.2.0** | >= 20.8.1 <= latest |
|
||||
| ~20.7.0 | **~19.2.0** | >= 20.8.1 <= latest |
|
||||
| ~20.6.0 | **~19.2.0** | >= 20.6.0 <= latest |
|
||||
|
||||
@@ -46,7 +46,7 @@ nx add @nx/angular
|
||||
This will install the correct version of `@nx/angular`.
|
||||
|
||||
{% callout type="note" title="Angular Tutorial" %}
|
||||
For a full tutorial experience, follow the [Angular Monorepo Tutorial](/getting-started/tutorials/angular-monorepo-tutorial)
|
||||
For a full tutorial experience, follow the [Angular Monorepo Tutorial](/tutorials/3-angular-monorepo/1a-introduction/1-welcome)
|
||||
{% /callout %}
|
||||
|
||||
## Using the Angular Plugin
|
||||
@@ -113,7 +113,7 @@ nx g @nx/angular:service apps/appName/src/lib/my-service/my-service
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [Angular Monorepo Tutorial](/getting-started/tutorials/angular-monorepo-tutorial)
|
||||
- [Angular Monorepo Tutorial](/tutorials/3-angular-monorepo/1a-introduction/1-welcome)
|
||||
- [Migrating from the Angular CLI](/recipes/angular/migration/angular)
|
||||
- [Setup Module Federation with Angular and Nx](/concepts/module-federation/faster-builds-with-module-federation)
|
||||
- [Using Tailwind CSS with Angular projects](/recipes/angular/using-tailwind-css-with-angular-projects)
|
||||
|
||||
@@ -170,7 +170,7 @@ The `@nx/gradle` plugin will automatically split your testing tasks by test clas
|
||||
|
||||
### Continuous Tasks
|
||||
|
||||
Gradle doesn't have a standard way to identify tasks which are [continuous](https://nx-dev-git-docs-gradle-publish-nrwl.vercel.app/reference/project-configuration#continuous), like `bootRun` for serving a Spring Boot project. To ensure Nx handles these continuous tasks correctly, you can explicitly mark them as continuous.
|
||||
Gradle doesn't have a standard way to identify tasks which are [continuous](/reference/project-configuration#continuous), like `bootRun` for serving a Spring Boot project. To ensure Nx handles these continuous tasks correctly, you can explicitly mark them as continuous.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="nx.json" %}
|
||||
|
||||
@@ -19,7 +19,7 @@ It provides:
|
||||
To create a new workspace with React, run `npx create-nx-workspace@latest --preset=react-standalone`.
|
||||
|
||||
{% callout type="note" title="React Tutorial" %}
|
||||
For a full tutorial experience, follow the [React Monorepo Tutorial](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
For a full tutorial experience, follow the [React Monorepo Tutorial](/tutorials/2-react-monorepo/1r-introduction/1-welcome)
|
||||
{% /callout %}
|
||||
|
||||
### Installation
|
||||
@@ -135,7 +135,7 @@ The library in `dist` is publishable to npm or a private registry.
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [React Monorepo Tutorial](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
- [React Monorepo Tutorial](/tutorials/2-react-monorepo/1r-introduction/1-welcome)
|
||||
- [Using Cypress](/nx-api/cypress)
|
||||
- [Using Jest](/nx-api/jest)
|
||||
- [Using Storybook](/recipes/storybook/overview-react)
|
||||
|
||||
@@ -5,11 +5,7 @@
|
||||
- [Installation](/getting-started/installation)
|
||||
- [Why Nx?](/getting-started/why-nx)
|
||||
- [Editor Setup](/getting-started/editor-setup)
|
||||
- [Tutorials](/getting-started/tutorials)
|
||||
- [TypeScript Monorepo](/getting-started/tutorials/typescript-packages-tutorial)
|
||||
- [React Monorepo](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
- [Angular Monorepo](/getting-started/tutorials/angular-monorepo-tutorial)
|
||||
- [Gradle Monorepo](/getting-started/tutorials/gradle-tutorial)
|
||||
- [Tutorials](/tutorials)
|
||||
- [Features](/features)
|
||||
- [Run Tasks](/features/run-tasks)
|
||||
- [Cache Task Results](/features/cache-task-results)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,437 +0,0 @@
|
||||
---
|
||||
title: 'Gradle Tutorial'
|
||||
description: In this tutorial you'll add Nx to an existing Gradle repo
|
||||
---
|
||||
|
||||
# Gradle Tutorial
|
||||
|
||||
In this tutorial, you'll learn how to add Nx to a repository with an existing Gradle setup.
|
||||
|
||||
What will you learn?
|
||||
|
||||
- how to add Nx to a Gradle project
|
||||
- how to run a single task (i.e. serve your app) or run multiple tasks in parallel
|
||||
- how to leverage code generators to scaffold components
|
||||
- how to modularize your codebase and impose architectural constraints for better maintainability
|
||||
- [how to speed up CI with Nx Cloud ⚡](#fast-ci)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Make sure that you have [Gradle](https://gradle.org/) installed on your system.
|
||||
Consult [Gradle's installation guide](https://docs.gradle.org/current/userguide/installation.html) for instruction that
|
||||
are specific to your operating system.
|
||||
|
||||
To verify that Gradle was installed correctly, run this command:
|
||||
|
||||
```shell
|
||||
gradle --version
|
||||
```
|
||||
|
||||
To streamline this tutorial, we'll install Nx globally on your system. You can use Homebrew (Mac only) or a manually installed Node version (any OS).
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Homebrew" %}
|
||||
|
||||
Make sure [Homebrew is installed](https://brew.sh/), then install Nx globally with these commands:
|
||||
|
||||
```shell
|
||||
brew tap nrwl/nx
|
||||
brew install nx
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
{% tab label="Node" %}
|
||||
|
||||
Install node from the [NodeJS website](https://nodejs.org/en/download), then install Nx globally with this command:
|
||||
|
||||
```shell
|
||||
npm install --global nx
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
## Getting Started
|
||||
|
||||
This tutorial picks up where [Spring framework](https://spring.io/)'s guide for [Multi-Module Projects](https://spring.io/guides/gs/multi-module) leaves off.
|
||||
|
||||
Fork [the sample repository](https://github.com/nrwl/gradle-tutorial/fork), and then clone it on your local machine:
|
||||
|
||||
```shell
|
||||
git clone https://github.com/<your-username>/gradle-tutorial.git
|
||||
```
|
||||
|
||||
The Multi-Module Spring Tutorial left us with 2 projects:
|
||||
|
||||
- The main `application` project which contains the Spring `DemoApplication`
|
||||
- A `library` project which contains a Service used in the `DemoApplication`
|
||||
|
||||
You can see the above 2 projects by running `./gradlew projects`
|
||||
|
||||
```text {% command="./gradlew projects" %}
|
||||
> Task :projects
|
||||
|
||||
------------------------------------------------------------
|
||||
Root project 'gradle-tutorial'
|
||||
------------------------------------------------------------
|
||||
|
||||
Root project 'gradle-tutorial'
|
||||
+--- Project ':application'
|
||||
\--- Project ':library'
|
||||
|
||||
```
|
||||
|
||||
## Add Nx
|
||||
|
||||
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. We will explore the features of Nx in this tutorial by adding it to the Gradle workspace above.
|
||||
|
||||
To add Nx, run
|
||||
|
||||
```shell {% path="~/gradle-tutorial" %}
|
||||
npx nx@latest init
|
||||
```
|
||||
|
||||
This command will download the latest version of Nx and help set up your repository to take advantage of it. Nx will
|
||||
also detect Gradle is used in the repo so it will propose adding the `@nx/gradle` plugin to integrate Gradle with Nx.
|
||||
Select the plugin and continue with the setup.
|
||||
|
||||
Similar to Gradle, Nx can be run with the `nx` or `nx.bat` executables. We will learn about some of the Nx commands in
|
||||
the following sections.
|
||||
|
||||
## Explore Your Workspace
|
||||
|
||||
Like Gradle, Nx understands your workspace as a graph of projects. Nx uses this graph for many things which we will
|
||||
learn about in following sections. To visualize this graph in your browser, Run the following command and click the
|
||||
"Show all projects" button in the left sidebar.
|
||||
|
||||
You will recognize that the projects which are shown, are the same projects which Gradle shows.
|
||||
The `@nx/gradle` plugin reflects the graph of projects in Gradle into the Nx Project Graph. As projects
|
||||
are created, deleted, and change their dependencies, Nx will automatically recalculate the graph. Exploring this graph
|
||||
visually is vital to understanding how your code is structured and how Nx and Gradle behaves.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Mac/Linux" %}
|
||||
|
||||
```shell
|
||||
./nx graph
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
{% tab label="Windows" %}
|
||||
|
||||
```shell
|
||||
./nx.bat graph
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
{% graph title="Gradle Projects" height="200px" jsonFile="shared/tutorials/gradle-project-graph.json" %}
|
||||
{% /graph %}
|
||||
|
||||
## Running Tasks
|
||||
|
||||
Nx is a task runner built for monorepos. It can run a single task for a single project, a task for all projects, and
|
||||
even intelligently run a subset of tasks based on the changes you've made in your repository. Nx also has sophisticated
|
||||
computation caching to reuse the results of tasks. We will explore how Nx adds to the task running Gradle provides.
|
||||
|
||||
Before we start running tasks, let's explore the tasks available for the `application` project. The `@nx/gradle` plugin
|
||||
that we've installed reflects Gradle's tasks to Nx, which allows it to run any of the Gradle tasks defined for that project. You can view the available tasks either through [Nx Console](/getting-started/editor-setup) or from the terminal:
|
||||
|
||||
```shell {% path="~/gradle-tutorial" %}
|
||||
./nx show project application --web
|
||||
```
|
||||
|
||||
{% project-details title="Project Details View" jsonFile="shared/tutorials/gradle-pdv.json" expandedTargets=["build"] height="520px" %}
|
||||
{% /project-details %}
|
||||
|
||||
The Nx command to run the `build` task for the `application` project is:
|
||||
|
||||
```shell
|
||||
./nx run application:build
|
||||
```
|
||||
|
||||
When Nx runs a Gradle task, it hands off the execution of that task to Gradle, so all task dependencies and
|
||||
configuration settings in the Gradle configuration are still respected.
|
||||
|
||||
By running the task via Nx, however, the task computation was cached for reuse. Now, running `./nx run application:build`
|
||||
again, will complete almost instantly as the result from the previous execution will be used.
|
||||
|
||||
```{% command="./nx run application:build" %}
|
||||
|
||||
✔ 1/1 dependent project tasks succeeded [1 read from cache]
|
||||
|
||||
Hint: you can run the command with --verbose to see the full dependent project outputs
|
||||
|
||||
—————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
|
||||
|
||||
|
||||
> nx run application:classes [existing outputs match the cache, left as is]
|
||||
|
||||
> ./gradlew :application:classes
|
||||
|
||||
> Task :library:compileJava UP-TO-DATE
|
||||
> Task :library:processResources NO-SOURCE
|
||||
> Task :library:classes UP-TO-DATE
|
||||
> Task :library:jar UP-TO-DATE
|
||||
> Task :application:compileJava UP-TO-DATE
|
||||
> Task :application:processResources UP-TO-DATE
|
||||
> Task :application:classes UP-TO-DATE
|
||||
|
||||
BUILD SUCCESSFUL in 647ms
|
||||
4 actionable tasks: 4 up-to-date
|
||||
|
||||
> nx run application:build [existing outputs match the cache, left as is]
|
||||
|
||||
> ./gradlew :application:build
|
||||
|
||||
|
||||
Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
|
||||
|
||||
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
|
||||
|
||||
For more on this, please refer to https://docs.gradle.org/8.5/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
|
||||
|
||||
BUILD SUCCESSFUL in 768ms
|
||||
9 actionable tasks: 1 executed, 8 up-to-date
|
||||
|
||||
—————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
|
||||
|
||||
NX Successfully ran target build for project application and 3 tasks it depends on (30ms)
|
||||
|
||||
Nx read the output from the cache instead of running the command for 4 out of 4 tasks.
|
||||
```
|
||||
|
||||
Now that we've run one task, let's run all the `build` tasks in the repository with the Nx `run-many` command. This is similar to Gradle's `./gradlew build` command.
|
||||
|
||||
```{% command="./nx run-many -t build" %}
|
||||
|
||||
✔ nx run library:classes [existing outputs match the cache, left as is]
|
||||
✔ nx run library:build [existing outputs match the cache, left as is]
|
||||
✔ nx run application:classes [existing outputs match the cache, left as is]
|
||||
✔ nx run application:build [existing outputs match the cache, left as is]
|
||||
✔ nx run gradle-tutorial:classes (1s)
|
||||
✔ nx run gradle-tutorial:build (1s)
|
||||
|
||||
—————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
|
||||
|
||||
NX Successfully ran target build for 3 projects and 3 tasks they depend on (2s)
|
||||
|
||||
Nx read the output from the cache instead of running the command for 4 out of 6 tasks.
|
||||
```
|
||||
|
||||
Again, because Nx cached the tasks when the application was built, most of the tasks here were near instant. The only
|
||||
ones which needed to be done is the root project's build. Running the command one more time, will be near instant as
|
||||
then all the tasks will be restored from the cache.
|
||||
|
||||
## Run Tasks for Affected Projects
|
||||
|
||||
Nx doesn't just cache your task results, it can also [eliminate the need to run unnecessary tasks](/ci/features/affected).
|
||||
|
||||
First, commit any outstanding changes to the `main` branch locally:
|
||||
|
||||
```shell
|
||||
git commit -am "changes"
|
||||
```
|
||||
|
||||
Next make a small change to the `application` code:
|
||||
|
||||
```java {% fileName="application/src/main/java/com/example/multimodule/application/DemoApplication.java" highlightLines=[21] %}
|
||||
package com.example.multimodule.application;
|
||||
|
||||
import com.example.multimodule.service.MyService;
|
||||
import org.springframework.boot.SpringApplication;
|
||||
import org.springframework.boot.autoconfigure.SpringBootApplication;
|
||||
import org.springframework.web.bind.annotation.GetMapping;
|
||||
import org.springframework.web.bind.annotation.RestController;
|
||||
|
||||
@SpringBootApplication(scanBasePackages = "com.example.multimodule")
|
||||
@RestController
|
||||
public class DemoApplication {
|
||||
|
||||
private final MyService myService;
|
||||
|
||||
public DemoApplication(MyService myService) {
|
||||
this.myService = myService;
|
||||
}
|
||||
|
||||
@GetMapping("/")
|
||||
public String home() {
|
||||
return myService.message() + " changed!";
|
||||
}
|
||||
|
||||
public static void main(String[] args) {
|
||||
SpringApplication.run(DemoApplication.class, args);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
As a developer, we know that this change only affects the `application` project, not the `library` project. We would
|
||||
run `./nx run application:test` to verify our changes. In CI, teams often run all test tasks rerunning
|
||||
the `library:test` task unnecessarily.
|
||||
|
||||
For a repository with only a few projects, you can manually calculate which projects are affected. As the repository grows, it becomes critical to have a tool like Nx that understands the project dependency graph and eliminates wasted time in CI.
|
||||
|
||||
The `./nx affected` command solves this problem. Nx uses its project graph in conjunction with git history to only run
|
||||
tasks for projects that may have been affected by the changes that you made.
|
||||
|
||||
To run the `test` tasks for projects affected by this change, run:
|
||||
|
||||
```shell
|
||||
./nx affected -t test
|
||||
```
|
||||
|
||||
Notice that this command does not run the `test` task for the `library` project, since it could not have been affected by the code change.
|
||||
|
||||
## Fast CI ⚡ {% highlightColor="green" %}
|
||||
|
||||
{% callout type="check" title="Repository with Nx" %}
|
||||
Make sure you have completed the previous sections of this tutorial before starting this one. If you want a clean starting point, you can check out the [reference code](https://github.com/nrwl/nx-recipes/tree/main/gradle) as a starting point.
|
||||
{% /callout %}
|
||||
|
||||
This tutorial walked you through how Nx can improve the local development experience, but the biggest difference Nx makes is in CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.
|
||||
|
||||
- Nx reduces wasted time in CI with the [`affected` command](/ci/features/affected).
|
||||
- Nx Replay's [remote caching](/ci/features/remote-cache) will reuse task artifacts from different CI executions making sure you will never run the same computation twice.
|
||||
- Nx Agents [efficiently distribute tasks across machines](/ci/concepts/parallelization-distribution) ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
|
||||
- Nx Atomizer [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across machines. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
|
||||
|
||||
### Connect to Nx Cloud {% highlightColor="green" %}
|
||||
|
||||
Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e tests deflaking, better DX and more.
|
||||
|
||||
Now that we're working on the CI pipeline, it is important for your changes to be pushed to a GitHub repository.
|
||||
|
||||
1. Commit your existing changes with `git add . && git commit -am "updates"`
|
||||
2. [Create a new GitHub repository](https://github.com/new)
|
||||
3. Follow GitHub's instructions to push your existing code to the repository
|
||||
|
||||
Now connect your repository to Nx Cloud with the following command:
|
||||
|
||||
```shell
|
||||
./nx connect
|
||||
```
|
||||
|
||||
A browser window will open to register your repository in your [Nx Cloud](https://cloud.nx.app) account. The link is also printed to the terminal if the windows does not open, or you closed it before finishing the steps. The app will guide you to create a PR to enable Nx Cloud on your repository.
|
||||
|
||||
|
||||
|
||||
Once the PR is created, merge it into your main branch.
|
||||
|
||||
|
||||
|
||||
And make sure you pull the latest changes locally:
|
||||
|
||||
```shell
|
||||
git pull
|
||||
```
|
||||
|
||||
You should now have an `nxCloudId` property specified in the `nx.json` file.
|
||||
|
||||
### Create a CI Workflow {% highlightColor="green" %}
|
||||
|
||||
Let's create a branch to add a CI workflow.
|
||||
|
||||
```shell
|
||||
git checkout -b add-workflow
|
||||
```
|
||||
|
||||
And use the following command to generate a CI workflow file.
|
||||
|
||||
```shell
|
||||
./nx generate ci-workflow --ci=github
|
||||
```
|
||||
|
||||
This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR. If you would like to also distribute tasks across multiple machines to ensure fast and reliable CI runs, uncomment the `nx-cloud start-ci-run` line.
|
||||
|
||||
The key lines in the CI pipeline are:
|
||||
|
||||
```yml {% fileName=".github/workflows/ci.yml" highlightLines=["21-24", "38-39"] %}
|
||||
name: CI
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
pull_request:
|
||||
|
||||
permissions:
|
||||
actions: read
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
main:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
filter: tree:0
|
||||
|
||||
# This enables task distribution via Nx Cloud
|
||||
# Run this command as early as possible, before dependencies are installed
|
||||
# Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
|
||||
# Uncomment this line to enable task distribution
|
||||
# - run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-jvm" --stop-agents-after="build"
|
||||
|
||||
- name: Set up JDK 21 for x64
|
||||
uses: actions/setup-java@v4
|
||||
with:
|
||||
java-version: '21'
|
||||
distribution: 'temurin'
|
||||
architecture: x64
|
||||
|
||||
- name: Setup Gradle
|
||||
uses: gradle/gradle-build-action@v2
|
||||
|
||||
- uses: nrwl/nx-set-shas@v4
|
||||
|
||||
# Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
|
||||
- run: ./nx affected -t test build
|
||||
```
|
||||
|
||||
### Open a Pull Request {% highlightColor="green" %}
|
||||
|
||||
Commit the changes and open a new PR on GitHub.
|
||||
|
||||
```shell
|
||||
git add .
|
||||
git commit -m 'add CI workflow file'
|
||||
git push origin add-workflow
|
||||
```
|
||||
|
||||
When you view the PR on GitHub, you will see a comment from Nx Cloud that reports on the status of the CI run.
|
||||
|
||||
|
||||
|
||||
The `See all runs` link goes to a page with the progress and results of tasks that were run in the CI pipeline.
|
||||
|
||||
|
||||
|
||||
For more information about how Nx can improve your CI pipeline, check out one of these detailed tutorials:
|
||||
|
||||
- [Circle CI with Nx](/ci/intro/tutorials/circle)
|
||||
- [GitHub Actions with Nx](/ci/intro/tutorials/github-actions)
|
||||
|
||||
## Summary
|
||||
|
||||
Now that you have added Nx to this sample Gradle repository, you have learned several ways that Nx can help your
|
||||
organization:
|
||||
|
||||
- Nx reflects the Gradle graph into the Nx graph
|
||||
- Nx's dependency graph visualisation helps you understand your codebase
|
||||
- Nx caches task results and reuses them when the same task is rerun later
|
||||
- Nx intelligently determines which tasks are `affected` by code changes to reduce waste in CI
|
||||
- Nx Cloud provides remote caching and distributed task execution to speed up CI
|
||||
|
||||
## Next Steps
|
||||
|
||||
Connect with the rest of the Nx community with these resources:
|
||||
|
||||
- ⭐️ [Star us on GitHub](https://github.com/nrwl/nx) to show your support and stay updated on new releases!
|
||||
- [Join the Official Nx Discord Server](https://go.nx.dev/community) to ask questions and find out the latest news about
|
||||
Nx.
|
||||
- [Follow Nx on Twitter](https://twitter.com/nxdevtools) to stay up to date with Nx news
|
||||
- [Read our Nx blog](/blog)
|
||||
- [Subscribe to our Youtube channel](https://www.youtube.com/@nxdevtools) for demos and Nx insights
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,505 +0,0 @@
|
||||
---
|
||||
title: 'TypeScript Monorepo Tutorial'
|
||||
description: In this tutorial you'll add Nx to an existing TypeScript repo
|
||||
---
|
||||
|
||||
# TypeScript Monorepo Tutorial
|
||||
|
||||
In this tutorial, you'll learn how to add Nx to a repository with an existing TypeScript project. The starting repository uses [NPM workspaces](https://docs.npmjs.com/cli/using-npm/workspaces) for project linking and is configured to build with [TypeScript project references](https://www.typescriptlang.org/docs/handbook/project-references.html).
|
||||
|
||||
What will you learn?
|
||||
|
||||
- how to add Nx to the repository with a single command
|
||||
- how to configure caching for your tasks
|
||||
- how to configure a task pipeline
|
||||
- how to configure projects automatically with Nx Plugins
|
||||
- how to manage your releases with `nx release`
|
||||
- [how to speed up CI with Nx Cloud ⚡](#fast-ci)
|
||||
|
||||
<!-- ## Final Source Code
|
||||
|
||||
Here's the source code of the final result for this tutorial.
|
||||
|
||||
{% github-repository url="https://github.com/nrwl/nx-recipes/tree/main/typescript-packages" /%} -->
|
||||
|
||||
<!-- {% youtube
|
||||
src="https://www.youtube.com/embed/ZA9K4iT3ANc"
|
||||
title="Nx NPM Workspaces Tutorial Walkthrough"
|
||||
/%} -->
|
||||
|
||||
## Starting Repository
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZA9K4iT3ANc?t=51" /%} -->
|
||||
|
||||
To get started, fork [the sample repository](https://github.com/nrwl/tuskydesign/fork) and clone it on your local machine:
|
||||
|
||||
```shell
|
||||
git clone https://github.com/<your-username>/tuskydesign.git
|
||||
```
|
||||
|
||||
The repository has three TypeScript packages under `packages/animals`, `packages/names` and `packages/zoo`. The `zoo` package uses `animals` and `names` to generate a random message. The root `package.json` has a `workspaces` property that tells NPM how to find the projects in the repository.
|
||||
|
||||
```json {% fileName="package.json" %}
|
||||
{
|
||||
"workspaces": ["packages/*"]
|
||||
}
|
||||
```
|
||||
|
||||
Because of this setting, when the install command is run at the root, the correct packages are installed for each project. NPM will create dedicated `node_modules` folders inside of each project folder where necessary.
|
||||
|
||||
```shell
|
||||
npm install
|
||||
```
|
||||
|
||||
Now let's try running some tasks. To build the `animals` package, use the `build` npm script:
|
||||
|
||||
```text {% command="npm run build -w @tuskdesign/animals" path="~/tuskydesigns" %}
|
||||
> @tuskdesign/animals@1.2.0 build
|
||||
> tsc --build tsconfig.lib.json
|
||||
```
|
||||
|
||||
The repository is set up using [TypeScript project references](https://www.typescriptlang.org/docs/handbook/project-references.html) so building the `zoo` package will automatically build all its dependencies.
|
||||
|
||||
```text {% command="npm run build -w @tuskdesign/zoo" path="~/tuskydesigns" %}
|
||||
> @tuskdesign/zoo@1.2.0 build
|
||||
> tsc --build tsconfig.lib.json
|
||||
```
|
||||
|
||||
To run the `zoo` package use the `serve` script:
|
||||
|
||||
```text {% command="npm run serve -w @tuskdesign/zoo" path="~/tuskydesigns" %}
|
||||
> @tuskdesign/zoo@1.2.0 serve
|
||||
> node dist/index.js
|
||||
|
||||
Bo the pig says oink!
|
||||
```
|
||||
|
||||
Now that you have a basic understanding of the repository we're working with, let's see how Nx can help us.
|
||||
|
||||
## Smart Monorepo
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZA9K4iT3ANc?t=170" /%} -->
|
||||
|
||||
Nx offers many features, but at its core, it is a task runner. Out of the box, it can cache your tasks and ensure those tasks are run in the correct order. After the initial set up, you can incrementally add on other features that would be helpful in your organization.
|
||||
|
||||
### Add Nx
|
||||
|
||||
To enable Nx in your repository, run a single command:
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx@latest init
|
||||
```
|
||||
|
||||
This command will download the latest version of Nx and help set up your repository to take advantage of it.
|
||||
|
||||
First, the script will propose installing some plugins based on the packages that are being used in your repository.
|
||||
|
||||
- Deselect both proposed plugins so that we can explore what Nx provides without any plugins.
|
||||
|
||||
Second, the script asks a series of questions to help set up caching for you.
|
||||
|
||||
- `Which scripts need to be run in order?` - Choose `build`
|
||||
- `Which scripts are cacheable?` - Choose `build` and `typecheck`
|
||||
- `Does the "build" script create any outputs?` - Enter `dist`
|
||||
- `Does the "typecheck" script create any outputs?` - Enter nothing
|
||||
- `Would you like remote caching to make your build faster?` - Choose `Skip for now`
|
||||
|
||||
### Explore Your Workspace
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZA9K4iT3ANc?t=250" /%} -->
|
||||
|
||||
If you run `nx graph` as instructed, you'll see the dependencies between your projects.
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx graph --focus=@tuskdesign/zoo
|
||||
```
|
||||
|
||||
{% graph title="Tusk Design" height="200px" jsonFile="shared/tutorials/typescript-packages-project-graph.json" %}
|
||||
{% /graph %}
|
||||
|
||||
Nx uses this graph to determine the order tasks are run and enforce module boundaries. You can also leverage this graph to gain an accurate understanding of the architecture of your codebase. Part of what makes this graph invaluable is that it is derived directly from your codebase, so it will never become out of date.
|
||||
|
||||
### Caching Pre-configured
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZA9K4iT3ANc?t=285" /%} -->
|
||||
|
||||
Nx has been configured to run your `build`, `typecheck` and `lint` tasks. You can run a single task like this:
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx build @tuskdesign/zoo
|
||||
```
|
||||
|
||||
Or all tasks with a certain name like this:
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx run-many -t typecheck
|
||||
```
|
||||
|
||||
During the `init` script, Nx also configured caching for these tasks. You can see in the `nx.json` file that the `build`, `typecheck` and `lint` targets have the `cache` property set to `true` and the `build` target specifies that its output goes to the project's `dist` folder.
|
||||
|
||||
```json {% fileName="nx.json" %}
|
||||
{
|
||||
"$schema": "./node_modules/nx/schemas/nx-schema.json",
|
||||
"targetDefaults": {
|
||||
"build": {
|
||||
"dependsOn": ["^build"],
|
||||
"outputs": ["{projectRoot}/dist"],
|
||||
"cache": true
|
||||
},
|
||||
"typecheck": {
|
||||
"cache": true
|
||||
},
|
||||
"lint": {
|
||||
"cache": true
|
||||
}
|
||||
},
|
||||
"defaultBase": "main"
|
||||
}
|
||||
```
|
||||
|
||||
Try running `build` for the `zoo` app a second time:
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx build @tuskdesign/zoo
|
||||
```
|
||||
|
||||
The first time `nx build` was run, it took about 1 second - just like running `npm run build`. But the second time you run `nx build`, it completes instantly and displays this message:
|
||||
|
||||
```text
|
||||
Nx read the output from the cache instead of running the command for 3 out of 3 tasks.
|
||||
```
|
||||
|
||||
You can see the same caching behavior working when you run `npx nx typecheck`.
|
||||
|
||||
### Use Task Pipelines
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZA9K4iT3ANc?t=358" /%} -->
|
||||
|
||||
You may be wondering why the caching message in the previous section mentioned 3 tasks when you only ran the `build` task from the terminal. When we said that `build` tasks must be run in order during the setup script, Nx created a simple task pipeline. You can see the configuration for it in the `nx.json` file:
|
||||
|
||||
```json {% fileName="nx.json" %}
|
||||
{
|
||||
"targetDefaults": {
|
||||
"build": {
|
||||
"dependsOn": ["^build"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This configuration means that if you run `build` on any project, Nx will first run `build` for the dependencies of that project and then run `build` on the project itself. The `^build` text means "the `build` tasks of the project's dependencies." You can visualize this in the Nx graph by selecting the `Tasks` dropdown in the top left and clicking `Show all tasks`:
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx graph
|
||||
```
|
||||
|
||||
Alternatively, you can pass the `--graph` option to the run command to inspect the task graph.
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx run @tuskdesign/zoo:build --graph
|
||||
```
|
||||
|
||||
{% graph height="200px" title="Build Task Pipeline" type="task" jsonFile="shared/tutorials/typescript-packages-build-tasks1.json" %}
|
||||
{% /graph %}
|
||||
|
||||
### Create a Task Pipeline
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZA9K4iT3ANc?t=450" /%} -->
|
||||
|
||||
You may have noticed in the `packages/zoo/package.json` file, there is a `serve` script that expects the `build` task to already have created the `dist` folder. Let's set up a task pipeline that will guarantee that the project's `build` task has been run.
|
||||
|
||||
```json {% fileName="nx.json" highlightLines=[5] %}
|
||||
{
|
||||
"$schema": "./node_modules/nx/schemas/nx-schema.json",
|
||||
"targetDefaults": {
|
||||
"serve": {
|
||||
"dependsOn": ["build"]
|
||||
},
|
||||
"build": {
|
||||
"dependsOn": ["^build"],
|
||||
"outputs": ["{projectRoot}/dist"],
|
||||
"cache": true
|
||||
},
|
||||
"typecheck": {
|
||||
"cache": true
|
||||
}
|
||||
},
|
||||
"defaultBase": "main"
|
||||
}
|
||||
```
|
||||
|
||||
The `serve` target's `dependsOn` line makes Nx run the `build` task for the current project before running the current project's `build` task. Now `nx serve` will run the `build` task before running the `serve` task.
|
||||
|
||||
### Use Nx Plugins to Enhance Your Workspace
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZA9K4iT3ANc?t=507" /%} -->
|
||||
|
||||
We mentioned earlier that this repository is using TypeScript project references defined in the `tsconfig.json` files to incrementally build each project so that the output is available for other projects in the repository. In order for this feature to work, the `references` section in the `tsconfig.json` files for each project need to accurately reflect the actual dependencies of that project. This can be difficult to maintain, but Nx already knows the dependencies of every project and you can use the `@nx/js` plugin to automatically keep the TypeScript project references in sync with the code base.
|
||||
|
||||
Nx plugins can:
|
||||
|
||||
- automatically configure caching for you, including inputs and outputs based on the underlying tooling configuration
|
||||
- infer tasks that can be run on a project because of the tooling present
|
||||
- keep tooling configuration in sync with the structure of your codebase
|
||||
- provide code generators to help scaffold out projects
|
||||
- automatically keep the tooling versions and configuration files up to date
|
||||
|
||||
For this tutorial, we'll focus on inferring tasks and keeping tooling configuration in sync.
|
||||
|
||||
First, let's remove the existing `build` and `typecheck` scripts from each project's `package.json` files to allow the `@nx/js` plugin to infer those tasks for us.
|
||||
|
||||
```json {% fileName="packages/animals/package.json" %}
|
||||
{
|
||||
"scripts": {}
|
||||
}
|
||||
```
|
||||
|
||||
```json {% fileName="packages/names/package.json" %}
|
||||
{
|
||||
"scripts": {}
|
||||
}
|
||||
```
|
||||
|
||||
```json {% fileName="packages/zoo/package.json" %}
|
||||
{
|
||||
"scripts": {
|
||||
"serve": "node dist/index.js"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Now let's add the `@nx/js` plugin:
|
||||
|
||||
```{% command="npx nx add @nx/js" path="~/tuskydesign" %}
|
||||
✔ Installing @nx/js...
|
||||
✔ Initializing @nx/js...
|
||||
NX Generating @nx/js:init
|
||||
|
||||
UPDATE nx.json
|
||||
UPDATE package.json
|
||||
|
||||
NX Package @nx/js added successfully.
|
||||
```
|
||||
|
||||
The `nx add` command installs the version of the plugin that matches your repo's Nx version and runs that plugin's initialization script. For `@nx/js`, the initialization script registers the plugin in the `plugins` array of `nx.json`. The registered plugin automatically infers `build` and `typecheck` tasks for any project with a `tsconfig.json` file. Open the project details view for the `zoo` package and look at the `build` task.
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx show project @tuskdesign/zoo
|
||||
```
|
||||
|
||||
{% project-details title="Project Details View" jsonFile="shared/tutorials/typescript-packages-pdv.json" %}
|
||||
{% /project-details %}
|
||||
|
||||
Notice that the `inputs` that are inferred for the `build` task match the `include` and `exclude` settings in the `tsconfig.lib.json` file. As those settings are changed, the cache `inputs` will automatically update to the correct values.
|
||||
|
||||
The `build` task also has a [sync generator](/concepts/sync-generators) defined. The `@nx/js:typescript-sync` generator will automatically update the `references` property in the `tsconfig.json` files across the repository to match the actual dependencies in your code.
|
||||
|
||||
Let's see this behavior in action by extracting some common code into a new `util` library.
|
||||
|
||||
First, create a library with `@nx/js:lib` generator:
|
||||
|
||||
```shell
|
||||
nx g @nx/js:lib packages/util
|
||||
```
|
||||
|
||||
Set the bundler to `tsc`, the linter to `none` and the unit test runner to `none`.
|
||||
|
||||
Now we can move the `getRandomItem` function from `packages/names/names.ts` and `packages/animals/animals.ts` into the `packages/util/src/lib/util.ts` file.
|
||||
|
||||
```ts {% fileName="packages/util/src/lib/util.ts" %}
|
||||
export function getRandomItem<T>(arr: T[]): T {
|
||||
return arr[Math.floor(Math.random() * arr.length)];
|
||||
}
|
||||
```
|
||||
|
||||
```ts {% fileName="packages/animals/animals.ts" %}
|
||||
import { getRandomItem } from '@tuskdesign/util';
|
||||
|
||||
// ...
|
||||
```
|
||||
|
||||
```ts {% fileName="packages/names/names.ts" %}
|
||||
import { getRandomItem } from '@tuskdesign/util';
|
||||
|
||||
// ...
|
||||
```
|
||||
|
||||
Now if you run the build, Nx will notice that the TypeScript project references need to be updated and ask your permission to update them.
|
||||
|
||||
```text {% command="nx build @tuskdesign/zoo" path="~/tuskydesigns" %}
|
||||
NX The workspace is out of sync
|
||||
|
||||
[@nx/js:typescript-sync]: Some TypeScript configuration files are missing project references to the projects they depend on or contain outdated project references.
|
||||
|
||||
This will result in an error in CI.
|
||||
|
||||
? Would you like to sync the identified changes to get your workspace up to date? …
|
||||
❯ Yes, sync the changes and run the tasks
|
||||
No, run the tasks without syncing the changes
|
||||
```
|
||||
|
||||
Allow the sync to happen and you'll see that the `tsconfig.json` and `tsconfig.lib.json` files have been updated to include references to the new `util` library. With this system in place, no matter how your codebase changes, the TypeScript project references will always be correct.
|
||||
|
||||
### Checkpoint
|
||||
|
||||
At this point, the repository is still using all the same tools to run tasks, but now Nx runs those tasks in a smarter way. The tasks are efficiently cached so that there is no repeated work and the cache configuration settings are automatically synced with your tooling configuration files by Nx plugins. Also, any task dependencies are automatically executed whenever needed because we configured task pipelines for the projects.
|
||||
|
||||
Open up the task graph for `zoo` app's `serve` task again to see the changes.
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx run @tuskdesign/zoo:serve --graph
|
||||
```
|
||||
|
||||
{% graph height="200px" title="Build Task Pipeline" type="task" jsonFile="shared/tutorials/typescript-packages-build-tasks2.json" %}
|
||||
{% /graph %}
|
||||
|
||||
## Manage Releases
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZA9K4iT3ANc?t=713" /%} -->
|
||||
|
||||
If you decide to publish the `animals` or `names` packages on NPM, Nx can also help you [manage the release process](/features/manage-releases). Release management involves updating the version of your package, populating a changelog, and publishing the new version to the NPM registry.
|
||||
|
||||
First you'll need to define which projects Nx should manage releases for by setting the `release.projects` property in `nx.json`:
|
||||
|
||||
```json {% fileName="nx.json" %}
|
||||
{
|
||||
"release": {
|
||||
"projects": ["packages/*"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Now you're ready to use the `nx release` command to publish the `animals` and `names` packages. The first time you run `nx release`, you need to add the `--first-release` flag so that Nx doesn't try to find the previous version to compare against. It's also recommended to use the `--dry-run` flag until you're sure about the results of the `nx release` command, then you can run it a final time without the `--dry-run` flag.
|
||||
|
||||
To preview your first release, run:
|
||||
|
||||
```shell
|
||||
npx nx release --first-release --dry-run
|
||||
```
|
||||
|
||||
The command will ask you a series of questions and then show you what the results would be. Once you are happy with the results, run it again without the `--dry-run` flag:
|
||||
|
||||
```shell
|
||||
npx nx release --first-release
|
||||
```
|
||||
|
||||
After this first release, you can remove the `--first-release` flag and just run `nx release --dry-run`. There is also a [dedicated feature page](/features/manage-releases) that goes into more detail about how to use the `nx release` command.
|
||||
|
||||
## Fast CI ⚡ {% highlightColor="green" %}
|
||||
|
||||
<!-- {% video-link link="https://youtu.be/ZA9K4iT3ANc?t=821" /%} -->
|
||||
|
||||
{% callout type="check" title="Forked repository with Nx" %}
|
||||
Make sure you have completed the previous sections of this tutorial before starting this one. If you want a clean starting point, you can fork the [sample repository with Nx already added](https://github.com/nrwl/nx-recipes/tree/main/typescript-packages).
|
||||
{% /callout %}
|
||||
|
||||
So far in this tutorial you've seen how Nx improves the local development experience, but the biggest difference Nx makes is in CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.
|
||||
|
||||
- Nx reduces wasted time in CI with the [`affected` command](/ci/features/affected).
|
||||
- Nx Replay's [remote caching](/ci/features/remote-cache) will reuse task artifacts from different CI executions making sure you will never run the same computation twice.
|
||||
- Nx Agents [efficiently distribute tasks across machines](/ci/features/distribute-task-execution) ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
|
||||
- Nx Atomizer [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across machines. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
|
||||
|
||||
### Connect to Nx Cloud {% highlightColor="green" %}
|
||||
|
||||
Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e tests deflaking, better DX and more.
|
||||
|
||||
Now that we're working on the CI pipeline, it is important for your changes to be pushed to a GitHub repository.
|
||||
|
||||
1. Commit your existing changes with `git add . && git commit -am "updates"`
|
||||
2. Push your changes to your forked GitHub repository with `git push`
|
||||
|
||||
Now connect your repository to Nx Cloud with the following command:
|
||||
|
||||
```shell
|
||||
npx nx connect
|
||||
```
|
||||
|
||||
A browser window will open to register your repository in your [Nx Cloud](https://cloud.nx.app) account. The link is also printed to the terminal if the windows does not open, or you closed it before finishing the steps. The app will guide you to create a PR to enable Nx Cloud on your repository.
|
||||
|
||||
|
||||
|
||||
Once the PR is created, merge it into your main branch.
|
||||
|
||||
|
||||
|
||||
And make sure you pull the latest changes locally:
|
||||
|
||||
```shell
|
||||
git pull
|
||||
```
|
||||
|
||||
You should now have an `nxCloudId` property specified in the `nx.json` file.
|
||||
|
||||
### Create a CI Workflow {% highlightColor="green" %}
|
||||
|
||||
Use the following command to generate a CI workflow file.
|
||||
|
||||
```shell
|
||||
npx nx generate ci-workflow --ci=github
|
||||
```
|
||||
|
||||
This generator creates a `.github/workflows/ci.yml` file that contains a CI pipeline that will run the `lint`, `test`, `build` and `e2e` tasks for projects that are affected by any given PR. If you would like to also distribute tasks across multiple machines to ensure fast and reliable CI runs, uncomment the `nx-cloud start-ci-run` line and have the `nx affected` line run the `e2e-ci` task instead of `e2e`.
|
||||
|
||||
The key lines in the CI pipeline are:
|
||||
|
||||
```yml {% fileName=".github/workflows/ci.yml" highlightLines=["10-14", "21-23"] %}
|
||||
name: CI
|
||||
# ...
|
||||
jobs:
|
||||
main:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
filter: tree:0
|
||||
|
||||
# This enables task distribution via Nx Cloud
|
||||
# Run this command as early as possible, before dependencies are installed
|
||||
# Learn more at https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirun
|
||||
# Uncomment this line to enable task distribution
|
||||
# - run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="e2e-ci"
|
||||
- uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: 20
|
||||
cache: 'npm'
|
||||
- run: npm ci --legacy-peer-deps
|
||||
- uses: nrwl/nx-set-shas@v4
|
||||
# Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
|
||||
# When you enable task distribution, run the e2e-ci task instead of e2e
|
||||
- run: npx nx affected -t lint test build e2e
|
||||
```
|
||||
|
||||
### Open a Pull Request {% highlightColor="green" %}
|
||||
|
||||
Commit the changes and open a new PR on GitHub.
|
||||
|
||||
```shell
|
||||
git add .
|
||||
git commit -m 'add CI workflow file'
|
||||
git push origin add-workflow
|
||||
```
|
||||
|
||||
When you view the PR on GitHub, you will see a comment from Nx Cloud that reports on the status of the CI run.
|
||||
|
||||
|
||||
|
||||
The `See all runs` link goes to a page with the progress and results of tasks that were run in the CI pipeline.
|
||||
|
||||
|
||||
|
||||
For more information about how Nx can improve your CI pipeline, check out one of these detailed tutorials:
|
||||
|
||||
- [Circle CI with Nx](/ci/intro/tutorials/circle)
|
||||
- [GitHub Actions with Nx](/ci/intro/tutorials/github-actions)
|
||||
|
||||
## Next Steps
|
||||
|
||||
Connect with the rest of the Nx community with these resources:
|
||||
|
||||
- ⭐️ [Star us on GitHub](https://github.com/nrwl/nx) to show your support and stay updated on new releases!
|
||||
- [Join the Official Nx Discord Server](https://go.nx.dev/community) to ask questions and find out the latest news about Nx.
|
||||
- [Follow Nx on Twitter](https://twitter.com/nxdevtools) to stay up to date with Nx news
|
||||
- [Read our Nx blog](/blog)
|
||||
- [Subscribe to our Youtube channel](https://www.youtube.com/@nxdevtools) for demos and Nx insights
|
||||
@@ -2,12 +2,15 @@ import {
|
||||
checkFilesDoNotExist,
|
||||
checkFilesExist,
|
||||
cleanupProject,
|
||||
detectPackageManager,
|
||||
getPackageManagerCommand,
|
||||
newProject,
|
||||
readFile,
|
||||
readJson,
|
||||
rmDist,
|
||||
runCLI,
|
||||
runCLIAsync,
|
||||
runCommand,
|
||||
uniq,
|
||||
updateFile,
|
||||
updateJson,
|
||||
@@ -187,4 +190,23 @@ describe('js e2e', () => {
|
||||
'Test Suites: 1 passed, 1 total'
|
||||
);
|
||||
}, 500_000);
|
||||
|
||||
it('should not update dependencies if they already exist', () => {
|
||||
const lib = uniq('@my-org/mylib');
|
||||
const currentJestVersion = '28.0.0';
|
||||
const pm = detectPackageManager();
|
||||
// set jest version
|
||||
updateJson('package.json', (json) => {
|
||||
json.devDependencies['jest'] = currentJestVersion;
|
||||
return json;
|
||||
});
|
||||
|
||||
runCommand(getPackageManagerCommand({ packageManager: pm }).install);
|
||||
|
||||
runCLI(`generate @nx/js:lib ${lib} --bundler=tsc --unitTestRunner=jest`);
|
||||
|
||||
const jestVersionAfterInstall =
|
||||
readJson('package.json').devDependencies['jest'];
|
||||
expect(jestVersionAfterInstall).toEqual(currentJestVersion);
|
||||
});
|
||||
});
|
||||
|
||||
@@ -56,7 +56,7 @@ export default function NxDocumentation({
|
||||
}
|
||||
|
||||
export const getStaticPaths: GetStaticPaths = () => {
|
||||
const reservedPaths = ['/ci', '/nx-api', '/changelog'];
|
||||
const reservedPaths = ['/ci', '/nx-api', '/changelog', '/tutorials'];
|
||||
return {
|
||||
paths: nxDocumentationApi
|
||||
.getSlugsStaticDocumentPaths()
|
||||
|
||||
@@ -16,6 +16,7 @@ export default function CustomApp({
|
||||
}: AppProps): JSX.Element {
|
||||
const router = useRouter();
|
||||
const gaMeasurementId = 'UA-88380372-10';
|
||||
const gtmMeasurementId = 'GTM-KW8423B6';
|
||||
|
||||
useEffect(() => {
|
||||
const handleRouteChange = (url: URL) =>
|
||||
@@ -116,14 +117,14 @@ export default function CustomApp({
|
||||
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
|
||||
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
|
||||
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
|
||||
})(window,document,'script','dataLayer','${gaMeasurementId}');
|
||||
})(window,document,'script','dataLayer','${gtmMeasurementId}');
|
||||
`,
|
||||
}}
|
||||
/>
|
||||
{/* Google Tag Manager - NoScript */}
|
||||
<noscript>
|
||||
<iframe
|
||||
src={`https://www.googletagmanager.com/ns.html?id=${gaMeasurementId}`}
|
||||
src={`https://www.googletagmanager.com/ns.html?id=${gtmMeasurementId}`}
|
||||
height="0"
|
||||
width="0"
|
||||
style={{ display: 'none', visibility: 'hidden' }}
|
||||
|
||||
@@ -62,7 +62,7 @@ export default function Tutorials(): JSX.Element {
|
||||
<TutorialCard
|
||||
title="TypeScript Monorepo"
|
||||
type="Tutorial"
|
||||
url="/tutorials/1-ts-packages/1-introduction/1-welcome"
|
||||
url="/tutorials/1-ts-packages/1t-introduction/1-welcome"
|
||||
icon="jsMono"
|
||||
/>
|
||||
<TutorialCard
|
||||
@@ -80,7 +80,7 @@ export default function Tutorials(): JSX.Element {
|
||||
<TutorialCard
|
||||
title="Gradle Monorepo"
|
||||
type="Tutorial"
|
||||
url="/getting-started/tutorials/gradle-tutorial"
|
||||
url="/tutorials/4-gradle/1g-introduction/1-welcome"
|
||||
icon="gradle"
|
||||
/>
|
||||
</dl>
|
||||
|
||||
@@ -600,42 +600,42 @@ for (const path of oldAngularTutorialPaths) {
|
||||
*/
|
||||
const standaloneTutorialRedirects = {
|
||||
'/showcase/example-repos/react-nx':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/react-tutorial': '/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-tutorial': '/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-tutorial/1-code-generation':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-tutorial/2-project-graph':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-tutorial/3-task-running':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-tutorial/4-task-pipelines':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-tutorial/5-summary':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-standalone-tutorial':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-standalone-tutorial/1-code-generation':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-standalone-tutorial/2-project-graph':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-standalone-tutorial/3-task-running':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-standalone-tutorial/4-task-pipelines':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/react-standalone-tutorial/5-summary':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/angular-standalone-tutorial':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-standalone-tutorial/1-code-generation':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-standalone-tutorial/2-project-graph':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-standalone-tutorial/3-task-running':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-standalone-tutorial/4-task-pipelines':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-standalone-tutorial/5-summary':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
};
|
||||
|
||||
const packagesIndexes = {
|
||||
@@ -773,17 +773,17 @@ const conceptUrls = {
|
||||
'/concepts/more-concepts/global-nx':
|
||||
'/getting-started/installation#installing-nx-globally',
|
||||
'/getting-started/package-based-repo-tutorial':
|
||||
'/getting-started/tutorials/typescript-packages-tutorial',
|
||||
'/tutorials/1-ts-packages/1t-introduction/1-welcome',
|
||||
'/getting-started/tutorials/package-based-repo-tutorial':
|
||||
'/getting-started/tutorials/typescript-packages-tutorial',
|
||||
'/tutorials/1-ts-packages/1t-introduction/1-welcome',
|
||||
'/getting-started/integrated-repo-tutorial':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/getting-started/tutorials/integrated-repo-tutorial':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/getting-started/react-standalone-tutorial':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/getting-started/angular-standalone-tutorial':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/concepts/more-concepts/micro-frontend-architecture':
|
||||
'/concepts/module-federation/micro-frontend-architecture',
|
||||
'/concepts/more-concepts/faster-builds-with-module-federation':
|
||||
@@ -799,35 +799,45 @@ const conceptUrls = {
|
||||
|
||||
const nested5minuteTutorialUrls = {
|
||||
'/tutorials/package-based-repo-tutorial':
|
||||
'/getting-started/tutorials/typescript-packages-tutorial',
|
||||
'/tutorials/1-ts-packages/1t-introduction/1-welcome',
|
||||
'/getting-started/tutorials/npm-workspaces-tutorial':
|
||||
'/getting-started/tutorials/typescript-packages-tutorial',
|
||||
'/tutorials/1-ts-packages/1t-introduction/1-welcome',
|
||||
'/tutorials/integrated-repo-tutorial':
|
||||
'/getting-started/tutorials/integrated-repo-tutorial',
|
||||
'/tutorials/react-standalone-tutorial':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/getting-started/tutorials/react-standalone-tutorial':
|
||||
'/getting-started/tutorials/react-monorepo-tutorial',
|
||||
'/tutorials/2-react-monorepo/1r-introduction/1-welcome',
|
||||
'/tutorials/angular-standalone-tutorial':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/getting-started/tutorials/angular-standalone-tutorial':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/getting-started/tutorials/vue-standalone-tutorial':
|
||||
'/getting-started/tutorials',
|
||||
'/tutorials/node-server-tutorial': '/getting-started/tutorials',
|
||||
'/angular-tutorial': '/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/angular-tutorial':
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-tutorial/1-code-generation':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/getting-started/angular-monorepo-tutorial':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-tutorial/2-project-graph':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-tutorial/3-task-running':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-tutorial/4-workspace-optimization':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/angular-tutorial/5-summary':
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial',
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/getting-started/tutorials': '/tutorials',
|
||||
'/getting-started/tutorials/typescript-packages-tutorial':
|
||||
'/tutorials/1-ts-packages/1t-introduction/1-welcome',
|
||||
'/getting-started/tutorials/react-monorepo-tutorial':
|
||||
'/tutorials/2-react-monorepo/1a-introduction/1-welcome',
|
||||
'/getting-started/tutorials/angular-monorepo-tutorial':
|
||||
'/tutorials/3-angular-monorepo/1a-introduction/1-welcome',
|
||||
'/getting-started/tutorials/gradle-tutorial':
|
||||
'/tutorials/4-gradle/1a-introduction/1-welcome',
|
||||
};
|
||||
|
||||
const pluginUrls = {
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
// TODO(isaac): nx build tutorial is caching when there are template changes
|
||||
// Bust: 3
|
||||
@@ -15,8 +15,10 @@ export function applyFileChangesPlugin(): ExpressiveCodePlugin {
|
||||
applyFileChangesTexts,
|
||||
(codeBlock, isTerminal) =>
|
||||
!isTerminal &&
|
||||
['solution:', 'file:'].some((prefix) =>
|
||||
codeBlock.metaOptions.getString('path')?.startsWith(prefix)
|
||||
['solution:', 'file:'].some(
|
||||
(prefix) =>
|
||||
codeBlock.metaOptions.getString('path')?.startsWith(prefix) &&
|
||||
!codeBlock.metaOptions.getBoolean('no-apply')
|
||||
),
|
||||
(codeBlock, _) => {
|
||||
return {
|
||||
|
||||
@@ -17,7 +17,8 @@ export function runInTerminalPlugin(): ExpressiveCodePlugin {
|
||||
'runInTerminal',
|
||||
svg,
|
||||
runInTerminalTexts,
|
||||
(_, isTerminal) => isTerminal,
|
||||
(codeBlock, isTerminal) =>
|
||||
isTerminal && !codeBlock.metaOptions.getBoolean('no-run'),
|
||||
(codeBlock, _) => {
|
||||
// remove comment lines starting with `#` from terminal frames
|
||||
let code = codeBlock.code.replace(/(?<=^|\n)\s*#.*($|\n+)/g, '').trim();
|
||||
|
||||
@@ -78,7 +78,7 @@ export function GlobalCustomizations() {
|
||||
// Apply file changes
|
||||
async function applyFileChanges(e: any) {
|
||||
const { filepath } = e.detail;
|
||||
if (!filepath) {
|
||||
if (!filepath || !(tutorialStore as any)._lessonSolution[filepath]) {
|
||||
return;
|
||||
}
|
||||
tutorialStore.updateFile(
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ previews:
|
||||
If you run `nx graph` as instructed, you'll see the dependencies between your projects.
|
||||
|
||||
```shell {% path="~/tuskydesigns" %}
|
||||
npx nx graph --focus=@tuskdesign/zoo
|
||||
nx graph --focus=@tuskdesign/zoo
|
||||
```
|
||||
|
||||
Nx uses this graph to determine the order tasks are run and enforce module boundaries. You can also leverage this graph to gain an accurate understanding of the architecture of your codebase. Part of what makes this graph invaluable is that it is derived directly from your codebase, so it will never become out of date.
|
||||
+1
-1
@@ -19,5 +19,5 @@ The `serve` target's `dependsOn` line makes Nx run the `build` task for the curr
|
||||
Now `nx serve` will run the `build` task before running the `serve` task.
|
||||
|
||||
```shell
|
||||
npx nx serve zoo
|
||||
nx serve zoo
|
||||
```
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user