docs(misc): remove /nx-api pages (#31453)
This PR removes the `/nx-api` pages from `nx-dev`. They are already redirected from `/nx-api` to either `/technologies` or `/reference/core-api` URLs. e.g. `/nx-api/nx` goes to `/reference/core-api/nx` and `/nx-api/react` goes to `/technologies/react/api` **Changes**: - Remove old `nx-api.json` from being generated in `scripts/documentation/generators/generate-manifests.ts` -- this was used to generate the sitemap - Remove `pages/nx-api` from Next.js app since we don't need them - Remove workaround from link checker `scripts/documentation/internal-link-checker.ts` -- the angular rspack/rsbuild and other workarounds are gone now that they are proper docs in `map.json` - Update Powerpack/Remote Cache reference docs to exclude API documents (since they are duplicated in the Intro page) -- `nx-dev/models-document/src/lib/mappings.ts` - All content in `docs` have been updated with new URL structure **Note:** Redirects are already handled, and Claude Code was used to verify the updated `docs/` URLs (see report below). The twelve 404s links were updated by hand. ## Verification Report https://gist.github.com/jaysoo/c7863fe7e091cb77929d1976165c357a
This commit is contained in:
Jack Hsu
GitHub
parent
733122bc9d
commit
66eaf2fc74
@ -65,7 +65,7 @@ Tailwind is a utility-first CSS framework packed with classes that can be compos
|
||||
nx g @nrwl/angular:app my-app --addTailwind
|
||||
```
|
||||
|
||||
Read more about Angular and Tailwind in our [docs](/nx-api/angular/generators/setup-tailwind).
|
||||
Read more about Angular and Tailwind in our [docs](/technologies/angular/api/generators/setup-tailwind).
|
||||
|
||||
### Other Highlights 🗒
|
||||
|
||||
|
||||
@ -129,7 +129,7 @@ Many of these generators come with a rich set of flags. For example, passing `--
|
||||
|
||||
**How do we find all these generators though?** There are different options:
|
||||
|
||||
- **Nx documentation** — use the search function there or just navigate the docs. All the reference pages are structured like `nx.dev/packages/<packagename>`. As an example for React that would look like: [/nx-api/react](/nx-api/react).
|
||||
- **Nx documentation** — use the search function there or just navigate the docs. All the reference pages are structured like `nx.dev/packages/<packagename>`. As an example for React that would look like: [/nx-api/react](/technologies/react/api).
|
||||
- `npx nx list` - lists a set of installed plugins as well as other available plugins that can be installed. To get a list of generators for a specific plugin - say for the `@nrwl/react` plugin - run `npx nx list @nrwl/react`. Similarly, you can then run `npx nx g @nrwl/react:lib --help` to get help for a particular generator
|
||||
|
||||
However, the absolute easiest way to explore the potential and even use Nx if you are not the "terminal type of person" is [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)! I'll go a bit deeper into that in a later section.
|
||||
@ -273,7 +273,7 @@ One of the advantages of using Nx over — say CRA or a custom starter template
|
||||
|
||||
Just to mention an example: when upgrading Nx to v13, all Nx users automatically got migrated to Webpack 5.
|
||||
|
||||
This is possible with Nx's [migrate command](/nx-api/nx/documents/migrate) that allows you to keep up to date with your framework in a mostly automated fashion. Whenever you upgrade Nx, you run
|
||||
This is possible with Nx's [migrate command](/reference/core-api/nx/documents/migrate) that allows you to keep up to date with your framework in a mostly automated fashion. Whenever you upgrade Nx, you run
|
||||
|
||||
```shell
|
||||
npx nx migrate latest
|
||||
@ -346,7 +346,7 @@ Here's the `project.json` for our `happynrwl` React application. I clipped out t
|
||||
}
|
||||
```
|
||||
|
||||
As you can see, all these "targets" (`build`, `serve`,...) have a so-called `options` property that allows you to configure how the target behaves. The actual configuration is abstracted behind the "[Nx Executor](/concepts/executors-and-configurations)", in our case `@nrwl/web:webpack`. You can find the details of how to configure that on the Nx docs in the CLI reference for the `@nrwl/web` package: [/nx-api/webpack/executors/webpack](/nx-api/webpack/executors/webpack).
|
||||
As you can see, all these "targets" (`build`, `serve`,...) have a so-called `options` property that allows you to configure how the target behaves. The actual configuration is abstracted behind the "[Nx Executor](/concepts/executors-and-configurations)", in our case `@nrwl/web:webpack`. You can find the details of how to configure that on the Nx docs in the CLI reference for the `@nrwl/web` package: [/nx-api/webpack/executors/webpack](/technologies/build-tools/webpack/api/executors/webpack).
|
||||
|
||||
To read more about how the `project.json`, its executors, and configuration options are structured, check out the official docs: [/reference/project-configuration](/reference/project-configuration).
|
||||
|
||||
@ -356,8 +356,8 @@ Nx's extensibility and customizability have really no limits, allowing it to rea
|
||||
|
||||
- [Custom workspace executors](/extending-nx/recipes/local-executors)
|
||||
- [Custom workspace generators](/extending-nx/recipes/local-generators)
|
||||
- [Create Nx plugins](/nx-api/plugin)
|
||||
- Control the entire workspace setup with [custom presets](/nx-api/plugin)
|
||||
- [Create Nx plugins](/reference/core-api/plugin)
|
||||
- Control the entire workspace setup with [custom presets](/reference/core-api/plugin)
|
||||
|
||||
## Q: Can I customize my Webpack config used to build my React app?
|
||||
|
||||
|
||||
@ -36,7 +36,7 @@ Nx can be used in a wide range of scenarios, from small open source projects, st
|
||||
- `@nrwl/*` plugins which are those actively maintained by the Nx core team
|
||||
- [Community plugins](/community)
|
||||
|
||||
This illustration should give you a rough idea. obviously some of the plugins may be built on top of others, leveraging common functionality. An example is the [@nrwl/js](/nx-api/js) plugin which not only can be used as a standalone plugin but also builds the basis for of many others by providing core JavaScript/TypeScript features.
|
||||
This illustration should give you a rough idea. obviously some of the plugins may be built on top of others, leveraging common functionality. An example is the [@nrwl/js](/technologies/typescript/api) plugin which not only can be used as a standalone plugin but also builds the basis for of many others by providing core JavaScript/TypeScript features.
|
||||
|
||||
|
||||
|
||||
@ -206,7 +206,7 @@ If however you're curious, you can now append `--allPrompts` to get all possible
|
||||
npx create-nx-workspace@next myorg --allPrompts
|
||||
```
|
||||
|
||||
Alternatively you can browse the [API docs on the Nx website](/nx-api/nx/documents/create-nx-workspace) to find out more.
|
||||
Alternatively you can browse the [API docs on the Nx website](/reference/core-api/nx/documents/create-nx-workspace) to find out more.
|
||||
|
||||
## Deliver the best possible TypeScript experience with `@nrwl/js`
|
||||
|
||||
@ -242,7 +242,7 @@ Learn more in this short video walkthrough:
|
||||
|
||||
## Our docs keep getting more and more awesome
|
||||
|
||||
Besides delivering awesome features, we keep improving our docs. They are essential to help discover new features and better understand existing ones. In the last weeks we've improved the navigation support, allowing you to navigate to a specific package with `/packages/<package-name>` such as [/nx-api/react](/nx-api/react) listing executors and generators that come with that Nx package, also improving the API docs of the individual executor options including a live embedded editor playground to experiment with different configuration setup.
|
||||
Besides delivering awesome features, we keep improving our docs. They are essential to help discover new features and better understand existing ones. In the last weeks we've improved the navigation support, allowing you to navigate to a specific package with `/packages/<package-name>` such as [/nx-api/react](/technologies/react/api) listing executors and generators that come with that Nx package, also improving the API docs of the individual executor options including a live embedded editor playground to experiment with different configuration setup.
|
||||
|
||||
Check out Benjamin Cabanes' tweet with some short videos:
|
||||
|
||||
|
||||
@ -74,7 +74,7 @@ Also see this example repository with some more information: [https://github.com
|
||||
|
||||
## Simplifying Nx
|
||||
|
||||
Nx follows a modular plugin architecture. There is the core part of Nx which has the main logic around managing the project graph, computation caching, hashing and more. On top of that we have a series of Nx provided plugins for some of the most common frameworks and libraries out there, like [TypeScript/Javascript](/nx-api/js), [Angular](/nx-api/angular), [React](/nx-api/react) & [React Native](/nx-api/react-native), [Next.js](/nx-api/next), [Nest.js](/nx-api/nest), [Node](/nx-api/node) and many more, not to forget about [all the community plugins](/community). We also have a [labs project section](https://github.com/nrwl/nx-labs) which is our incubator for potentially new, natively supported Nx plugins.
|
||||
Nx follows a modular plugin architecture. There is the core part of Nx which has the main logic around managing the project graph, computation caching, hashing and more. On top of that we have a series of Nx provided plugins for some of the most common frameworks and libraries out there, like [TypeScript/Javascript](/technologies/typescript/api), [Angular](/technologies/angular/api), [React](/technologies/react/api) & [React Native](/technologies/react/react-native/api), [Next.js](/technologies/react/next/api), [Nest.js](/technologies/node/nest/api), [Node](/technologies/node/api) and many more, not to forget about [all the community plugins](/community). We also have a [labs project section](https://github.com/nrwl/nx-labs) which is our incubator for potentially new, natively supported Nx plugins.
|
||||
|
||||
This modular structure allows you to just use [Nx core without plugins](/getting-started/intro). An ideal approach if you want to add Nx to an [existing Lerna/Yarn/NPM/PNPM workspace](/recipes/adopting-nx/adding-to-monorepo). With v14 we made it even simpler s.t. now you only have a single `nx` package in your dependencies with the core setup.
|
||||
|
||||
@ -250,7 +250,7 @@ Nx v14 ships with React 18 support for React DOM and React Native. The latter ha
|
||||
|
||||
In addition to that, Expo and Expo Application Service support has been added which has lead already to some drastic speed improvements with some of our clients.
|
||||
|
||||
Finally, it is the first version which ships the built-in module federation support for React as we've mentioned a couple of sections above. Check out the React package docs page and search for the `host` and `remote` generator: [/nx-api/react](/nx-api/react)
|
||||
Finally, it is the first version which ships the built-in module federation support for React as we've mentioned a couple of sections above. Check out the React package docs page and search for the `host` and `remote` generator: [/nx-api/react](/technologies/react/api)
|
||||
|
||||
## Angular
|
||||
|
||||
@ -258,7 +258,7 @@ There have been a lot of highlights for the Nx Angular plugin since v13. Here ar
|
||||
|
||||
- Support and migrations for Angular 13 (Angular v14 coming soon. We will release that as a minor upgrade in Nx once the Angular team releases v14)
|
||||
- Tailwind CSS support (generators, added support to library executors). Read [our blog detailed post](/blog/set-up-tailwind-css-with-angular-in-an-nx-workspace).
|
||||
- Single Component Application Modules (SCAM) generators for components, directives and pipes ([see our docs](/nx-api/angular))
|
||||
- Single Component Application Modules (SCAM) generators for components, directives and pipes ([see our docs](/technologies/angular/api))
|
||||
- Improved Angular CLI to Nx migration support. We invested quite some time refactoring our current migration support from the Angular CLI which not only will allow us to implement more migration scenarios in the future but it also provides better error messages and hints during the migration process. This also allowed us to add support for multi-project Angular CLI workspaces which can now be seamlessly migrated. Multi-application Angular CLI workspace support will be added soon.
|
||||
|
||||
Finally, similar to React also Angular gets built-in support for Webpack Module federation and hence also Microfrontends within Nx. See the sections about Module Federation and Microservices for more info and links to the docs.
|
||||
|
||||
@ -37,7 +37,7 @@ You can also append the `--generate-tests` to automatically generate Cypress com
|
||||
nx g @nrwl/react:cypress-component-configuration --project=my-react-project --generate-tests
|
||||
```
|
||||
|
||||
Check out our [generator docs](/nx-api/react/generators/cypress-component-configuration) for more info.
|
||||
Check out our [generator docs](/technologies/react/api/generators/cypress-component-configuration) for more info.
|
||||
|
||||
{% youtube src="https://youtu.be/QDWN4C7T-Ck" /%}
|
||||
|
||||
|
||||
@ -198,9 +198,9 @@ If you are currently using the NxExt based Vite plugin, or even a Webpack based
|
||||
npx nx g @nrwl/vite:configuration
|
||||
```
|
||||
|
||||
This will adjust the NxExt Vite plugin configuration to match the one provided by our core team. Check out our docs for more info: [/nx-api/vite/generators/configuration](/nx-api/vite/generators/configuration)
|
||||
This will adjust the NxExt Vite plugin configuration to match the one provided by our core team. Check out our docs for more info: [/technologies/build-tools/vite/generators/configuration](/technologies/build-tools/vite/api/generators/configuration)
|
||||
|
||||
You can also find all the details about the new Vite package in our docs: [/nx-api/vite](/nx-api/vite)
|
||||
You can also find all the details about the new Vite package in our docs: [/technologies/build-tools/vite](/technologies/build-tools/vite/api)
|
||||
|
||||
## Adopting Nx has never been easier
|
||||
|
||||
|
||||
@ -30,17 +30,17 @@ Nx 15.4 brings in the latest Vite major version following the Vite 4 release ear
|
||||
|
||||
As the [Vite launch article](https://vitejs.dev/blog/announcing-vite4.html) mentions, we are investing in the Vite ecosystem, and now officially support a first-party Vite plugin. Nx 15.4 continues this investment with timely support for Vite 4, and we're excited to be a part of the Vite ecosystem and a part of bringing more value to our devs through Vite support!
|
||||
|
||||
Projects already using our [@nrwl/vite plugin](/nx-api/vite) will be automatically upgraded to Vite 4 when they upgrade to the latest Nx version with the `nx migrate` command, and we've also simplified the configuration required to support Vite.
|
||||
Projects already using our [@nrwl/vite plugin](/technologies/build-tools/vite/api) will be automatically upgraded to Vite 4 when they upgrade to the latest Nx version with the `nx migrate` command, and we've also simplified the configuration required to support Vite.
|
||||
|
||||
We've also spent some effort into making the conversion of existing projects to use Vite simpler, including:
|
||||
|
||||
- the ability to choose which targets you want to convert
|
||||
- enhanced `vite.config.ts` file configuration
|
||||
- better DX with detailed messages during conversion
|
||||
- [better documentation around converting using our generator](/nx-api/vite/generators/configuration)
|
||||
- [better documentation around converting using our generator](/technologies/build-tools/vite/api/generators/configuration)
|
||||
- [adding a guide to our docs for converting manually](/technologies/build-tools/vite/recipes/configure-vite)
|
||||
|
||||
You can check out more details about our Vite plugin including how to add Vite and Vitest to your existing Nx workspace by visiting our docs at [nx.dev/nx-api/vite](/nx-api/vite)
|
||||
You can check out more details about our Vite plugin including how to add Vite and Vitest to your existing Nx workspace by visiting our docs at [nx.dev/technologies/build-tools/vite](/technologies/build-tools/vite/api)
|
||||
|
||||
## Nx Watch
|
||||
|
||||
|
||||
@ -56,7 +56,7 @@ Answer with the following:
|
||||
|
||||
When your workspace is created, run `cd myorg`.
|
||||
|
||||
Next, we will need to install the [Official Nx Angular Plugin](/nx-api/angular):
|
||||
Next, we will need to install the [Official Nx Angular Plugin](/technologies/angular/api):
|
||||
|
||||
```
|
||||
npm install @nrwl/angular
|
||||
|
||||
@ -200,7 +200,7 @@ This might look weird initially, but basically, we run the `e2e` target (see `e2
|
||||
|
||||
By default, these tests run in headless mode, but you can pass `--watch` to run it interactively with the Cypress test runner such that the tests get re-executed whenever we change our source.
|
||||
|
||||
> _Want Cypress Component testing? There's an Nx generator that can help set that up. Check out the docs:_ [_/nx-api/react/generators/cypress-component-configuration_](/nx-api/react/generators/cypress-component-configuration)
|
||||
> _Want Cypress Component testing? There's an Nx generator that can help set that up. Check out the docs:_ [_/nx-api/react/generators/cypress-component-configuration_](/technologies/react/api/generators/cypress-component-configuration)
|
||||
|
||||
## Linting
|
||||
|
||||
|
||||
@ -135,7 +135,7 @@ Stay tuned for a more in-depth blog post coming soon to [our blog](/blog).
|
||||
|
||||
Nx provides support for Storybook version 7.0 beta, with generators and executors, so that you can try it out now, either in a new or in your existing Nx workspace. Storybook version 7 is a major release that brings a lot of new features and improvements. You can read more about it in the [Storybook 7 beta announcement blog post](https://storybook.js.org/blog/7-0-beta/). Apart from the new features and enhancements, it also brings some breaking changes. You can read more about them in the [Storybook 7 migration docs](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-65x-to-700) and the [Storybook 7 migration guide](https://chromatic-ui.notion.site/Storybook-7-migration-guide-dbf41fa347304eb2a5e9c69b34503937). Do note that _version 7 is still in beta_, and so is the Nx support for it.
|
||||
|
||||
You can try out Storybook 7.0 beta in a new Nx workspace by passing the `--storybook7betaConfiguration` flag when generating the Storybook configuration for your projects. Read more in our [Storybook 7 setup guide](/technologies/test-tools/storybook/recipes/best-practices). If you want to migrate your existing Storybook configuration to Storybook 7.0 beta, please read our [migration guide](/nx-api/storybook/generators/migrate-7).
|
||||
You can try out Storybook 7.0 beta in a new Nx workspace by passing the `--storybook7betaConfiguration` flag when generating the Storybook configuration for your projects. Read more in our [Storybook 7 setup guide](/technologies/test-tools/storybook/recipes/best-practices). If you want to migrate your existing Storybook configuration to Storybook 7.0 beta, please read our [migration guide](/technologies/test-tools/storybook/api/generators/migrate-7).
|
||||
|
||||
## More flexible Webpack config
|
||||
|
||||
@ -147,7 +147,7 @@ Previously when you created a new React application with the Nx `@nrwl/react` pl
|
||||
|
||||
It was for a good reason, but at the same time, it is a thin line to walk between giving more flexibility and ensuring integrity and consistency (not to speak about features such as [automated code migrations](/features/automate-updating-dependencies)). We wrote a [blog post about it last week](/blog/configuration-files-and-potholes-in-your-codebase).
|
||||
|
||||
Inspired by our new [Vite setup](/nx-api/vite), which allows for a more modular configuration in the `vite.config.ts`, we wanted to bring some of the same flexibility to our Webpack setup as well. As such, now every Nx Webpack setup (e.g. a new React + Webpack based app) have a `webpack.config.js` in the project root. Old project are automatically migrated to this new setup.
|
||||
Inspired by our new [Vite setup](/technologies/build-tools/vite/api), which allows for a more modular configuration in the `vite.config.ts`, we wanted to bring some of the same flexibility to our Webpack setup as well. As such, now every Nx Webpack setup (e.g. a new React + Webpack based app) have a `webpack.config.js` in the project root. Old project are automatically migrated to this new setup.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -203,7 +203,7 @@ host apps and libraries in any language. With the newly released [**_Encapsulate
|
||||
The codebase contains both Typescript code for the VSCode extension and Kotlin code for the IntelliJ plugin. Currently,
|
||||
all the Kotlin code resides in a single app. Targets defined in `project.json` are available that wrap different gradle
|
||||
tasks like running a development instance, building or formatting the plugin using the
|
||||
[`nx:run-commands`](/nx-api/nx/executors/run-commands) executor.
|
||||
[`nx:run-commands`](/reference/core-api/nx/executors/run-commands) executor.
|
||||
Since the plugin depends on artifacts provided by other Nx apps (namely the `nxls` and `generate-ui`), we have also
|
||||
created gradle tasks that call Nx to build these dependencies under the hood. This roundabout way of calling one tool
|
||||
from the other (and back again) could definitely be improved and we might look into having a more straightforward
|
||||
|
||||
@ -137,7 +137,7 @@ Read all the details [on our blog post](/blog/expanding-nx-console-to-jetbrains-
|
||||
|
||||
{% youtube src="https://youtu.be/JJ12zKedwIs" /%}
|
||||
|
||||
Nx Console has proven a highly valuable tool for exploring Nx generators. Especially if you cannot recall all the various parameters, you can possibly pass. And sure, you could always pass the `--help` or browse [the docs](/nx-api/react/generators/library), but it is just less convenient.
|
||||
Nx Console has proven a highly valuable tool for exploring Nx generators. Especially if you cannot recall all the various parameters, you can possibly pass. And sure, you could always pass the `--help` or browse [the docs](/technologies/react/api/generators/library), but it is just less convenient.
|
||||
|
||||
|
||||
|
||||
@ -164,7 +164,7 @@ Read all about it [in the doc about Customizing Generator Options](/extending-nx
|
||||
|
||||
## Modular Node Applications
|
||||
|
||||
Nx has had Node backend support since the beginning, where you could add an [ExpressJS](/nx-api/express) or [Nest.js](/nx-api/nest) based application to your monorepo. This is a powerful approach as it allows you to colocate your frontend and backend code, which helps share code and, in particular, TypeScript types for your APIs!!
|
||||
Nx has had Node backend support since the beginning, where you could add an [ExpressJS](/technologies/node/express/api) or [Nest.js](/technologies/node/nest/api) based application to your monorepo. This is a powerful approach as it allows you to colocate your frontend and backend code, which helps share code and, in particular, TypeScript types for your APIs!!
|
||||
|
||||
In [Nx 15.7](/blog/nx-15-7-node-support-angular-lts-lockfile-pruning), we then announced [Nx Standalone Projects](https://youtu.be/qEaVzh-oBBc) support for Node. This allows to develop a Node backend in isolation but still leverages all the features from Nx in terms of code generators, automated migrations, and speed features such as [affected commands](/ci/features/affected), [caching](/concepts/how-caching-works), and [optimized CI setups](/ci/features/distribute-task-execution).
|
||||
|
||||
|
||||
@ -70,11 +70,11 @@ This creates a new application in your Nx monorepo that uses Rspack as the bundl
|
||||
Go and learn more on the
|
||||
|
||||
- official Rspack website: [https://rspack.dev](https://rspack.dev/)
|
||||
- learn about the Nx Rspack plugin: [/nx-api/rspack](/nx-api/rspack)
|
||||
- learn about the Nx Rspack plugin: [/technologies/build-tools/rspack/introduction](/technologies/build-tools/rspack/api)
|
||||
|
||||
## Learn more
|
||||
|
||||
- 🦀 [Rspack and Nx docs](/nx-api/rspack)
|
||||
- 🦀 [Rspack and Nx docs](/technologies/build-tools/rspack/api)
|
||||
- 🧠 [Nx Docs](/getting-started/intro)
|
||||
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
|
||||
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
|
||||
|
||||
@ -13,7 +13,7 @@ We're proud to announce the release of Nx version 16! In this article, we'll go
|
||||
But before we jump into the new features of Nx 16, let's recap some of the recent features from our Nx 15 minor releases!
|
||||
|
||||
- We introduced simpler presets for React, Angular, and [Node starter applications](https://youtu.be/K4f-fMuAoRY)
|
||||
- We added official support for [Vite](/nx-api/vite) and Vitest for integrated Nx monorepos
|
||||
- We added official support for [Vite](/technologies/build-tools/vite/api) and Vitest for integrated Nx monorepos
|
||||
- We introduced an [official Deno plugin](https://youtu.be/NpH8cFSp51E), including integration for Node and Deno project collocation and project graph support for Deno imports
|
||||
- We added Rust into the Nx codebase to speed up core functionality
|
||||
- We added support for [non-npm workspaces](https://youtu.be/QOhdL02f6BY) to support workspaces focused on other languages like C#, Java, and Kotlin, and saw some of those in action with community plugins for [.NET](https://www.nx-dotnet.com/) and [Java/Kotlin](https://github.com/tinesoft/nxrocks)
|
||||
|
||||
@ -274,7 +274,7 @@ Using it, you get the native look, a11y, and theme-aware styling for free! Thank
|
||||
|
||||
One big upside of using a webview is the huge Javascript ecosystem is available to you! To make sure that no regressions are introduced later on, we use [Cypress](https://www.cypress.io/). We can mock the editor communication and provide different schemas, make sure the form is rendered correctly and the right messages are sent back to the IDE.
|
||||
|
||||
While there's no particular Lit integration for Cypress, the tool itself is framework agnostic so it still works perfectly fine. Using the [`@nx/cypress`](/nx-api/cypress) executors did most of the work for us so setup was pretty quick too.
|
||||
While there's no particular Lit integration for Cypress, the tool itself is framework agnostic so it still works perfectly fine. Using the [`@nx/cypress`](/technologies/test-tools/cypress/api) executors did most of the work for us so setup was pretty quick too.
|
||||
|
||||
### Results: Comparing Performance
|
||||
|
||||
@ -610,7 +610,7 @@ Using it, you get the native look, a11y, and theme-aware styling for free! Thank
|
||||
|
||||
One big upside of using a webview is the huge Javascript ecosystem is available to you! To make sure that no regressions are introduced later on, we use [Cypress](https://www.cypress.io/). We can mock the editor communication and provide different schemas, make sure the form is rendered correctly and the right messages are sent back to the IDE.
|
||||
|
||||
While there’s no particular Lit integration for Cypress, the tool itself is framework agnostic so it still works perfectly fine. Using the [`@nx/cypress`](/nx-api/cypress) executors did most of the work for us so setup was pretty quick too.
|
||||
While there’s no particular Lit integration for Cypress, the tool itself is framework agnostic so it still works perfectly fine. Using the [`@nx/cypress`](/technologies/test-tools/cypress/api) executors did most of the work for us so setup was pretty quick too.
|
||||
|
||||
### Results: Comparing Performance
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ Be sure to mark your calendars for our Nx 16.5 livestream as well! We'll highlig
|
||||
|
||||
Our first major feature actually comes to us from the community. Nx has supported a tags property in your project.json file for awhile now — and it's main purpose has been to be used in conjuncture with the [Nx Module Boundary lint rule](/features/enforce-module-boundaries) to define which projects in your Nx workspace can depend on what — for example, you don't want your frontend applications to depend on any backend-specific code.
|
||||
|
||||
With this new feature, you can add the `--tag` option to the [`nx affected`](/nx-api/nx/documents/affected) and [`nx run-many`](/nx-api/nx/documents/run-many) commands to specify to Nx to only run commands for projects that match the given tags.
|
||||
With this new feature, you can add the `--tag` option to the [`nx affected`](/reference/core-api/nx/documents/affected) and [`nx run-many`](/reference/core-api/nx/documents/run-many) commands to specify to Nx to only run commands for projects that match the given tags.
|
||||
|
||||
{% youtube src="https://youtu.be/enQDQmFquGU" /%}
|
||||
|
||||
|
||||
@ -188,7 +188,7 @@ The preset generator does 2 things:
|
||||
|
||||
_preset generator_
|
||||
|
||||
The `addProjectConfiguration` and `generateFiles` functions are from [@nx/devkit](/nx-api/devkit/documents/nx_devkit), a library that contains utility functions for writing plugins for Nx. For the future, see the [complete list of utility functions](/nx-api/devkit/documents/nx_devkit).
|
||||
The `addProjectConfiguration` and `generateFiles` functions are from [@nx/devkit](/reference/core-api/devkit/documents/nx_devkit), a library that contains utility functions for writing plugins for Nx. For the future, see the [complete list of utility functions](/reference/core-api/devkit/documents/nx_devkit).
|
||||
|
||||
1. Change the project which is created with `addProjectConfiguration`:
|
||||
|
||||
@ -311,7 +311,7 @@ And finally, another file to host the actual HTML template: `src/generators/pres
|
||||
</html>
|
||||
```
|
||||
|
||||
3\. Our application uses some npm dependencies so add those to the workspace as well with the [addDependenciesToPackageJson](/nx-api/devkit/documents/nx_devkit) function to the end of the export default function in `src/generators/preset/generator.ts`:
|
||||
3\. Our application uses some npm dependencies so add those to the workspace as well with the [addDependenciesToPackageJson](/reference/core-api/devkit/documents/nx_devkit) function to the end of the export default function in `src/generators/preset/generator.ts`:
|
||||
|
||||
```
|
||||
import {
|
||||
|
||||
@ -294,7 +294,7 @@ If you want to create a build locally using your own infrastructure:
|
||||
npx nx build cats --local
|
||||
```
|
||||
|
||||
Here is the complete list of flags for the build command: [/nx-api/expo/executors/build](/nx-api/expo/executors/build).
|
||||
Here is the complete list of flags for the build command: [/technologies/react/expo/executors/build](/technologies/react/expo/api/executors/build).
|
||||
|
||||
## Submit to the App Store
|
||||
|
||||
|
||||
@ -282,7 +282,7 @@ Towards the start of the year, we added support for Nx standalone applications.
|
||||
|
||||
Ever since we introduced these, we've had requests from the community to add a generator to convert your standalone workspace to a monorepo setup — to support repos that grew to emcompass more than just the 1 application.
|
||||
|
||||
This is where our new [`convert-to-monorepo` generator](/nx-api/workspace/generators/convert-to-monorepo) comes into play!
|
||||
This is where our new [`convert-to-monorepo` generator](/reference/core-api/workspace/generators/convert-to-monorepo) comes into play!
|
||||
|
||||
```shell
|
||||
nx g convert-to-monorepo
|
||||
@ -332,7 +332,7 @@ You can find all of the examples and more on our "Showcase" section: [/showcase]
|
||||
|
||||
ESLint has announced a new config system — nicknamed "flat config" — whose intent is to be be familiar and much simpler than the current config system. You can read more about this [in their blog post](https://eslint.org/blog/2022/08/new-config-system-part-2/).
|
||||
|
||||
As part of our continued support for ESLint, we've introduced [a new generator](/nx-api/eslint/generators/convert-to-flat-config) to convert your Nx monorepo to this new system:
|
||||
As part of our continued support for ESLint, we've introduced [a new generator](/technologies/eslint/api/generators/convert-to-flat-config) to convert your Nx monorepo to this new system:
|
||||
|
||||
```
|
||||
> nx g convert-to-flat-config
|
||||
|
||||
@ -300,7 +300,7 @@ In this blog, we have:
|
||||
- Used Nx to run Playwright tests
|
||||
- Set up a Playwright configuration for an existing Nx app
|
||||
|
||||
Hopefully, this gives you good insight into how to get started with Playwright. The Playwright configuration in this example is pretty simple, to learn more about `@nx/playwright` plugin, check out the Nx documentation: [/nx-api/playwright](/nx-api/playwright).
|
||||
Hopefully, this gives you good insight into how to get started with Playwright. The Playwright configuration in this example is pretty simple, to learn more about `@nx/playwright` plugin, check out the Nx documentation: [/technologies/test-tools/playwright/introduction](/technologies/test-tools/playwright/api).
|
||||
|
||||
## Learn more
|
||||
|
||||
|
||||
@ -226,7 +226,7 @@ In Nx 17, we removed any remaining traces of `tslint` from our linter package, s
|
||||
|
||||
As we solidify this command, we intend to bring robust support for various versioning and publishing strategies, as well as built-in support for publishing packages or modules to a variety of languages, registries, and platforms.
|
||||
|
||||
For more [checkout our API docs](/nx-api/nx/documents/release), and be sure to catch James Henry's announcement of this new command at [Nx Conf](/blog/nx-conf-2023-recap):
|
||||
For more [checkout our API docs](/reference/core-api/nx/documents/release), and be sure to catch James Henry's announcement of this new command at [Nx Conf](/blog/nx-conf-2023-recap):
|
||||
|
||||
{% youtube src="https://www.youtube.com/embed/p5qW5-2nKqI?si=FzpGMJwPVINc1hgL" /%}
|
||||
|
||||
@ -234,7 +234,7 @@ For more [checkout our API docs](/nx-api/nx/documents/release), and be sure to c
|
||||
|
||||
At Nx, we're OBSESSED with building a better, more robust experience for our developers. Towards this end, we're now in [v2 of our Project Inference API](/extending-nx/recipes/project-graph-plugins).
|
||||
|
||||
This API is a way of extending the Nx project graph, which can be particularly helpful for extending Nx to support other languages, allowing Nx to determine where to find and draw boundaries around projects in your workspace. A great example is our very own [Vue plugin](/nx-api/vue).
|
||||
This API is a way of extending the Nx project graph, which can be particularly helpful for extending Nx to support other languages, allowing Nx to determine where to find and draw boundaries around projects in your workspace. A great example is our very own [Vue plugin](/technologies/vue/api).
|
||||
|
||||
Interestingly, v2 includes support for dynamic targets as well. This opens up exciting new doors to reducing configuration, and we hope to expand on this to better support our first-party plugins in the near future.
|
||||
|
||||
|
||||
@ -706,8 +706,8 @@ Here is a simple app that uses TanStack Query and Redux for state management. Th
|
||||
Nx is a powerful monorepo tool. Together with Nx and these 2 state management tools, it will be very easy to scale up any app.
|
||||
|
||||
- TanStack Query site: [https://tanstack.com/query/latest](https://tanstack.com/query/latest)
|
||||
- Official @nx/expo plugin: [/nx-api/expo](/nx-api/expo)
|
||||
- Official @nx/react-native plugin: [/nx-api/react-native](/nx-api/react-native)
|
||||
- Official @nx/expo plugin: [/technologies/react/expo](/technologies/react/expo/api)
|
||||
- Official @nx/react-native plugin: [/technologies/react/react-native](/technologies/react/react-native/api)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -57,7 +57,7 @@ Our collaboration with our friends in the Vite core team has been incredibly fru
|
||||
|
||||
|
||||
|
||||
We also built some powerful code generators that not only facilitate a seamless [transition from Webpack to Vite](/nx-api/vite/generators/configuration#nxviteconfiguration) but also pave the way for an effortless [migration from a CRA-based setup](/recipes/adopting-nx/adding-to-existing-project) to a modern Nx + Vite based workspace. To see this process in action, [check out this short video](https://www.youtube.com/watch?v=zvYb7XCLQzU).
|
||||
We also built some powerful code generators that not only facilitate a seamless [transition from Webpack to Vite](/technologies/build-tools/vite/api/generators/configuration#nxviteconfiguration) but also pave the way for an effortless [migration from a CRA-based setup](/recipes/adopting-nx/adding-to-existing-project) to a modern Nx + Vite based workspace. To see this process in action, [check out this short video](https://www.youtube.com/watch?v=zvYb7XCLQzU).
|
||||
|
||||
[AnalogJS](https://analogjs.org/) — the fullstack Angular meta-framework which also heavily builds on top of Vite — is using the `@nx/vite` plugin to power its Angular and Nx based workspaces.
|
||||
|
||||
@ -220,7 +220,7 @@ And you'll then have access to Nx generators so you can create Vue applications,
|
||||
|
||||
|
||||
|
||||
Checkout out our [Vue API docs](/nx-api/vue), and stay tuned as Nx prepares to offer more Vue support (including support for [Nuxt](https://nuxt.com/), a full-stack framework built around Vue) in the near future!
|
||||
Checkout out our [Vue API docs](/technologies/vue/api), and stay tuned as Nx prepares to offer more Vue support (including support for [Nuxt](https://nuxt.com/), a full-stack framework built around Vue) in the near future!
|
||||
|
||||
### Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support
|
||||
|
||||
@ -316,7 +316,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.
|
||||
- [**Reference**](/reference) and [**API docs**](/nx-api) — pure, raw and to the point.
|
||||
- [**Reference**](/reference) and [**API docs**](/reference/core-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.
|
||||
|
||||
|
||||
@ -141,7 +141,7 @@ And after running the generator, you can expect your project detail view to look
|
||||
|
||||
Notice that in addition to reducing the configuration in your `project.json` file, this generator will also turn on the Nx Atomizer for your Cypress and Playwright projects, so Nx will allow sharding for your end-to-end tasks in CI based on the tests present in your workspace going forward. Note that Nx Agents are very highly highly encouraged as a way of taking advantage of this sharding capability.
|
||||
|
||||
As a note, if you cannot see `e2e-ci` tasks after converting your cypress projects, you can [take a closer look here](/nx-api/cypress/documents/overview#splitting-e2e-tasks-by-file) at how to configure them correctly.
|
||||
As a note, if you cannot see `e2e-ci` tasks after converting your cypress projects, you can [take a closer look here](/technologies/test-tools/cypress/introduction#splitting-e2e-tasks-by-file) at how to configure them correctly.
|
||||
|
||||
## BREAKING CHANGE: Updating Bundled Environment Variables: `NX_` to `NX_PUBLIC_`
|
||||
|
||||
|
||||
@ -16,4 +16,4 @@ In this episode, welcome Nx Champion and Nx Expert, Tine Kondo. Our discussion h
|
||||
|
||||
We touch on the difficulties larger organizations face when merging PRs in a timely manner, emphasizing how a monorepo alleviates the headache of coordinating multiple PRs across various repositories, and share firsthand experiences and frustrations with traditional multi-repo setups, underscoring the benefits of a unified approach.
|
||||
|
||||
In particular, Nx's new plugin: [@nx/gradle](/nx-api/gradle) is of interest, and Tine provides some valuable insight on the impact this plugin can make, as well as the importance for Maven support.
|
||||
In particular, Nx's new plugin: [@nx/gradle](/technologies/java/api) is of interest, and Tine provides some valuable insight on the impact this plugin can make, as well as the importance for Maven support.
|
||||
|
||||
@ -106,7 +106,7 @@ Note that the new, free [hobby tier for Nx Cloud](#new-nx-cloud-hobby-tier) incl
|
||||
|
||||
## Pattern Support for `targetDefaults`
|
||||
|
||||
When using the [Atomizer features](/ci/features/split-e2e-tasks) of plugins like [`@nx/playwright`](/nx-api/playwright) and [`@nx/cypress`](/nx-api/cypress), you end up creating tasks with dynamic but predictable names.
|
||||
When using the [Atomizer features](/ci/features/split-e2e-tasks) of plugins like [`@nx/playwright`](/technologies/test-tools/playwright/api) and [`@nx/cypress`](/technologies/test-tools/cypress/api), you end up creating tasks with dynamic but predictable names.
|
||||
|
||||
|
||||
|
||||
@ -178,7 +178,7 @@ width="100%" /%}
|
||||
|
||||
## Support For Incremental Builds For Vite
|
||||
|
||||
Nx now supports incremental builds with our [`vite` plugin](/nx-api/vite). Incremental builds in Nx workspaces allow you to build any package in your workspace individually, and will then automatically use that built artifact when then building any project or application that consumes the package. This way you can speed up your build and CI times through optimizations like [only building packages that were affected](/nx-api/nx/documents/affected), using [Nx Replay](/ci/features/remote-cache) to effortlessly cache and share your built artifacts, and allowing you to run builds of your various packages in parallel using [Nx Agents](/ci/features/distribute-task-execution).
|
||||
Nx now supports incremental builds with our [`vite` plugin](/technologies/build-tools/vite/api). Incremental builds in Nx workspaces allow you to build any package in your workspace individually, and will then automatically use that built artifact when then building any project or application that consumes the package. This way you can speed up your build and CI times through optimizations like [only building packages that were affected](/reference/core-api/nx/documents/affected), using [Nx Replay](/ci/features/remote-cache) to effortlessly cache and share your built artifacts, and allowing you to run builds of your various packages in parallel using [Nx Agents](/ci/features/distribute-task-execution).
|
||||
|
||||
Read more about [buildable libraries and incremental builds](/concepts/buildable-and-publishable-libraries).
|
||||
|
||||
@ -194,11 +194,11 @@ npx nx g convert-to-inferred
|
||||
|
||||
The important thing to note here is that while this generator will make adjustments to the `project.json` file of the projects you convert, the behavior of your tasks should remain the same. You can see project details via the [Nx Console](/getting-started/editor-setup) plugin of your IDE, or in a browser by running the command: `nx show project [projectName]`.
|
||||
|
||||
In Nx 19, we were focused on adding `convert-to-inferred` to our [Playwright](/nx-api/playwright), [Cypress](/nx-api/cypress), and [ESLint](/nx-api/eslint) plugins - where bringing the [Nx Atomizer](/ci/features/split-e2e-tasks) provided the greatest value. Since then, we've added this generator to most other plugins. Currently, our React native plugins (react native, expo, detox) are the only plugins that are outstanding, and we'll be providing `convert-to-inferred` generators here in the near future.
|
||||
In Nx 19, we were focused on adding `convert-to-inferred` to our [Playwright](/technologies/test-tools/playwright/api), [Cypress](/technologies/test-tools/cypress/api), and [ESLint](/technologies/eslint/api) plugins - where bringing the [Nx Atomizer](/ci/features/split-e2e-tasks) provided the greatest value. Since then, we've added this generator to most other plugins. Currently, our React native plugins (react native, expo, detox) are the only plugins that are outstanding, and we'll be providing `convert-to-inferred` generators here in the near future.
|
||||
|
||||
## Gradle Composite Builds Support
|
||||
|
||||
In [Nx 19.0](/blog/nx-19-release), we introduced support for Gradle through our [Gradle plugin](/nx-api/gradle). With the latest update, this plugin now also supports [Gradle Composite builds](https://docs.gradle.org/current/userguide/composite_builds.html), in addition to multi-project builds.
|
||||
In [Nx 19.0](/blog/nx-19-release), we introduced support for Gradle through our [Gradle plugin](/technologies/java/api). With the latest update, this plugin now also supports [Gradle Composite builds](https://docs.gradle.org/current/userguide/composite_builds.html), in addition to multi-project builds.
|
||||
|
||||
Gradle Composite builds are commonly used in larger workspaces to manage dependencies across multiple projects. With this new support, Nx can now leverage composite builds to enhance the Nx Task Graph. For example, consider the following `settings.gradle.kts` file:
|
||||
|
||||
@ -217,7 +217,7 @@ You can read more on composite builds in the [Gradle documentation](https://docs
|
||||
|
||||
## Experimental: Gradle Test Atomization
|
||||
|
||||
The new [`@nx/gradle` plugin](/nx-api/gradle) now includes experimental support for [Test Atomization](/ci/features/split-e2e-tasks).
|
||||
The new [`@nx/gradle` plugin](/technologies/java/api) now includes experimental support for [Test Atomization](/ci/features/split-e2e-tasks).
|
||||
|
||||
|
||||
|
||||
@ -225,7 +225,7 @@ With Test Atomization, as you add tests to your Gradle projects, Nx will automat
|
||||
|
||||
## Experimental: Nx Release Adds File Based Versioning Support
|
||||
|
||||
Currently with [Nx release](/nx-api/nx/documents/release), you already have two different ways of figuring out the how to modify the current version of a package to get its updated version:
|
||||
Currently with [Nx release](/reference/core-api/nx/documents/release), you already have two different ways of figuring out the how to modify the current version of a package to get its updated version:
|
||||
|
||||
- Imperatively via the CLI/prompt by telling it your desired relative (semver keyword) or absolute (e.g. `1.2.3`) version.
|
||||
- Declaratively by letting Nx inspect your git history and determine the semver bump to apply based on the conventional commits specification.
|
||||
@ -261,7 +261,7 @@ Fetching @angular/core@18.1.2
|
||||
|
||||
Our `@nx/react` package will now create new React applications using version 18.3, and we now support the new experimental `reactCompiler`. Users can install the [`babel-plugin-react-compiler` package](https://www.npmjs.com/package/babel-plugin-react-compiler) and you can follow [this guide for how to enable it with Nx](/technologies/react/recipes/react-compiler#react-compiler-with-nx).
|
||||
|
||||
Note that due to the extent of breaking changes coming with React 19, we will not be providing a automated migration to React 19 via [`nx migrate`](/nx-api/nx/documents/migrate).
|
||||
Note that due to the extent of breaking changes coming with React 19, we will not be providing a automated migration to React 19 via [`nx migrate`](/reference/core-api/nx/documents/migrate).
|
||||
|
||||
## Automatically Update Nx
|
||||
|
||||
|
||||
@ -81,7 +81,7 @@ Next, we'll want to navigate into our new workspace:
|
||||
cd myorg
|
||||
```
|
||||
|
||||
And finally, we'll add the [`@nx/react`](/nx-api/react) plugin to our workspace.
|
||||
And finally, we'll add the [`@nx/react`](/technologies/react/api) plugin to our workspace.
|
||||
|
||||
```shell
|
||||
npx nx add @nx/react
|
||||
|
||||
@ -28,11 +28,11 @@ In this blog post:
|
||||
|
||||
## Nx Import
|
||||
|
||||
In Nx 19.8, [`nx import`](/nx-api/nx/documents/import) has now moved from beta support to now generally available!
|
||||
In Nx 19.8, [`nx import`](/reference/core-api/nx/documents/import) has now moved from beta support to now generally available!
|
||||
|
||||
Nx Import is a new [top-level command of the Nx CLI](/reference/nx-commands) which allows you to import projects along with its git history from some other repository into your current Nx workspace.
|
||||
|
||||
Keep an eye out for more on Nx Import on our [YouTube Channel](https://www.youtube.com/@nxdevtools) coming soon, and in the meantime be sure to check [the documentation](/nx-api/nx/documents/import) as this is now fully documented!
|
||||
Keep an eye out for more on Nx Import on our [YouTube Channel](https://www.youtube.com/@nxdevtools) coming soon, and in the meantime be sure to check [the documentation](/reference/core-api/nx/documents/import) as this is now fully documented!
|
||||
|
||||
## Improved Task Scheduling!
|
||||
|
||||
@ -73,7 +73,7 @@ title="ESLint Config Automation With Nx"
|
||||
|
||||
## Nx Release Enhancements
|
||||
|
||||
[`nx release`](/nx-api/nx/documents/release) is a framework/language/platform agnostic solution to versioning, publishing, and changelogs for your monorepo. We've been continuing to invest in Nx Release in 19.8, adding support specifically for [`pnpm publish`](https://pnpm.io/cli/publish) and [Github Enterprise Server](https://github.com/nrwl/nx/pull/26482)!
|
||||
[`nx release`](/reference/core-api/nx/documents/release) is a framework/language/platform agnostic solution to versioning, publishing, and changelogs for your monorepo. We've been continuing to invest in Nx Release in 19.8, adding support specifically for [`pnpm publish`](https://pnpm.io/cli/publish) and [Github Enterprise Server](https://github.com/nrwl/nx/pull/26482)!
|
||||
|
||||
We also have a new feature from Nx Champion, Jonathan Gelin - which allows you to use `groupPreVersionCommand` in addition to the `preVersionCommand` when using the release groups feature to support [building before versioning](/recipes/nx-release/build-before-versioning).
|
||||
|
||||
|
||||
@ -130,8 +130,8 @@ 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](/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.
|
||||
- [Enforce Module Boundaries](/reference/core-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](/reference/core-api/conformance#ensure-owners): Requires every project to have an owner defined for the `@nx/owners` plugin.
|
||||
|
||||
To get started, install the following package:
|
||||
|
||||
|
||||
@ -141,7 +141,7 @@ There's a lot more in Nx 20, so be sure to check the full changelog for all the
|
||||
[gradle-atomizer]: /blog/nx-19-5-adds-stackblitz-new-features-and-more#experimental-gradle-test-atomization
|
||||
[nx-gradle]: /blog/nx-19-release#new-plugin-nxgradle
|
||||
[file-based-versioning]: /recipes/nx-release/file-based-versioning-version-plans
|
||||
[nx-rspack]: /nx-api/rspack
|
||||
[nx-rspack]: /technologies/build-tools/rspack/introduction
|
||||
[crystalize-command]: /blog/nx-19-8-update#crystalize-your-entire-workspace-in-one-command
|
||||
[nx-import]: /recipes/adopting-nx/import-project
|
||||
[migration-step]: /features/automate-updating-dependencies
|
||||
|
||||
@ -23,7 +23,7 @@ However, while we've always had a great story for starting up a fresh monorepo f
|
||||
|
||||
Prior to this work, it was always possible to do manually - but it takes some finessing both in terms of copying/pasting files over, and (as we'll see later) maintaining combining git history from the old project into its new home.
|
||||
|
||||
We always wanted to make this better - and now, we've now added a new top-level command to Nx specifically to address this: [`nx import`](http://localhost:4200/nx-api/nx/documents/import).
|
||||
We always wanted to make this better - and now, we've now added a new top-level command to Nx specifically to address this: [`nx import`](http://localhost:4200/reference/core-api/nx/documents/import).
|
||||
|
||||
## How It Works
|
||||
|
||||
|
||||
@ -84,7 +84,7 @@ Sometimes the second part of the problem simply builds on top of the first. On t
|
||||
|
||||
### New Feature for 2.0.0: File Watching!
|
||||
|
||||
We've also added file watching (using [`nx watch`](/nx-api/nx/documents/watch) behind the scenes!)
|
||||
We've also added file watching (using [`nx watch`](/reference/core-api/nx/documents/watch) behind the scenes!)
|
||||
|
||||
Simply add `watch-` to the start of any of the commands and aliases listed above to start any of them in watch mode, so they automatically re-run as soon as any changes to the file system are detected! Example:
|
||||
|
||||
|
||||
@ -47,7 +47,7 @@ Once installed, run the following generator that ships with the `@nx/plugin` pac
|
||||
nx g plugin packages/nx-plugin --importPath=@org/nx-plugin
|
||||
```
|
||||
|
||||
Also, make sure to check out our [extensive instructions in our docs for building plugins](/extending-nx/intro/getting-started), or you can jump right to the API for [@nx/plugin](/nx-api/plugin).
|
||||
Also, make sure to check out our [extensive instructions in our docs for building plugins](/extending-nx/intro/getting-started), or you can jump right to the API for [@nx/plugin](/reference/core-api/plugin).
|
||||
|
||||
## Setting up custom generators
|
||||
|
||||
@ -137,7 +137,7 @@ To support consistency across your org, you can publish this plugin so that all
|
||||
nx release --first-release
|
||||
```
|
||||
|
||||
If you want to test your package by publishing locally, your project will also be set up with a [Verdaccio configuration](/nx-api/js/executors/verdaccio) that allows you to run a local registry for testing your new plugin locally:
|
||||
If you want to test your package by publishing locally, your project will also be set up with a [Verdaccio configuration](/technologies/typescript/api/executors/verdaccio) that allows you to run a local registry for testing your new plugin locally:
|
||||
|
||||
```bash
|
||||
nx local-registry
|
||||
@ -171,7 +171,7 @@ Your plugin can provide _anything an existing Nx plugin provides._ This includes
|
||||
|
||||
- [Generators](/extending-nx/recipes/local-generators)
|
||||
- [Task inference](/extending-nx/tutorials/tooling-plugin)
|
||||
- [Custom eslint rules](/nx-api/eslint/generators/workspace-rule#nxeslintworkspacerule)
|
||||
- [Custom eslint rules](/technologies/eslint/api/generators/workspace-rule#nxeslintworkspacerule)
|
||||
- [Migrations](/extending-nx/recipes/migration-generators)
|
||||
- Shared tool configs
|
||||
- CI pipeline starters
|
||||
|
||||
@ -123,11 +123,11 @@ And we will continue to add this as the default to all our official presets soon
|
||||
|
||||
## Rspack updates
|
||||
|
||||
Our [`@nx/rspack`](/nx-api/rspack) plugin has moved from labs into our main repo now, and we now have [a dedicated plugin](/nx-api/rsbuild) for [Rsbuild](https://rsbuild.dev/) (a vite-like build tool with streamlined config built on top of Rspack) as well.
|
||||
Our [`@nx/rspack`](/technologies/build-tools/rspack/api) plugin has moved from labs into our main repo now, and we now have [a dedicated plugin](/technologies/build-tools/rsbuild/api) for [Rsbuild](https://rsbuild.dev/) (a vite-like build tool with streamlined config built on top of Rspack) as well.
|
||||
|
||||
With the latest improvements, our Rspack plugin is now at feature parity with our [`@nx/webpack`](/nx-api/webpack) plugin, which should make it easier for teams to migrate from Webpack to Rspack now and take advantage of the significant performance gains.
|
||||
With the latest improvements, our Rspack plugin is now at feature parity with our [`@nx/webpack`](/technologies/build-tools/webpack/api) plugin, which should make it easier for teams to migrate from Webpack to Rspack now and take advantage of the significant performance gains.
|
||||
|
||||
Our new [Rsbuild plugin](/nx-api/rsbuild) will bring support for React and Vue applications, and we have measured a massive performance increase here over webpack. Running the command:
|
||||
Our new [Rsbuild plugin](/technologies/build-tools/rsbuild/api) will bring support for React and Vue applications, and we have measured a massive performance increase here over webpack. Running the command:
|
||||
|
||||
```shell
|
||||
nx g @nx/rsbuild:configuration
|
||||
@ -195,9 +195,9 @@ We've also introduced spinners into the terminal ui for instances where a task i
|
||||
|
||||
> Update: Self-hosted cache was previously part of Powerpack. But no more, it is no free for everyone to use.
|
||||
|
||||
We just improved support for our [self-hosted caching packages](/recipes/running-tasks/self-hosted-caching) by adding adapters for [Azure](/nx-api/azure-cache) and [Google Cloud Storage](/nx-api/gcs-cache) as supported storage providers (in addition to [S3](/nx-api/s3-cache) or [simply using a shared file system](/nx-api/shared-fs-cache)).
|
||||
We just improved support for our [self-hosted caching packages](/recipes/running-tasks/self-hosted-caching) by adding adapters for [Azure](/reference/core-api/azure-cache) and [Google Cloud Storage](/reference/core-api/gcs-cache) as supported storage providers (in addition to [S3](/reference/core-api/s3-cache) or [simply using a shared file system](/reference/core-api/shared-fs-cache)).
|
||||
|
||||
We've also [added support for S3 compatible providers](/nx-api/s3-cache#s3-compatible-providers) such as:
|
||||
We've also [added support for S3 compatible providers](/reference/core-api/s3-cache#s3-compatible-providers) such as:
|
||||
|
||||
- [MinIO](https://min.io/product/s3-compatibility)
|
||||
- [LocalStack](https://www.localstack.cloud)
|
||||
|
||||
@ -48,7 +48,7 @@ Hetzner Cloud needed a solution that would streamline their development process,
|
||||
After evaluating Nx and Turborepo, Hetzner Cloud selected Nx for its advanced monorepo management capabilities. They started a [Nx Enterprise](/enterprise) contract and closely collaborated with the Nx Developer Productivity Engineers to assess Hetzner's current software landscape and evaluate the best strategy. Their goal was not necessarily to create a monorepo in the first place, but to modularize their monolithic application. Nx provided the right tools to:
|
||||
|
||||
- **Break down the monolith** into modular packages without affecting deployment.
|
||||
- **Define clear domain boundaries** using [module boundary rules](/features/enforce-module-boundaries) and [conformance rules](/nx-api/conformance).
|
||||
- **Define clear domain boundaries** using [module boundary rules](/features/enforce-module-boundaries) and [conformance rules](/reference/core-api/conformance).
|
||||
- **Improve ownership management** by having a more modular structure with clear boundaries allowing for easier allocaton of owernship. Something that could further be improved in the future by using [CodeOwners](/nx-enterprise/powerpack/owners).
|
||||
|
||||
Beyond modularization, Nx helped consolidate fragmented projects into a single, structured workspace. This reduced the overhead of maintaining multiple repositories and simplified dependency management. Using the [Nx Graph](/features/explore-graph), the team gained visibility into their project relationships, making it easier to coordinate work and optimize collaboration.
|
||||
|
||||
@ -48,13 +48,13 @@ By default, Nx will use the `name` property from the `package.json` for a projec
|
||||
|
||||
We have also made projects inferred by `@nx/js` more efficient by eliminating the duplicate typechecks that were occurring. Previously, when `@nx/js` inferred tasks in a workspace using TypeScript project references, buildable libraries would have both a `build` and `typecheck` target inferred. However, since typechecking occurs as part of `build`, this resulted in typechecking being run twice. Now, buildable projects will only have the `build` target, saving time.
|
||||
|
||||
[See more details on how `@nx/js` infers tasks](/nx-api/js#how-nxjs-infers-tasks)
|
||||
[See more details on how `@nx/js` infers tasks](/technologies/typescript/api#how-nxjs-infers-tasks)
|
||||
|
||||
{% youtube src="https://www.youtube.com/watch?v=O2xBQJMTs9E" /%}
|
||||
|
||||
## Migration docs
|
||||
|
||||
When `nx migrate` is run, Nx determines what migrations need to be run, but it hasn't been easy for users to understand what the migrations do. The first step we're taking to address this is providing migrations docs for each plugin, going back to version 20 of Nx. [See the Angular plugin migration for an example](/nx-api/angular/migrations).
|
||||
When `nx migrate` is run, Nx determines what migrations need to be run, but it hasn't been easy for users to understand what the migrations do. The first step we're taking to address this is providing migrations docs for each plugin, going back to version 20 of Nx. [See the Angular plugin migration for an example](/technologies/angular/api/migrations).
|
||||
|
||||
Additionally, when running migrations, the terminal will provide links for each migration with richer information about what is actually happening. This is just our first step in addressing confusion during migrations, keep an eye out for more development here.
|
||||
|
||||
@ -64,7 +64,7 @@ Additionally, when running migrations, the terminal will provide links for each
|
||||
|
||||
## React 19 support for new workspaces
|
||||
|
||||
New Nx workspaces now default to React 19. Note that due to the extent of breaking changes coming with React 19, we will not be providing an automated migration to React 19 via [**`nx migrate`**](/nx-api/nx/documents/migrate). If you're ready to make this migration on your own, [see our docs about using the new `reactCompiler`](/technologies/react/recipes/react-compiler#react-compiler-with-nx)
|
||||
New Nx workspaces now default to React 19. Note that due to the extent of breaking changes coming with React 19, we will not be providing an automated migration to React 19 via [**`nx migrate`**](/reference/core-api/nx/documents/migrate). If you're ready to make this migration on your own, [see our docs about using the new `reactCompiler`](/technologies/react/recipes/react-compiler#react-compiler-with-nx)
|
||||
|
||||
## Angular 19.2 support
|
||||
|
||||
|
||||
@ -121,7 +121,7 @@ export default createConfig(
|
||||
|
||||
{% callout type="deepdive" title="createConfig Information" %}
|
||||
The `createConfig` function is used to create an Rspack configuration object setup for Angular applications.
|
||||
You can read more about it [here](/nx-api/angular-rspack/documents/create-config).
|
||||
You can read more about it [here](/technologies/angular/angular-rspack/api).
|
||||
{% /callout %}
|
||||
|
||||
### Building and Serving your Application
|
||||
|
||||
@ -103,7 +103,7 @@ Or more generically:
|
||||
|
||||
- `{ciTargetName}--{path/to/test/file}`
|
||||
|
||||
You can find more information on how to configure the Atomizer on the respective [Jest](/nx-api/jest#splitting-e2e-tests), [Cypress](/nx-api/cypress#nxcypress-configuration), [Playwright](/nx-api/playwright#nxplaywright-configuration), [Gradle](/nx-api/gradle/documents/overview#nxgradle-configuration) or follow [this recipe](/extending-nx/recipes/project-graph-plugins) to create your own inferred plugin.
|
||||
You can find more information on how to configure the Atomizer on the respective [Jest](/technologies/test-tools/jest/api#splitting-e2e-tests), [Cypress](/technologies/test-tools/cypress/api#nxcypress-configuration), [Playwright](/technologies/test-tools/playwright/api#nxplaywright-configuration), [Gradle](/technologies/java/introduction#nxgradle-configuration) or follow [this recipe](/extending-nx/recipes/project-graph-plugins) to create your own inferred plugin.
|
||||
|
||||
## Manual E2E Project Splitting
|
||||
|
||||
|
||||
@ -128,13 +128,13 @@ To test how performance improved, we forked the Spring Boot repo and converted i
|
||||
|
||||
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)
|
||||
[Check out the docs for more details.](/technologies/java/api)
|
||||
|
||||
## 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.
|
||||
[Automated migrations](/features/automate-updating-dependencies) have always been a massively valuable part of Nx. Previously, we [added migration docs](/technologies/angular/api/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.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ title="Nx 17.0 Has Landed!!!"
|
||||
## Features
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="Official @nx/vue plugin" type="document" url="/nx-api/vue" /%}
|
||||
{% card title="Official @nx/vue plugin" type="document" url="/technologies/vue/introduction" /%}
|
||||
{% card title="Module Federation Improvements" type="document" url="/technologies/module-federation/concepts/module-federation-and-nx" /%}
|
||||
{% card title="Show Task Inputs in the Task Graph Visualizer" type="external" url="https://github.com/nrwl/nx/pull/19597" /%}
|
||||
{% card title="Move properties from tasksRunnerOptions up to the root of nx.json" type="external" url="https://github.com/nrwl/nx/pull/19243" /%}
|
||||
|
||||
@ -17,7 +17,7 @@ title="Nx 18.0!!!"
|
||||
{% cards cols="2" %}
|
||||
{% card title="Inferred tasks (Project Crystal)" type="document" url="/concepts/inferred-tasks" /%}
|
||||
{% card title="Project Details View" type="document" url="/features/explore-graph#explore-projects-in-your-workspace" /%}
|
||||
{% card title="New @nx/nuxt plugin" type="document" url="/nx-api/nuxt" /%}
|
||||
{% card title="New @nx/nuxt plugin" type="document" url="/technologies/vue/nuxt/introduction" /%}
|
||||
{% card title="Distribute tasks on Nx Agents" type="document" url="/ci/features/distribute-task-execution" /%}
|
||||
{% card title="Automatically split e2e tasks (Atomizer)" type="document" url="/ci/features/split-e2e-tasks" /%}
|
||||
{% card title="Re-run flaky tasks" type="document" url="/ci/features/flaky-tasks" /%}
|
||||
|
||||
@ -4,16 +4,16 @@
|
||||
|
||||
### Personal Access Tokens
|
||||
|
||||
Two new top-level commands: [`nx login`](/nx-api/nx/documents/login) (an alias for [`nx-cloud login`](/ci/reference/nx-cloud-cli#npx-nxcloud-login))and [`nx logout`](/nx-api/nx/documents/login) (an alias for [`nx-cloud logout`](/ci/reference/nx-cloud-cli#npx-nxcloud-logout)) to support Personal Access Tokens for Nx Cloud. [Checkout the Full Blog Post](/blog/personal-access-tokens)
|
||||
Two new top-level commands: [`nx login`](/reference/core-api/nx/documents/login) (an alias for [`nx-cloud login`](/ci/reference/nx-cloud-cli#npx-nxcloud-login))and [`nx logout`](/reference/core-api/nx/documents/login) (an alias for [`nx-cloud logout`](/ci/reference/nx-cloud-cli#npx-nxcloud-logout)) to support Personal Access Tokens for Nx Cloud. [Checkout the Full Blog Post](/blog/personal-access-tokens)
|
||||
|
||||
{% youtube
|
||||
src="https://youtu.be/i51LPtagb2s"
|
||||
title="NEW: Personal Access Tokens for Nx Cloud"
|
||||
/%}
|
||||
|
||||
### [rspack](/nx-api/rspack) as the Default Bundler for Module Federation
|
||||
### [rspack](/technologies/build-tools/rspack/api) as the Default Bundler for Module Federation
|
||||
|
||||
We've moved to [rspack](/nx-api/rspack) as the default bundler when setting up Module Federation with Nx! Checkout [Colum's thread](https://x.com/FerryColum/status/1833097821496455321) and catch our upcoming Nx Live broadcast for more:
|
||||
We've moved to [rspack](/technologies/build-tools/rspack/api) as the default bundler when setting up Module Federation with Nx! Checkout [Colum's thread](https://x.com/FerryColum/status/1833097821496455321) and catch our upcoming Nx Live broadcast for more:
|
||||
|
||||
{% youtube
|
||||
src="https://youtube.com/live/_c4zjYm0pYE"
|
||||
|
||||
@ -10,7 +10,7 @@ width="100%" /%}
|
||||
## Features
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="Nx Import" type="document" url="/nx-api/nx/documents/import" /%}
|
||||
{% card title="Nx Import" type="document" url="/reference/core-api/nx/documents/import" /%}
|
||||
{% card title="Improved Task Scheduling" type="document" url="/blog/nx-19-8-update#improved-task-scheduling" /%}
|
||||
{% card title="Project Crystal Comes to Angular" type="document" url="/blog/nx-19-8-update#project-crystal-comes-to-angular" /%}
|
||||
{% card title="Crystalize Your Entire Workspace In One Command" type="document" url="/blog/nx-19-8-update#crystalize-your-entire-workspace-in-one-command" /%}
|
||||
|
||||
@ -11,8 +11,8 @@ width="100%" /%}
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="Composite Graph" type="document" url="/features/explore-graph" /%}
|
||||
{% card title="New repositories can use TypeScript project references instead of path aliases" type="document" url="/nx-api/js" /%}
|
||||
{% card title="Rspack plugin graduates from labs" type="document" url="/nx-api/rspack" /%}
|
||||
{% card title="New repositories can use TypeScript project references instead of path aliases" type="document" url="/technologies/typescript/introduction" /%}
|
||||
{% card title="Rspack plugin graduates from labs" type="document" url="/technologies/build-tools/rspack/introduction" /%}
|
||||
{% /cards %}
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
@ -3,9 +3,9 @@
|
||||
## Features
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="Angular Vitest Support" type="document" url="/nx-api/angular/generators/application#unittestrunner" /%}
|
||||
{% card title="Remix Vite Application Generator" type="document" url="/nx-api/remix/generators/application" /%}
|
||||
{% card title="Rspack Convert-Webpack Generator" type="document" url="/nx-api/rspack/generators/convert-webpack" /%}
|
||||
{% card title="Angular Vitest Support" type="document" url="/technologies/angular/api/generators/application#unittestrunner" /%}
|
||||
{% card title="Remix Vite Application Generator" type="document" url="/technologies/react/remix/api/generators/application" /%}
|
||||
{% card title="Rspack Convert-Webpack Generator" type="document" url="/technologies/build-tools/rspack/api/generators/convert-webpack" /%}
|
||||
|
||||
{% /cards %}
|
||||
|
||||
|
||||
@ -3,9 +3,9 @@
|
||||
## Features
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="New @nx/module-federation plugin" type="document" url="/nx-api/module-federation" /%}
|
||||
{% card title="Angular 19 Support" type="document" url="/nx-api/angular" /%}
|
||||
{% card title="Enhanced Rspack Configuration and Plugin Updates" type="document" url="/nx-api/rspack" /%}
|
||||
{% card title="New @nx/module-federation plugin" type="document" url="/technologies/module-federation/introduction" /%}
|
||||
{% card title="Angular 19 Support" type="document" url="/technologies/angular/introduction" /%}
|
||||
{% card title="Enhanced Rspack Configuration and Plugin Updates" type="document" url="/technologies/build-tools/rspack/introduction" /%}
|
||||
{% /cards %}
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
@ -11,7 +11,7 @@ width="100%" /%}
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="TypeScript Project References & Workspaces Support" type="document" url="/concepts/typescript-project-linking" /%}
|
||||
{% card title="New @nx/rsbuild Plugin" type="document" url="/nx-api/rsbuild" /%}
|
||||
{% card title="New @nx/rsbuild Plugin" type="document" url="/technologies/angular/angular-rsbuild/api" /%}
|
||||
{% card title="Support for Rollup TypeScript Config" type="external" url="https://github.com/nrwl/nx/pull/28240" /%}
|
||||
{% card title="Expo v52 Support" type="external" url="https://github.com/nrwl/nx/pull/29142" /%}
|
||||
{% /cards %}
|
||||
|
||||
@ -10,10 +10,10 @@ title="Nx Update: 20.5!"
|
||||
## Features
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="Angular 19.2 Support" type="document" url="/nx-api/angular" /%}
|
||||
{% card title="Vite 6 + Vitest 3 Support" type="document" url="/nx-api/vite" /%}
|
||||
{% card title="Migration Documentation" type="document" url="/nx-api/angular/migrations" /%}
|
||||
{% card title="ESM Support for ESLint Config" type="document" url="/recipes/tips-n-tricks/flat-config" /%}
|
||||
{% card title="Angular 19.2 Support" type="document" url="/technologies/angular/introduction" /%}
|
||||
{% card title="Vite 6 + Vitest 3 Support" type="document" url="/technologies/build-tools/vite" /%}
|
||||
{% card title="Migration Documentation" type="document" url="/technologies/angular/api/migrations" /%}
|
||||
{% card title="ESM Support for ESLint Config" type="document" url="/technologies/eslint/recipes/flat-config" /%}
|
||||
{% /cards %}
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
@ -3,9 +3,9 @@
|
||||
## Features:
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="Angular Convert to Rspack Generator" type="external" url="/nx-api/angular/generators/convert-to-rspack" /%}
|
||||
{% card title="React Router Plugin" type="external" url="/recipes/react/react-router" /%}
|
||||
{% card title="Local Cache Size Limits" type="external" url="/nx-api/devkit/documents/NxJsonConfiguration#maxcachesize" /%}
|
||||
{% card title="Angular Convert to Rspack Generator" type="external" url="/technologies/angular/api/generators/convert-to-rspack" /%}
|
||||
{% card title="React Router Plugin" type="external" url="/technologies/react/recipes/react-router" /%}
|
||||
{% card title="Local Cache Size Limits" type="external" url="/reference/core-api/devkit/documents/NxJsonConfiguration#maxcachesize" /%}
|
||||
{% card title="TypeScript Solution Setup by Default" type="external" url="/concepts/typescript-project-linking" /%}
|
||||
{% /cards %}
|
||||
|
||||
|
||||
@ -4,8 +4,8 @@
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="Nx Init for CRA Projects" type="document" url="/recipes/adopting-nx/adding-to-existing-project" /%}
|
||||
{% card title="Support for Incremental Builds with Angular App and Lib" type="document" url="/recipes/angular/setup-incremental-builds-angular" /%}
|
||||
{% card title="React Router Plugin with Data APIs" type="document" url="/recipes/react/react-router" /%}
|
||||
{% card title="Support for Incremental Builds with Angular App and Lib" type="document" url="/technologies/angular/recipes/setup-incremental-builds-angular" /%}
|
||||
{% card title="React Router Plugin with Data APIs" type="document" url="/technologies/react/recipes/react-router" /%}
|
||||
{% card title="Enhanced Nx Release with Custom Registry Support" type="document" url="/recipes/nx-release/configure-custom-registries" /%}
|
||||
{% /cards %}
|
||||
|
||||
|
||||
@ -3,10 +3,10 @@
|
||||
## Features
|
||||
|
||||
{% cards cols="2" %}
|
||||
{% card title="Angular Rspack Support" type="document" url="/recipes/angular/rspack/getting-started" /%}
|
||||
{% card title="Angular Rspack Support" type="document" url="/technologies/angular/angular-rspack/introduction" /%}
|
||||
{% card title="HTTP-Based Caches Support" type="document" url="/recipes/running-tasks/self-hosted-caching" /%}
|
||||
{% card title="Revamped Nx Release Version Implementation" type="document" url="/features/manage-releases" /%}
|
||||
{% card title="Cypress v14 Support" type="document" url="/nx-api/cypress" /%}
|
||||
{% card title="Cypress v14 Support" type="document" url="/technologies/test-tools/cypress/introduction" /%}
|
||||
{% /cards %}
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
@ -12,7 +12,7 @@ title="Nx 21 Release: Continuous tasks and Terminal UI lead the way"
|
||||
{% cards cols="2" %}
|
||||
{% card title="Continuous Tasks" type="document" url="/recipes/running-tasks/defining-task-pipeline#continuous-task-dependencies" /%}
|
||||
{% card title="Terminal UI (TUI)" type="document" url="/recipes/running-tasks/terminal-ui" /%}
|
||||
{% card title="Gradle Plugin Enhancements" type="document" url="/nx-api/gradle" /%}
|
||||
{% card title="Gradle Plugin Enhancements" type="document" url="/technologies/java/introduction" /%}
|
||||
{% card title="Migrate UI" type="document" url="/recipes/nx-console/console-migrate-ui#nx-console-migrate-ui" /%}
|
||||
{% /cards %}
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
{% cards cols="2" %}
|
||||
{% card title="Focus Single Tasks in Terminal UI" type="document" url="/recipes/running-tasks/terminal-ui" /%}
|
||||
{% card title="Automatic CPU Core-Based Parallel Execution" type="document" url="/recipes/running-tasks/run-tasks-in-parallel" /%}
|
||||
{% card title="Angular Convert to Rspack Enhancements" type="document" url="/recipes/angular/rspack/migrate-from-webpack" /%}
|
||||
{% card title="Angular Convert to Rspack Enhancements" type="document" url="/technologies/angular/angular-rspack/recipes/migrate-from-webpack" /%}
|
||||
{% /cards %}
|
||||
|
||||
## Bug Fixes:
|
||||
|
||||
@ -10,7 +10,7 @@ The conformance plugin allows you to encode your own organization's standards so
|
||||
The plugin also provides the following pre-written rules:
|
||||
|
||||
- [**Enforce Project Boundaries**](#enforce-project-boundaries): Similar to the Nx [ESLint Enforce Module Boundaries rule](/features/enforce-module-boundaries), but enforces the boundaries on every project dependency, not just those created from TypeScript imports or `package.json` dependencies.
|
||||
- [**Ensure Owners**](#ensure-owners): Require every project to have an owner defined for the [`@nx/owners` plugin](/nx-api/owners)
|
||||
- [**Ensure Owners**](#ensure-owners): Require every project to have an owner defined for the [`@nx/owners` plugin](/reference/core-api/owners)
|
||||
|
||||
{% callout title="This plugin requires an active Nx Powerpack license" %}
|
||||
In order to use `@nx/conformance`, you need to have an active Powerpack license. If you don't have a license or it has expired, the `nx conformance` command will fail.
|
||||
@ -147,7 +147,7 @@ a given `source` project the resulting constraints would be **all** that match i
|
||||
|
||||
### Ensure Owners
|
||||
|
||||
This rule requires every project to have an owner defined for the [`@nx/owners` plugin](/nx-api/owners)
|
||||
This rule requires every project to have an owner defined for the [`@nx/owners` plugin](/reference/core-api/owners)
|
||||
|
||||
Set the `rule` property to: `@nx/conformance/ensure-owners`
|
||||
|
||||
@ -167,6 +167,6 @@ Set the `rule` property to: `@nx/conformance/ensure-owners`
|
||||
|
||||
For more information about the conformance plugin, consult the following articles:
|
||||
|
||||
- [Create a Conformance Rule](/nx-api/conformance/documents/create-conformance-rule)
|
||||
- [Create a Conformance Rule](/reference/core-api/conformance/documents/create-conformance-rule)
|
||||
- [Publish Conformance Rules to Nx Cloud](/ci/recipes/enterprise/conformance/publish-conformance-rules-to-nx-cloud)
|
||||
- [Configure Conformance Rules in Nx Cloud](/ci/recipes/enterprise/conformance/configure-conformance-rules-in-nx-cloud)
|
||||
|
||||
@ -5,7 +5,7 @@ description: The Nx Powerpack Owners plugin provides the ability to define code
|
||||
|
||||
The `@nx/owners` plugin extends the CODEOWNERS functionality to allow you to define code ownership based on projects in addition to the standard file-based definitions. It leverages the [`nx sync`](/concepts/sync-generators) command to compile `owners` configuration settings from `nx.json` and project configuration files into valid CODEOWNERS files for [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners), [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/set-up-and-use-code-owners/) or [GitLab](https://docs.gitlab.com/ee/user/project/codeowners/).
|
||||
|
||||
With this plugin, you can specify code ownership using the same project matcher syntax as [`nx run-many`](/nx-api/nx/documents/run-many#examples). This allows you to easily define rules for multiple projects that may not be located in the same directory. Also, the CODEOWNERS rules will not need to be revisited if a project location is changed or a new project is added.
|
||||
With this plugin, you can specify code ownership using the same project matcher syntax as [`nx run-many`](/reference/core-api/nx/documents/run-many#examples). This allows you to easily define rules for multiple projects that may not be located in the same directory. Also, the CODEOWNERS rules will not need to be revisited if a project location is changed or a new project is added.
|
||||
|
||||
{% callout title="This plugin requires an active Nx Powerpack license" %}
|
||||
In order to use `@nx/owners`, you need to have an active Powerpack license. If you don't have a license or it has expired, the syncing process will stop working and you'll need to manually maintain your CODEOWNERS file.
|
||||
@ -65,7 +65,7 @@ It is also often helpful to add `nx sync` as a git push hook or git commit hook.
|
||||
"owners": ["@joelovesrust"],
|
||||
// specify either projects or files, not both
|
||||
// Can be any project specifier that could be used in `nx run-many`
|
||||
// See https://nx.dev/nx-api/nx/documents/run-many
|
||||
// See https://nx.dev/reference/core-api/nx/documents/run-many
|
||||
"projects": ["my-rust-app", "rust-*", "tag:rust"],
|
||||
// File globs
|
||||
"files": [".github/workflows/**/*"]
|
||||
@ -93,7 +93,7 @@ It is also often helpful to add `nx sync` as a git push hook or git commit hook.
|
||||
"owners": ["@joelovesrust"],
|
||||
// specify either projects or files, not both
|
||||
// Can be any project specifier that could be used in `nx run-many`
|
||||
// See https://nx.dev/nx-api/nx/documents/run-many
|
||||
// See https://nx.dev/reference/core-api/nx/documents/run-many
|
||||
"projects": ["my-rust-app", "rust-*", "tag:rust"],
|
||||
// File globs
|
||||
"files": [".github/workflows/**/*"]
|
||||
@ -123,7 +123,7 @@ If you are using GitLab, you can specify CODEOWNERS [sections](https://docs.gitl
|
||||
"owners": ["@joelovesrust"],
|
||||
// Specify either `projects` or `files`, not both
|
||||
// Can be any project specifier that could be used in `nx run-many`
|
||||
// See https://nx.dev/nx-api/nx/documents/run-many
|
||||
// See https://nx.dev/reference/core-api/nx/documents/run-many
|
||||
"projects": ["my-rust-app", "rust-*", "tag:rust"],
|
||||
// File globs
|
||||
"files": [".github/workflows/**/*"]
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -5455,19 +5455,7 @@
|
||||
"name": "azure-cache",
|
||||
"packageName": "@nx/azure-cache",
|
||||
"description": "A Nx plugin which provides a Nx cache which can be self hosted on Azure Blob Storage.",
|
||||
"documents": {
|
||||
"/reference/core-api/azure-cache/documents/overview": {
|
||||
"id": "overview",
|
||||
"name": "Overview",
|
||||
"description": "A Nx plugin which provides a Nx cache which can be self hosted on Azure Blob Storage.",
|
||||
"file": "external-generated/packages/azure-cache/documents/overview",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/reference/core-api/azure-cache/documents/overview",
|
||||
"tags": [],
|
||||
"originalFilePath": "shared/packages/azure-cache/azure-cache-plugin"
|
||||
}
|
||||
},
|
||||
"documents": {},
|
||||
"root": "/libs/nx-packages/azure-cache",
|
||||
"source": "/libs/nx-packages/azure-cache/src",
|
||||
"executors": {},
|
||||
@ -5536,19 +5524,7 @@
|
||||
"name": "owners",
|
||||
"packageName": "@nx/owners",
|
||||
"description": "A Nx plugin which provides the ability to configure and maintain codeowners for projects in Nx workspaces.",
|
||||
"documents": {
|
||||
"/reference/core-api/owners/documents/overview": {
|
||||
"id": "overview",
|
||||
"name": "Overview",
|
||||
"description": "A Nx plugin which provides the ability to configure and maintain codeowners for projects in Nx workspaces.",
|
||||
"file": "external-generated/packages/owners/documents/overview",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/reference/core-api/owners/documents/overview",
|
||||
"tags": [],
|
||||
"originalFilePath": "shared/packages/owners/owners-plugin"
|
||||
}
|
||||
},
|
||||
"documents": {},
|
||||
"root": "/libs/nx-packages/owners",
|
||||
"source": "/libs/nx-packages/owners/src",
|
||||
"executors": {},
|
||||
@ -5580,19 +5556,7 @@
|
||||
"name": "gcs-cache",
|
||||
"packageName": "@nx/gcs-cache",
|
||||
"description": "A Nx plugin which provides a Nx cache which can be self hosted on Google Cloud Storage.",
|
||||
"documents": {
|
||||
"/reference/core-api/gcs-cache/documents/overview": {
|
||||
"id": "overview",
|
||||
"name": "Overview",
|
||||
"description": "A Nx plugin which provides a Nx cache which can be self hosted on Google Cloud Storage.",
|
||||
"file": "external-generated/packages/gcs-cache/documents/overview",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/reference/core-api/gcs-cache/documents/overview",
|
||||
"tags": [],
|
||||
"originalFilePath": "shared/packages/gcs-cache/gcs-cache-plugin"
|
||||
}
|
||||
},
|
||||
"documents": {},
|
||||
"root": "/libs/nx-packages/gcs-cache",
|
||||
"source": "/libs/nx-packages/gcs-cache/src",
|
||||
"executors": {},
|
||||
@ -5605,19 +5569,7 @@
|
||||
"name": "s3-cache",
|
||||
"packageName": "@nx/s3-cache",
|
||||
"description": "A Nx plugin which provides a Nx cache which can be self hosted on Amazon S3.",
|
||||
"documents": {
|
||||
"/reference/core-api/s3-cache/documents/overview": {
|
||||
"id": "overview",
|
||||
"name": "Overview",
|
||||
"description": "A Nx plugin which provides a Nx cache which can be self hosted on Amazon S3.",
|
||||
"file": "external-generated/packages/s3-cache/documents/overview",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/reference/core-api/s3-cache/documents/overview",
|
||||
"tags": [],
|
||||
"originalFilePath": "shared/packages/s3-cache/s3-cache-plugin"
|
||||
}
|
||||
},
|
||||
"documents": {},
|
||||
"root": "/libs/nx-packages/s3-cache",
|
||||
"source": "/libs/nx-packages/s3-cache/src",
|
||||
"executors": {},
|
||||
@ -5630,19 +5582,7 @@
|
||||
"name": "shared-fs-cache",
|
||||
"packageName": "@nx/shared-fs-cache",
|
||||
"description": "A Nx plugin to enable you to use a shared file system directory",
|
||||
"documents": {
|
||||
"/reference/core-api/shared-fs-cache/documents/overview": {
|
||||
"id": "overview",
|
||||
"name": "Overview",
|
||||
"description": "A Nx plugin to enable you to use a shared file system directory",
|
||||
"file": "external-generated/packages/shared-fs-cache/documents/overview",
|
||||
"itemList": [],
|
||||
"isExternal": false,
|
||||
"path": "/reference/core-api/shared-fs-cache/documents/overview",
|
||||
"tags": [],
|
||||
"originalFilePath": "shared/packages/shared-fs-cache/shared-fs-cache-plugin"
|
||||
}
|
||||
},
|
||||
"documents": {},
|
||||
"root": "/libs/nx-packages/shared-fs-cache",
|
||||
"source": "/libs/nx-packages/shared-fs-cache/src",
|
||||
"executors": {},
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -149,27 +149,6 @@
|
||||
"name": "Run Only Tasks Affected by a PR",
|
||||
"path": "/ci/features/affected"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/run",
|
||||
"id": "run",
|
||||
"name": "run",
|
||||
"path": "/nx-api/nx/documents/run"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/run-many",
|
||||
"id": "run-many",
|
||||
"name": "run-many",
|
||||
"path": "/nx-api/nx/documents/run-many"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/affected",
|
||||
"id": "affected",
|
||||
"name": "affected",
|
||||
"path": "/nx-api/nx/documents/affected"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/run",
|
||||
@ -277,20 +256,6 @@
|
||||
"name": "Project Configuration reference: inputs and namedInputs",
|
||||
"path": "/reference/project-configuration#inputs-and-namedinputs"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/connect-to-nx-cloud",
|
||||
"id": "connect-to-nx-cloud",
|
||||
"name": "connect-to-nx-cloud",
|
||||
"path": "/nx-api/nx/documents/connect-to-nx-cloud"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/reset",
|
||||
"id": "reset",
|
||||
"name": "reset",
|
||||
"path": "/nx-api/nx/documents/reset"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/connect-to-nx-cloud",
|
||||
@ -344,20 +309,6 @@
|
||||
"name": "Infer Tasks or Projects",
|
||||
"path": "/extending-nx/recipes/project-graph-plugins"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/dep-graph",
|
||||
"id": "dep-graph",
|
||||
"name": "graph",
|
||||
"path": "/nx-api/nx/documents/dep-graph"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/show",
|
||||
"id": "show",
|
||||
"name": "show",
|
||||
"path": "/nx-api/nx/documents/show"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/dep-graph",
|
||||
@ -437,13 +388,6 @@
|
||||
"name": "Create a Sync Generator",
|
||||
"path": "/extending-nx/recipes/create-sync-generator"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/generate",
|
||||
"id": "generate",
|
||||
"name": "generate",
|
||||
"path": "/nx-api/nx/documents/generate"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/generate",
|
||||
@ -541,20 +485,6 @@
|
||||
"name": "Create a Sync Generator",
|
||||
"path": "/extending-nx/recipes/create-sync-generator"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/sync",
|
||||
"id": "sync",
|
||||
"name": "sync",
|
||||
"path": "/nx-api/nx/documents/sync"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/sync-check",
|
||||
"id": "sync-check",
|
||||
"name": "sync:check",
|
||||
"path": "/nx-api/nx/documents/sync-check"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/sync",
|
||||
@ -599,13 +529,6 @@
|
||||
"name": "Altering Migration Process",
|
||||
"path": "/recipes/tips-n-tricks/advanced-update"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/migrate",
|
||||
"id": "migrate",
|
||||
"name": "migrate",
|
||||
"path": "/nx-api/nx/documents/migrate"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/migrate",
|
||||
@ -678,20 +601,6 @@
|
||||
"name": ".nxignore",
|
||||
"path": "/reference/nxignore"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/format-check",
|
||||
"id": "format-check",
|
||||
"name": "format:check",
|
||||
"path": "/nx-api/nx/documents/format-check"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/format-write",
|
||||
"id": "format-write",
|
||||
"name": "format:write",
|
||||
"path": "/nx-api/nx/documents/format-write"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/format-check",
|
||||
@ -820,13 +729,6 @@
|
||||
"name": "Configuring Version Prefix for Dependency Versions",
|
||||
"path": "/recipes/nx-release/configuration-version-prefix"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/release",
|
||||
"id": "release",
|
||||
"name": "release",
|
||||
"path": "/nx-api/nx/documents/release"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/release",
|
||||
@ -857,13 +759,6 @@
|
||||
"name": "Activate Powerpack",
|
||||
"path": "/nx-enterprise/activate-powerpack"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/create-nx-workspace",
|
||||
"id": "create-nx-workspace",
|
||||
"name": "create-nx-workspace",
|
||||
"path": "/nx-api/nx/documents/create-nx-workspace"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/create-nx-workspace",
|
||||
@ -889,13 +784,6 @@
|
||||
"name": "Run Root-Level NPM Scripts with Nx",
|
||||
"path": "/recipes/running-tasks/root-level-scripts"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/exec",
|
||||
"id": "exec",
|
||||
"name": "exec",
|
||||
"path": "/nx-api/nx/documents/exec"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/exec",
|
||||
@ -912,13 +800,6 @@
|
||||
"name": "Workspace Watching",
|
||||
"path": "/recipes/running-tasks/workspace-watching"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/watch",
|
||||
"id": "watch",
|
||||
"name": "watch",
|
||||
"path": "/nx-api/nx/documents/watch"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/watch",
|
||||
@ -958,13 +839,6 @@
|
||||
"name": "Migrating from Angular CLI",
|
||||
"path": "/technologies/angular/migration/angular"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/init",
|
||||
"id": "init",
|
||||
"name": "init",
|
||||
"path": "/nx-api/nx/documents/init"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/init",
|
||||
@ -981,13 +855,6 @@
|
||||
"name": "Import an Existing Project into an Nx Workspace",
|
||||
"path": "/recipes/adopting-nx/import-project"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/import",
|
||||
"id": "import",
|
||||
"name": "import",
|
||||
"path": "/nx-api/nx/documents/import"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/import",
|
||||
@ -1011,13 +878,6 @@
|
||||
"name": "What Are Nx Plugins",
|
||||
"path": "/concepts/nx-plugins"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/add",
|
||||
"id": "add",
|
||||
"name": "add",
|
||||
"path": "/nx-api/nx/documents/add"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/add",
|
||||
@ -1139,13 +999,6 @@
|
||||
"id": "publish-plugin",
|
||||
"name": "Publish a Plugin",
|
||||
"path": "/extending-nx/recipes/publish-plugin"
|
||||
},
|
||||
{
|
||||
"description": "The Nx Plugin for Angular contains executors, generators, and utilities for managing Angular applications and libraries within an Nx workspace. It provides: \n\n- Integration with libraries such as Storybook, Jest, ESLint, Tailwind CSS, Playwright and Cypress. \n\n- Generators to help scaffold code quickly (like: Micro Frontends, Libraries, both internal to your codebase and publishable to npm) \n\n- Single Component Application Modules (SCAMs) \n\n- NgRx helpers. \n\n- Utilities for automatic workspace refactoring.",
|
||||
"file": "generated/packages/angular/documents/nx-devkit-angular-devkit",
|
||||
"id": "nx-devkit-angular-devkit",
|
||||
"name": "Nx Devkit and Angular Devkit",
|
||||
"path": "/nx-api/angular/documents/nx-devkit-angular-devkit"
|
||||
}
|
||||
],
|
||||
"daemon": [
|
||||
@ -1156,13 +1009,6 @@
|
||||
"name": "Nx Daemon",
|
||||
"path": "/concepts/nx-daemon"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/daemon",
|
||||
"id": "daemon",
|
||||
"name": "daemon",
|
||||
"path": "/nx-api/nx/documents/daemon"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/daemon",
|
||||
@ -1660,13 +1506,6 @@
|
||||
"name": "Set Up CI",
|
||||
"path": "/ci/recipes/set-up"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/connect-to-nx-cloud",
|
||||
"id": "connect-to-nx-cloud",
|
||||
"name": "connect-to-nx-cloud",
|
||||
"path": "/nx-api/nx/documents/connect-to-nx-cloud"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/connect-to-nx-cloud",
|
||||
@ -1701,20 +1540,6 @@
|
||||
"name": "Personal Access Tokens",
|
||||
"path": "/ci/recipes/security/personal-access-tokens"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/login",
|
||||
"id": "login",
|
||||
"name": "login",
|
||||
"path": "/nx-api/nx/documents/login"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/logout",
|
||||
"id": "logout",
|
||||
"name": "logout",
|
||||
"path": "/nx-api/nx/documents/logout"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/login",
|
||||
@ -1758,13 +1583,6 @@
|
||||
}
|
||||
],
|
||||
"affected": [
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/affected",
|
||||
"id": "affected",
|
||||
"name": "affected",
|
||||
"path": "/nx-api/nx/documents/affected"
|
||||
},
|
||||
{
|
||||
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
|
||||
"file": "generated/packages/nx/documents/affected",
|
||||
|
||||
@ -150,7 +150,7 @@ npx nx g @schematics/angular:component my-component
|
||||
```
|
||||
|
||||
{% callout type="check" title="Important" %}
|
||||
Support to run Angular Devkit builders and schematics is enabled by installing the [`@nx/angular` plugin](/nx-api/angular/documents/overview). This plugin is installed by default when creating a new Angular workspace with Nx or [migrate an existing Angular CLI workspace to Nx](#migrate-from-the-angular-cli).
|
||||
Support to run Angular Devkit builders and schematics is enabled by installing the [`@nx/angular` plugin](/technologies/angular/introduction). This plugin is installed by default when creating a new Angular workspace with Nx or [migrate an existing Angular CLI workspace to Nx](#migrate-from-the-angular-cli).
|
||||
{% /callout %}
|
||||
|
||||
### Running Commands
|
||||
@ -200,7 +200,7 @@ To reiterate: `nx migrate` runs the migrations written by the Angular team the s
|
||||
|
||||
### 'nx add'
|
||||
|
||||
The [`nx add` command](/nx-api/nx/documents/add) is similar to the `ng add` command. It installs a given package specifier (e.g. `@nx/react`, `@nx/react@18.1.0`, `@nx/react@latest`) and it runs an `init` or `ng-add` generator if the installed package contains it.
|
||||
The [`nx add` command](/reference/core-api/nx/documents/add) is similar to the `ng add` command. It installs a given package specifier (e.g. `@nx/react`, `@nx/react@18.1.0`, `@nx/react@latest`) and it runs an `init` or `ng-add` generator if the installed package contains it.
|
||||
|
||||
```shell
|
||||
nx add [package]
|
||||
@ -260,7 +260,7 @@ Features like
|
||||
- offering [remote caching abilities](/ci/features/remote-cache) on CI
|
||||
- offering [task distribution across machines (Nx Agents)](/ci/features/distribute-task-execution)
|
||||
|
||||
And, Nx already uses fast, modern tooling like [ESBuild](/nx-api/esbuild), [Vite](/nx-api/vite), Vitest and [Rspack](/nx-api/rspack) for non-Angular stacks. So once Angular is ready to use these tools, Nx will also be ready.
|
||||
And, Nx already uses fast, modern tooling like [ESBuild](/technologies/build-tools/esbuild/api), [Vite](/technologies/build-tools/vite/api), Vitest and [Rspack](/technologies/build-tools/rspack/api) for non-Angular stacks. So once Angular is ready to use these tools, Nx will also be ready.
|
||||
|
||||
### Editor Integration
|
||||
|
||||
@ -393,7 +393,7 @@ Learn more about the [graph features here](/features/explore-graph).
|
||||
|
||||
### Extensible and Customizable: Make it fit your own needs
|
||||
|
||||
Nx is [built to be extensible](/getting-started/why-nx#how-does-nx-work). Just like the [packages published by the Nx core team](/nx-api) you can create your own Nx plugins by [extending Nx](/extending-nx/intro/getting-started). This can be as simple as using [run-commands](/nx-api/nx/executors/run-commands) to integrate custom commands into the project configuration or as complex as [creating your own local executor](/extending-nx/recipes/local-executors).
|
||||
Nx is [built to be extensible](/getting-started/why-nx#how-does-nx-work). Just like the [packages published by the Nx core team](/plugin-registry) you can create your own Nx plugins by [extending Nx](/extending-nx/intro/getting-started). This can be as simple as using [run-commands](/reference/core-api/nx/executors/run-commands) to integrate custom commands into the project configuration or as complex as [creating your own local executor](/extending-nx/recipes/local-executors).
|
||||
|
||||
And if you ever need to expand beyond Angular or diversify your stack, you can still keep using Nx, which is [battle-tested with many different technologies](/getting-started/intro#pick-your-stack).
|
||||
|
||||
|
||||
@ -6,13 +6,13 @@ description: Compare Nx Devkit and Angular Devkit for creating generators and ex
|
||||
# Nx Devkit and Angular Devkit
|
||||
|
||||
{% callout type="note" title="Nx & Angular" %}
|
||||
This document covers the difference between Nx Devkit and Angular Devkit. See the [Nx Devkit](/nx-api/devkit/documents/nx_devkit) guide for more in-depth details about Nx Devkit.
|
||||
This document covers the difference between Nx Devkit and Angular Devkit. See the [Nx Devkit](/reference/core-api/devkit/documents/nx_devkit) guide for more in-depth details about Nx Devkit.
|
||||
{% /callout %}
|
||||
|
||||
Nx comes with a devkit to write generators and executors, but you can also use Angular devkit (schematics and builders). In other words, you can use an Angular schematic to implement a generator, and you can use an Angular builder to implement an executor.
|
||||
|
||||
{% callout type="check" title="Important" %}
|
||||
Support to run Angular Devkit builders and schematics is enabled by installing the [`@nx/angular` plugin](/nx-api/angular/documents/overview). This plugin is installed by default when creating a new Angular workspace with Nx or [migrate an existing Angular CLI workspace to Nx](technologies/angular/migration/angular).
|
||||
Support to run Angular Devkit builders and schematics is enabled by installing the [`@nx/angular` plugin](/technologies/angular/introduction). This plugin is installed by default when creating a new Angular workspace with Nx or [migrate an existing Angular CLI workspace to Nx](technologies/angular/migration/angular).
|
||||
{% /callout %}
|
||||
|
||||
**What are the differences between Nx Devkit and Angular Devkit?**
|
||||
|
||||
@ -10,7 +10,7 @@ Why should you use this plugin?
|
||||
- _Fast_ builds using esbuild.
|
||||
- Type-checking using TypeScript, which esbuild does not handle.
|
||||
- Intelligent `package.json` output.
|
||||
- Additional [assets](/nx-api/esbuild/executors/esbuild#assets) for the output.
|
||||
- Additional [assets](/technologies/build-tools/esbuild/api/executors/esbuild#assets) for the output.
|
||||
|
||||
## Setting Up @nx/esbuild
|
||||
|
||||
@ -133,4 +133,4 @@ Extra API options for esbuild can be passed in the `esbuildOptions` object for y
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [Using JS](/nx-api/js)
|
||||
- [Using JS](/technologies/typescript/api)
|
||||
|
||||
@ -73,8 +73,8 @@ nx lint my-project
|
||||
|
||||
## Utils
|
||||
|
||||
- [convert-to-flat-config](/nx-api/eslint/generators/convert-to-flat-config) - Converts the workspace's [ESLint](https://eslint.org/) configs to the new [Flat Config](https://eslint.org/blog/2022/08/new-config-system-part-2)
|
||||
- [convert-to-flat-config](/technologies/eslint/api/generators/convert-to-flat-config) - Converts the workspace's [ESLint](https://eslint.org/) configs to the new [Flat Config](https://eslint.org/blog/2022/08/new-config-system-part-2)
|
||||
|
||||
## ESLint plugin
|
||||
|
||||
Read about our dedicated ESLint plugin - [eslint-plugin-nx](/nx-api/eslint-plugin/documents/overview).
|
||||
Read about our dedicated ESLint plugin - [eslint-plugin-nx](/technologies/eslint/eslint-plugin/api).
|
||||
|
||||
@ -343,5 +343,5 @@ Below table is a map between expo commands and Nx commands:
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [Using Detox](/nx-api/detox)
|
||||
- [Using Jest](/nx-api/jest)
|
||||
- [Using Detox](/technologies/test-tools/detox/api)
|
||||
- [Using Jest](/technologies/test-tools/jest/api)
|
||||
|
||||
@ -271,7 +271,7 @@ The Nx task options can be configured via the [project config file](/reference/p
|
||||
|
||||
If you're using [inferred tasks](/concepts/inferred-tasks), or running Jest directly with the `nx:run-commands` executor, you can [provide the Jest args](/recipes/running-tasks/pass-args-to-commands) for the command you're running.
|
||||
|
||||
If you're using the `@nx/jest:jest` executor, you can provide [the options the executor accepts](/nx-api/jest/executors/jest#options).
|
||||
If you're using the `@nx/jest:jest` executor, you can provide [the options the executor accepts](/technologies/test-tools/jest/api/executors/jest#options).
|
||||
|
||||
### Code Coverage
|
||||
|
||||
|
||||
@ -203,4 +203,4 @@ Bundling dependencies is typically not recommended for Node applications.
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [Using Jest](/nx-api/jest)
|
||||
- [Using Jest](/technologies/test-tools/jest/api)
|
||||
|
||||
@ -93,5 +93,5 @@ For additional information on how to debug Node applications, see the [Node.js d
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [Using Cypress](/nx-api/cypress)
|
||||
- [Using Jest](/nx-api/jest)
|
||||
- [Using Cypress](/technologies/test-tools/cypress/api)
|
||||
- [Using Jest](/technologies/test-tools/jest/api)
|
||||
|
||||
@ -130,7 +130,7 @@ The Nx CLI provides the [`migrate` command](/features/automate-updating-dependen
|
||||
|
||||
#### Use upgrade-native Generator
|
||||
|
||||
To upgrade native iOS and Android code to latest, you can use the [upgrade-native](/nx-api/react-native/generators/upgrade-native) generator:
|
||||
To upgrade native iOS and Android code to latest, you can use the [upgrade-native](/technologies/react/react-native/api/generators/upgrade-native) generator:
|
||||
|
||||
```shell
|
||||
nx generate @nx/react-native:upgrade-native apps/<your-app-name>
|
||||
@ -194,5 +194,5 @@ The build artifacts will be located under `<your app folder>/android/app/build`.
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [Using Detox](/nx-api/detox)
|
||||
- [Using Jest](/nx-api/jest)
|
||||
- [Using Detox](/technologies/test-tools/detox/api)
|
||||
- [Using Jest](/technologies/test-tools/jest/api)
|
||||
|
||||
@ -136,6 +136,6 @@ The library in `dist` is publishable to npm or a private registry.
|
||||
## More Documentation
|
||||
|
||||
- [React Monorepo Tutorial](/getting-started/tutorials/react-monorepo-tutorial)
|
||||
- [Using Cypress](/nx-api/cypress)
|
||||
- [Using Jest](/nx-api/jest)
|
||||
- [Using Cypress](/technologies/test-tools/cypress/api)
|
||||
- [Using Jest](/technologies/test-tools/jest/api)
|
||||
- [Using Storybook](/technologies/test-tools/storybook/recipes/overview-react)
|
||||
|
||||
@ -62,7 +62,7 @@ The `buildTargetName`, `previewTargetName`, `serveTargetName` and `serveStaticTa
|
||||
|
||||
### Generate a new project using Rspack
|
||||
|
||||
You can generate a [React](/nx-api/react) application that uses Rspack. The [`@nx/react:app`](/nx-api/react/generators/application) generator accepts the `bundler` option, where you can pass `rspack`. This will generate a new application configured to use Rspack, and it will also install all the necessary dependencies, including the `@nx/rspack` plugin.
|
||||
You can generate a [React](/technologies/react/api) application that uses Rspack. The [`@nx/react:app`](/technologies/react/api/generators/application) generator accepts the `bundler` option, where you can pass `rspack`. This will generate a new application configured to use Rspack, and it will also install all the necessary dependencies, including the `@nx/rspack` plugin.
|
||||
|
||||
To generate a React application using Rspack, run the following:
|
||||
|
||||
@ -74,4 +74,4 @@ nx g @nx/react:app my-app --bundler=rspack
|
||||
|
||||
You can use the `@nx/rspack:configuration` generator to change your React to use Rspack. This generator will modify your project's configuration to use Rspack, and it will also install all the necessary dependencies, including the `@nx/rspack` plugin.
|
||||
|
||||
You can read more about this generator on the [`@nx/rspack:configuration`](/nx-api/rspack/generators/configuration) generator page.
|
||||
You can read more about this generator on the [`@nx/rspack:configuration`](/technologies/build-tools/rspack/api/generators/configuration) generator page.
|
||||
|
||||
@ -7,7 +7,7 @@ description: The purpose of this guide is to help you set up Storybook in your N
|
||||
|
||||
## Purpose of this guide
|
||||
|
||||
The purpose of this guide is to help you [set up Storybook in your Nx workspace](/nx-api/storybook) so that you can get the most out of Nx and its powerful capabilities.
|
||||
The purpose of this guide is to help you [set up Storybook in your Nx workspace](/technologies/test-tools/storybook/api) so that you can get the most out of Nx and its powerful capabilities.
|
||||
|
||||
## When to use Storybook
|
||||
|
||||
@ -31,7 +31,7 @@ First, let’s see what Nx offers, when you are in the process of developing a p
|
||||
|
||||
#### Configuration generation
|
||||
|
||||
You can generate the Storybook configuration files and settings using the Nx [`@nx/storybook:configuration` generator](/nx-api/storybook/generators/configuration). You can read more about configuring Storybook with Nx in our [`@nx/storybook` package overview page](/nx-api/storybook#generating-storybook-configuration). With Nx, you configure Storybook for each individual project.
|
||||
You can generate the Storybook configuration files and settings using the Nx [`@nx/storybook:configuration` generator](/technologies/test-tools/storybook/api/generators/configuration). You can read more about configuring Storybook with Nx in our [`@nx/storybook` package overview page](/technologies/test-tools/storybook/api#generating-storybook-configuration). With Nx, you configure Storybook for each individual project.
|
||||
|
||||
#### Stories generation
|
||||
|
||||
@ -45,15 +45,15 @@ If your project is not configured yet, check out one of these guides:
|
||||
|
||||
- [Set up Storybook for Vue Projects](/technologies/test-tools/storybook/recipes/overview-vue)
|
||||
|
||||
If your project is [already configured](/nx-api/storybook), you can use the `stories` generator:
|
||||
If your project is [already configured](/technologies/test-tools/storybook/api), you can use the `stories` generator:
|
||||
|
||||
- [React (and Next.js) stories generator](/nx-api/react/generators/stories)
|
||||
- [React (and Next.js) stories generator](/technologies/react/api/generators/stories)
|
||||
|
||||
- [Angular stories generator](/nx-api/angular/generators/stories)
|
||||
- [Angular stories generator](/technologies/angular/api/generators/stories)
|
||||
|
||||
- [Vue stories generator](/nx-api/vue/generators/stories)
|
||||
- [Vue stories generator](/technologies/vue/api/generators/stories)
|
||||
|
||||
- [React Native stories generator](/nx-api/react-native/generators/stories)
|
||||
- [React Native stories generator](/technologies/react/react-native/api/generators/stories)
|
||||
|
||||
The stories generator will read your inputs (if you’re using Angular), or your props (if you're using React), and will generate stories with the corresponding arguments/controls already prefilled.
|
||||
|
||||
@ -73,11 +73,11 @@ You can set up your interaction tests to run as part of your CI. You can read mo
|
||||
|
||||
#### Serve
|
||||
|
||||
When you are configuring Storybook, Nx [adds a serve and a build target for Storybook](/nx-api/storybook#generating-storybook-configuration) in your `project.json`, as we explained above. You can use these targets to [serve](/nx-api/storybook/executors/storybook) and [build](/nx-api/storybook/executors/build) storybook locally, and also in production. Cypress will also use these targets when firing up the e2e tests. While developing, you can serve your Storybooks locally to see if your components work and look as expected. This can help you and speed up the development and debugging process (no need to fire up a complex dev stack).
|
||||
When you are configuring Storybook, Nx [adds a serve and a build target for Storybook](/technologies/test-tools/storybook/api#generating-storybook-configuration) in your `project.json`, as we explained above. You can use these targets to [serve](/technologies/test-tools/storybook/api/executors/storybook) and [build](/technologies/test-tools/storybook/api/executors/build) storybook locally, and also in production. Cypress will also use these targets when firing up the e2e tests. While developing, you can serve your Storybooks locally to see if your components work and look as expected. This can help you and speed up the development and debugging process (no need to fire up a complex dev stack).
|
||||
|
||||
#### Build and deploy
|
||||
|
||||
The build and deploy step usually comes in handy when you are ready to use Storybook for documentation, and you want to publish it. The [building](/nx-api/storybook/executors/build) step of Storybook is integrated in the Nx ecosystem, as explained above, and you can trigger your Storybook builds as you would trigger any other build inside your workspace.
|
||||
The build and deploy step usually comes in handy when you are ready to use Storybook for documentation, and you want to publish it. The [building](/technologies/test-tools/storybook/api/executors/build) step of Storybook is integrated in the Nx ecosystem, as explained above, and you can trigger your Storybook builds as you would trigger any other build inside your workspace.
|
||||
|
||||
When you publish your organization’s Storybook, as a result, ideally, you would want to have one shareable Storybook page/application living under one URL, that you can share. With Nx, you can build your Storybook and it will be ready for deployment. **However**, at this point, you have one Storybook per project in your workspace, and you could end up with far too many Storybooks that are built and ready for deployment. This is not ideal, and does not accomplish the ultimate goal of “one shareable documentation page”.
|
||||
|
||||
@ -148,4 +148,4 @@ If you have any questions or suggestions, please feel free to reach out to us on
|
||||
|
||||
### Nx & Storybook documentation
|
||||
|
||||
You can find all Storybook-related Nx documentation in the [packages page](/nx-api/storybook).
|
||||
You can find all Storybook-related Nx documentation in the [packages page](/technologies/test-tools/storybook/api).
|
||||
|
||||
@ -105,7 +105,7 @@ nx g @nx/react-native:storybook-configuration my-react-native-project
|
||||
|
||||
These framework-specific generators will also **generate stories** and interaction tests for you.
|
||||
|
||||
If you are NOT using a framework-specific generator (for [Angular](/nx-api/angular/generators/storybook-configuration), [React](/nx-api/react/generators/storybook-configuration), [React Native](/nx-api/react-native/generators/storybook-configuration), [Vue](/nx-api/vue/generators/storybook-configuration)), in the field `uiFramework` you must choose one of the following Storybook frameworks:
|
||||
If you are NOT using a framework-specific generator (for [Angular](/technologies/angular/api/generators/storybook-configuration), [React](/technologies/react/api/generators/storybook-configuration), [React Native](/technologies/react/react-native/api/generators/storybook-configuration), [Vue](/technologies/vue/api/generators/storybook-configuration)), in the field `uiFramework` you must choose one of the following Storybook frameworks:
|
||||
|
||||
- `@storybook/angular`
|
||||
- `@storybook/html-webpack5`
|
||||
@ -132,7 +132,7 @@ Choosing one of these frameworks will have the following effects on your workspa
|
||||
|
||||
3. Nx will create new `targets` in your project's `project.json`, called `storybook`, `test-storybook` and `build-storybook`, containing all the necessary configuration to serve, test and build Storybook.
|
||||
|
||||
Make sure to **use the framework-specific generators** if your project is using Angular, React, Next.js, Vue, Nuxt, or React Native: [`@nx/angular:storybook-configuration`](/nx-api/angular/generators/storybook-configuration), [`@nx/react:storybook-configuration`](/nx-api/react/generators/storybook-configuration), [`@nx/react-native:storybook-configuration`](/nx-api/react-native/generators/storybook-configuration), [`@nx/vue:storybook-configuration`](/nx-api/vue/generators/storybook-configuration) as shown above.
|
||||
Make sure to **use the framework-specific generators** if your project is using Angular, React, Next.js, Vue, Nuxt, or React Native: [`@nx/angular:storybook-configuration`](/technologies/angular/api/generators/storybook-configuration), [`@nx/react:storybook-configuration`](/technologies/react/api/generators/storybook-configuration), [`@nx/react-native:storybook-configuration`](/technologies/react/react-native/api/generators/storybook-configuration), [`@nx/vue:storybook-configuration`](/technologies/vue/api/generators/storybook-configuration) as shown above.
|
||||
|
||||
### Running Storybook
|
||||
|
||||
@ -241,5 +241,5 @@ For more on using Storybook, see the [official Storybook documentation](https://
|
||||
|
||||
Here's more information on common migration scenarios for Storybook with Nx. For Storybook specific migrations that are not automatically handled by Nx please refer to the [official Storybook page](https://storybook.js.org/)
|
||||
|
||||
- [Storybook 7 migration generator](/nx-api/storybook/generators/migrate-7)
|
||||
- [Storybook 7 migration generator](/technologies/test-tools/storybook/api/generators/migrate-7)
|
||||
- [Storybook 7 setup guide](/technologies/test-tools/storybook/recipes/best-practices)
|
||||
|
||||
@ -7,17 +7,17 @@ description: This guide explains how you can set up Storybook version 7 in your
|
||||
|
||||
Storybook 7 is a major release that brings a lot of new features and improvements. You can read more about it in the [Storybook 7.0.0 release article](https://storybook.js.org/blog/storybook-7-0/). Apart from the new features and improvements it introduces, it also brings some breaking changes. You can read more about them in the [Storybook 7 migration docs](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-65x-to-700) and the [Storybook 7.0.0 migration guide](https://storybook.js.org/docs/react/migration-guide).
|
||||
|
||||
Nx provides new generators that allow you to generate Storybook 7 configuration for your projects, by installing the correct dependencies and creating the corresponding version 7 configuration files. Nx also provides a [Storybook 7 migration generator](/nx-api/storybook/generators/migrate-7) that you can use to migrate your existing Storybook configuration to version 7.
|
||||
Nx provides new generators that allow you to generate Storybook 7 configuration for your projects, by installing the correct dependencies and creating the corresponding version 7 configuration files. Nx also provides a [Storybook 7 migration generator](/technologies/test-tools/storybook/api/generators/migrate-7) that you can use to migrate your existing Storybook configuration to version 7.
|
||||
|
||||
So, let's see how you can use Storybook 7 on your Nx workspace.
|
||||
|
||||
## Migrate your existing workspace to Storybook 7
|
||||
|
||||
If you already have Storybook configured in your Nx workspace, you can use the [Storybook 7 migrator generator](/nx-api/storybook/generators/migrate-7) to migrate your existing Storybook configuration to version 7.
|
||||
If you already have Storybook configured in your Nx workspace, you can use the [Storybook 7 migrator generator](/technologies/test-tools/storybook/api/generators/migrate-7) to migrate your existing Storybook configuration to version 7.
|
||||
|
||||
## Set up Storybook 7 in a _new_ Nx Workspace
|
||||
|
||||
Please read the [`@nx/storybook` package overview](/nx-api/storybook) to see how you can configure Storybook in your Nx workspace.
|
||||
Please read the [`@nx/storybook` package overview](/technologies/test-tools/storybook/api) to see how you can configure Storybook in your Nx workspace.
|
||||
|
||||
## Changes from the v6.5 Storybook configuration
|
||||
|
||||
@ -32,7 +32,7 @@ The Storybook configuration generated by Nx for Storybook 7 is very similar to t
|
||||
### Changes in the `storybook` and `build-storybook` targets
|
||||
|
||||
- The `uiFramework` field is not needed any more, thus it is not set. Nx was using the `uiFramework` field to load any framework specific options for the Storybook builder. This is no longer needed, since the `framework` set in `.storybook/main.js|ts` takes care of that.
|
||||
- More options from the Storybook CLI are now exposed in the executors. You can see these in the [`@nx/storybook:storybook`](/nx-api/storybook/executors/storybook) and [`@nx/storybook:build`](/nx-api/storybook/executors/build) executor schemas. You can read more about these options in the [Storybook 7 CLI docs](https://storybook.js.org/docs/7.0/react/api/cli-options). If there's an option you need to pass but it's not in the executor schema, you can always pass it, since the executors are just passing the options to the Storybook CLI.
|
||||
- More options from the Storybook CLI are now exposed in the executors. You can see these in the [`@nx/storybook:storybook`](/technologies/test-tools/storybook/api/executors/storybook) and [`@nx/storybook:build`](/technologies/test-tools/storybook/api/executors/build) executor schemas. You can read more about these options in the [Storybook 7 CLI docs](https://storybook.js.org/docs/7.0/react/api/cli-options). If there's an option you need to pass but it's not in the executor schema, you can always pass it, since the executors are just passing the options to the Storybook CLI.
|
||||
|
||||
## Report any issues and bugs
|
||||
|
||||
|
||||
@ -86,7 +86,7 @@ The `buildTargetName`, `previewTargetName`, `testTargetName`, `serveTargetName`
|
||||
|
||||
### Generate a new project using Vite
|
||||
|
||||
You can generate a [React](/nx-api/react) application or library or a [Web](/nx-api/web) application that uses Vite.js. The [`@nx/react:app`](/nx-api/react/generators/application), [`@nx/react:lib`](/nx-api/react/generators/library) and [`@nx/web:app`](/nx-api/web/generators/application) generators accept the `bundler` option, where you can pass `vite`. This will generate a new application configured to use Vite.js, and it will also install all the necessary dependencies, including the `@nx/vite` plugin.
|
||||
You can generate a [React](/technologies/react/api) application or library or a [Web](/reference/core-api/web) application that uses Vite.js. The [`@nx/react:app`](/technologies/react/api/generators/application), [`@nx/react:lib`](/technologies/react/api/generators/library) and [`@nx/web:app`](/reference/core-api/web/generators/application) generators accept the `bundler` option, where you can pass `vite`. This will generate a new application configured to use Vite.js, and it will also install all the necessary dependencies, including the `@nx/vite` plugin.
|
||||
|
||||
To generate a React application using Vite.js, run the following:
|
||||
|
||||
@ -110,4 +110,4 @@ nx g @nx/web:app apps/my-app --bundler=vite
|
||||
|
||||
You can use the `@nx/vite:configuration` generator to change your React or Web project to use Vite.js. This generator will modify your project's configuration to use Vite.js, and it will also install all the necessary dependencies, including the `@nx/vite` plugin..
|
||||
|
||||
You can read more about this generator on the [`@nx/vite:configuration`](/nx-api/vite/generators/configuration) generator page.
|
||||
You can read more about this generator on the [`@nx/vite:configuration`](/technologies/build-tools/vite/api/generators/configuration) generator page.
|
||||
|
||||
@ -44,12 +44,12 @@ The application uses no framework and generates with web components. You can add
|
||||
To start the application in development mode, run `nx serve my-new-app`.
|
||||
|
||||
{% callout type="note" title="React" %}
|
||||
If you are looking to add a React application, check out the [React plugin](/nx-api/react).
|
||||
If you are looking to add a React application, check out the [React plugin](/technologies/react/api).
|
||||
{% /callout %}
|
||||
|
||||
### Creating Libraries
|
||||
|
||||
To create a generic TypeScript library (i.e. non-framework specific), use the [`@nx/js`](/nx-api/js) plugin.
|
||||
To create a generic TypeScript library (i.e. non-framework specific), use the [`@nx/js`](/technologies/typescript/api) plugin.
|
||||
|
||||
```shell
|
||||
nx g @nx/js:lib libs/my-new-lib
|
||||
@ -107,5 +107,5 @@ The library in `dist` is publishable to npm or a private registry.
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [Using Cypress](/nx-api/cypress)
|
||||
- [Using Jest](/nx-api/jest)
|
||||
- [Using Cypress](/technologies/test-tools/cypress/api)
|
||||
- [Using Jest](/technologies/test-tools/jest/api)
|
||||
|
||||
@ -76,7 +76,7 @@ The `buildTargetName`, `previewTargetName`, `serveTargetName` and `serveStaticTa
|
||||
|
||||
## Generate a new project using Webpack
|
||||
|
||||
You can generate a [React](/nx-api/react) application or a [Web](/nx-api/web) application that uses Webpack in an existing Nx workspace. The [`@nx/react:app`](/nx-api/react/generators/application), [`@nx/node:app`](/nx-api/node/generators/application) and [`@nx/web:app`](/nx-api/web/generators/application) generators accept the `bundler` option, where you can pass `webpack`. This will generate a new application configured to use Webpack, and it will also install all the necessary dependencies, including the `@nx/webpack` plugin.
|
||||
You can generate a [React](/technologies/react/api) application or a [Web](/reference/core-api/web) application that uses Webpack in an existing Nx workspace. The [`@nx/react:app`](/technologies/react/api/generators/application), [`@nx/node:app`](/technologies/node/api/generators/application) and [`@nx/web:app`](/reference/core-api/web/generators/application) generators accept the `bundler` option, where you can pass `webpack`. This will generate a new application configured to use Webpack, and it will also install all the necessary dependencies, including the `@nx/webpack` plugin.
|
||||
|
||||
To generate a React application using Webpack, run the following:
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ Codifying your organization's best practices into local generators is a great wa
|
||||
## Reorganizing Projects
|
||||
|
||||
After some time of working within a workspace, projects might need to be moved or sometimes even removed.
|
||||
The workspace plugin provides the [`@nx/workspace:move`](/nx-api/workspace/generators/move) and [`@nx/workspace:remove`](/nx-api/workspace/generators/remove) generators to help aid with this.
|
||||
The workspace plugin provides the [`@nx/workspace:move`](/reference/core-api/workspace/generators/move) and [`@nx/workspace:remove`](/reference/core-api/workspace/generators/remove) generators to help aid with this.
|
||||
|
||||
### Moving Projects
|
||||
|
||||
@ -29,7 +29,7 @@ Moving the files manually can be done easily but a lot of steps are often missed
|
||||
5. Paths in target options such as output path will be changed
|
||||
6. Other configuration will be updated too, such as `extends` in `tsconfig.json`, the name of the project in `jest.config.js`, and the extends in `.eslintrc.json`
|
||||
|
||||
> See more about [`@nx/workspace:move`](/nx-api/workspace/generators/move)
|
||||
> See more about [`@nx/workspace:move`](/reference/core-api/workspace/generators/move)
|
||||
|
||||
### Removing Projects
|
||||
|
||||
@ -42,4 +42,4 @@ Like when moving projects, some steps are often missed when removing projects. T
|
||||
3. The project's configuration will be removed.
|
||||
4. The path mapping in `tsconfig.base.json` will be removed.
|
||||
|
||||
> See more about [`@nx/workspace:remove`](/nx-api/workspace/generators/remove)
|
||||
> See more about [`@nx/workspace:remove`](/reference/core-api/workspace/generators/remove)
|
||||
|
||||
@ -8,7 +8,7 @@ The purpose of a CI pipeline is to run tasks like `build`, `test`, `lint` and `e
|
||||
|
||||
Nx provides plugins for popular tools that make it easy to update to the latest version of that tool and [automatically updates](/features/automate-updating-dependencies) your configuration files to take advantage of enhancements in the tool. The tool authors are always looking for ways to improve their product and the best way to get the most out of the tool you're using is to make sure you're on the latest version. Also, the recommended configuration settings for a tool will change over time so even if you're on the latest version of a tool, you may be using a slower version of it because you don't know about a new configuration setting. [`nx migrate`](/features/automate-updating-dependencies) will automatically change the default settings of in your tooling config to use the latest recommended settings so that your repo won't be left behind.
|
||||
|
||||
Because Nx plugins have a consistent interface for how they are invoked and how they interact with the codebase, it is easier to try out a different tool to see if it is better than what you're currently using. Newer tools that were created with different technologies or different design decisions can be orders of magnitude faster than your existing tools. Or the new tool might not help your project. Browse through the [list of Nx plugins](/plugin-registry), like [vite](/nx-api/vite) or [rspack](/nx-api/rspack), and try it out on your project with the default settings already configured for you.
|
||||
Because Nx plugins have a consistent interface for how they are invoked and how they interact with the codebase, it is easier to try out a different tool to see if it is better than what you're currently using. Newer tools that were created with different technologies or different design decisions can be orders of magnitude faster than your existing tools. Or the new tool might not help your project. Browse through the [list of Nx plugins](/plugin-registry), like [vite](/technologies/build-tools/vite/api) or [rspack](/technologies/build-tools/rspack/api), and try it out on your project with the default settings already configured for you.
|
||||
|
||||
## Reduce Wasted Time
|
||||
|
||||
|
||||
@ -51,7 +51,7 @@ In order to guarantee that cache poisoning will never affect your end users, [sk
|
||||
|
||||
### Do Not Manually Share Your Local Cache
|
||||
|
||||
Nx implicitly trusts the local cache which is stored by default in the `.nx/cache` folder. You can change the location of that folder in the `nx.json` file, so it could be tempting to place it on a network drive and easily share your cache with everyone on the company network. However, by doing this you've voided the guarantee of immutability from your cache. If someone has direct access to the cached files, they could directly poison the cache. Nx will automatically detect if a cache entry has been created in your local cache using a different machine and warn you with an [Unknown Local Cache Error](/troubleshooting/unknown-local-cache). Instead, use Nx Cloud [remote caching](/ci/features/remote-cache). If you want share your local cache anyway, you can [activate Nx Powerpack](/nx-enterprise/activate-powerpack) and use the [`@nx/shared-fs-cache`](/nx-api/shared-fs-cache) plugin.
|
||||
Nx implicitly trusts the local cache which is stored by default in the `.nx/cache` folder. You can change the location of that folder in the `nx.json` file, so it could be tempting to place it on a network drive and easily share your cache with everyone on the company network. However, by doing this you've voided the guarantee of immutability from your cache. If someone has direct access to the cached files, they could directly poison the cache. Nx will automatically detect if a cache entry has been created in your local cache using a different machine and warn you with an [Unknown Local Cache Error](/troubleshooting/unknown-local-cache). Instead, use Nx Cloud [remote caching](/ci/features/remote-cache). If you want share your local cache anyway, you can [activate Nx Powerpack](/nx-enterprise/activate-powerpack) and use the [`@nx/shared-fs-cache`](/reference/core-api/shared-fs-cache) plugin.
|
||||
|
||||
### Configure End to End Encryption
|
||||
|
||||
|
||||
@ -98,6 +98,6 @@ In the same way that Nx efficiently assigns tasks to parallel processes on a sin
|
||||
|
||||
## Conclusion
|
||||
|
||||
If your repo is starting to grow large enough that CI times are suffering, or if your parallelization strategy is growing too complex to manage effectively, try [setting up Nx Agents](/ci/features/distribute-task-execution). You can [generate a simple workflow](/nx-api/workspace/generators/ci-workflow) for common CI providers with a `nx g ci-workflow` or follow one of the [CI setup recipes](/ci/recipes/set-up).
|
||||
If your repo is starting to grow large enough that CI times are suffering, or if your parallelization strategy is growing too complex to manage effectively, try [setting up Nx Agents](/ci/features/distribute-task-execution). You can [generate a simple workflow](/reference/core-api/workspace/generators/ci-workflow) for common CI providers with a `nx g ci-workflow` or follow one of the [CI setup recipes](/ci/recipes/set-up).
|
||||
|
||||
Organizations that want extra help setting up Nx Cloud or getting the most out of Nx can [sign up for Nx Enterprise](/enterprise). This package comes with extra support from the Nx team and the option to host Nx Cloud on your own servers.
|
||||
|
||||
@ -8,7 +8,7 @@ Let's create a custom rule which we can then publish to Nx Cloud. We will first
|
||||
nx generate @nx/js:library cloud-conformance-rules
|
||||
```
|
||||
|
||||
The Nx Cloud distribution mechanism expects each rule to be created in a named subdirectory in the `src/` directory of our new project, and each rule directory to contain an `index.ts` and a `schema.json` file. You can read more about [creating a conformance rule](/nx-api/conformance/documents/create-conformance-rule) in the dedicated guide. For this recipe, we'll generate a default rule to use in the publishing process.
|
||||
The Nx Cloud distribution mechanism expects each rule to be created in a named subdirectory in the `src/` directory of our new project, and each rule directory to contain an `index.ts` and a `schema.json` file. You can read more about [creating a conformance rule](/reference/core-api/conformance/documents/create-conformance-rule) in the dedicated guide. For this recipe, we'll generate a default rule to use in the publishing process.
|
||||
|
||||
```shell
|
||||
nx g @nx/conformance:create-rule --name=test-cloud-rule --directory=cloud-conformance-rules/src --category=reliability --description="A test cloud rule" --reporter=non-project-files-reporter
|
||||
@ -18,7 +18,7 @@ nx g @nx/conformance:create-rule --name=test-cloud-rule --directory=cloud-confor
|
||||
If you get an error resolving the `@nx/conformance` plugin, you may need to add it. You can do this by running `nx add @nx/conformance` in your workspace.
|
||||
{% /callout %}
|
||||
|
||||
We now have a valid implementation of a rule and we are ready to build it and publish it to Nx Cloud. The [`@nx/conformance` plugin](/nx-api/conformance) provides a [dedicated executor called `bundle-rules`](/nx-api/conformance/executors/bundle-rules) for creating appropriate build artifacts for this purpose. We will replace the existing build target and wire up that executor in our `cloud-conformance-rules` project's `project.json` file:
|
||||
We now have a valid implementation of a rule and we are ready to build it and publish it to Nx Cloud. The [`@nx/conformance` plugin](/reference/core-api/conformance) provides a [dedicated executor called `bundle-rules`](/reference/core-api/conformance/executors/bundle-rules) for creating appropriate build artifacts for this purpose. We will replace the existing build target and wire up that executor in our `cloud-conformance-rules` project's `project.json` file:
|
||||
|
||||
```jsonc {% fileName="cloud-conformance-rules/project.json" %}
|
||||
{
|
||||
|
||||
@ -79,10 +79,10 @@ If you upgraded Nx from an older version, ensure that [inferred tasks](/concepts
|
||||
|
||||
If you are already using the `@nx/cypress`, `@nx/playwright`, or `@nx/jest` plugin, you need to manually add the appropriate configuration to the `plugins` array of `nx.json`. Follow the instructions for the plugin you are using:
|
||||
|
||||
- [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)
|
||||
- [Configure Cypress Task Splitting](/technologies/test-tools/cypress/api#nxcypress-configuration)
|
||||
- [Configure Playwright Task Splitting](/technologies/test-tools/playwright/api#nxplaywright-configuration)
|
||||
- [Configure Jest Task Splitting](/technologies/test-tools/jest/api#splitting-e2e-tests)
|
||||
- [Configure Gradle Testing Task Splitting](/technologies/java/api#splitting-tests)
|
||||
|
||||
## Verify Automated Task Splitting Works
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ This task should produce the compiled output of this project. Typically, you'll
|
||||
}
|
||||
```
|
||||
|
||||
The task might use the [@nx/vite](/nx-api/vite), [@nx/webpack](/nx-api/webpack) or [@nx/rspack](/nx-api/rspack) plugins. Or you could have the task launch your own custom script.
|
||||
The task might use the [@nx/vite](/technologies/build-tools/vite/api), [@nx/webpack](/technologies/build-tools/webpack/api) or [@nx/rspack](/technologies/build-tools/rspack/api) plugins. Or you could have the task launch your own custom script.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Vite" %}
|
||||
@ -102,7 +102,7 @@ You can define your own `build` task in your project configuration. Here is an e
|
||||
|
||||
## `serve`
|
||||
|
||||
This task should run your project in a developer preview mode. The task might use the [@nx/vite](/nx-api/vite), [@nx/webpack](/nx-api/webpack) or [@nx/rspack](/nx-api/rspack) plugins. Or you could have the task launch your own custom script.
|
||||
This task should run your project in a developer preview mode. The task might use the [@nx/vite](/technologies/build-tools/vite/api), [@nx/webpack](/technologies/build-tools/webpack/api) or [@nx/rspack](/technologies/build-tools/rspack/api) plugins. Or you could have the task launch your own custom script.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Vite" %}
|
||||
@ -182,7 +182,7 @@ You can define your own `serve` task in your project configuration. Here is an e
|
||||
|
||||
## `test`
|
||||
|
||||
This task typically runs unit tests for a project. The task might use the [@nx/vite](/nx-api/vite) or [@nx/jest](/nx-api/jest) plugins. Or you could have the task launch your own custom script.
|
||||
This task typically runs unit tests for a project. The task might use the [@nx/vite](/technologies/build-tools/vite/api) or [@nx/jest](/technologies/test-tools/jest/api) plugins. Or you could have the task launch your own custom script.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Vitest" %}
|
||||
@ -242,7 +242,7 @@ You can define your own `test` task in your project configuration. Here is an ex
|
||||
|
||||
## `lint`
|
||||
|
||||
This task should run lint rules for a project. The task might use the [@nx/eslint](/nx-api/eslint) plugin or run your own custom script.
|
||||
This task should run lint rules for a project. The task might use the [@nx/eslint](/technologies/eslint/api) plugin or run your own custom script.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="ESLint" %}
|
||||
|
||||
@ -11,7 +11,7 @@ Projects are often grouped by _scope_. A project's scope is either the applicati
|
||||
|
||||
## Move Generator
|
||||
|
||||
Don't be too anxious about choosing the exact right folder structure from the beginning. Projects can be moved or renamed using the [`@nx/workspace:move` generator](/nx-api/workspace/generators/move).
|
||||
Don't be too anxious about choosing the exact right folder structure from the beginning. Projects can be moved or renamed using the [`@nx/workspace:move` generator](/reference/core-api/workspace/generators/move).
|
||||
|
||||
For instance, if a project under the `booking` folder is now being shared by multiple apps, you can move it to the shared folder like this:
|
||||
|
||||
@ -21,7 +21,7 @@ nx g move --project booking-some-project shared/some-project
|
||||
|
||||
## Remove Generator
|
||||
|
||||
Similarly, if you no longer need a project, you can remove it with the [`@nx/workspace:remove` generator](/nx-api/workspace/generators/remove).
|
||||
Similarly, if you no longer need a project, you can remove it with the [`@nx/workspace:remove` generator](/reference/core-api/workspace/generators/remove).
|
||||
|
||||
```shell
|
||||
nx g remove booking-some-project
|
||||
|
||||
@ -39,7 +39,7 @@ Nx provides tools to give you the benefits of a monorepo without the drawbacks o
|
||||
|
||||
- **Consistent Code Generation** - Generators allow you to customize and standardize organizational conventions and structure, removing the need to perform the same manual setup tasks repetitively.
|
||||
|
||||
- **Affected Commands** - [Nx's affected commands](/nx-api/nx/documents/affected) analyze your source code, the context of the changes, and only runs tasks on the affected projects impacted by the source code changes.
|
||||
- **Affected Commands** - [Nx's affected commands](/reference/core-api/nx/documents/affected) analyze your source code, the context of the changes, and only runs tasks on the affected projects impacted by the source code changes.
|
||||
|
||||
- **Remote Caching** - Nx provides local caching and support for remote caching of command executions. With remote caching, when someone on your team runs a command, everyone else gets access to those artifacts to speed up their command executions, bringing them down from minutes to seconds. Nx helps you scale your development to massive applications and libraries even more with distributed task execution and incremental builds.
|
||||
|
||||
|
||||
@ -68,7 +68,7 @@ If defining a new target that needs to run a single shell command, there is a sh
|
||||
}
|
||||
```
|
||||
|
||||
For more info, see the [run-commands documentation](/nx-api/nx/executors/run-commands)
|
||||
For more info, see the [run-commands documentation](/reference/core-api/nx/executors/run-commands)
|
||||
|
||||
## Build your own Executor
|
||||
|
||||
|
||||
@ -9,10 +9,10 @@ Nx plugins help developers use a tool or framework with Nx. They allow the plugi
|
||||
|
||||
For example, plugins can accomplish the following:
|
||||
|
||||
- [Configure Nx cache settings](/concepts/inferred-tasks) for a tool. The [`@nx/webpack`](/nx-api/webpack) plugin can automatically configure the [inputs](/recipes/running-tasks/configure-inputs) and [outputs](/recipes/running-tasks/configure-outputs) for a `build` task based on the settings in the `webpack.config.js` file it uses.
|
||||
- [Update tooling configuration](/features/automate-updating-dependencies) when upgrading the tool version. When Storybook 7 introduced a [new format](https://storybook.js.org/blog/storybook-csf3-is-here) for their configuration files, anyone using the [`@nx/storybook`](/nx-api/storybook) plugin could automatically apply those changes to their repository when upgrading.
|
||||
- [Set up a tool](/features/generate-code) for the first time. With the [`@nx/playwright`](/nx-api/playwright) plugin installed, you can use the `@nx/playwright:configuration` code generator to set up Playwright tests in an existing project.
|
||||
- [Run a tool in an advanced way](/concepts/executors-and-configurations). The [`@nx/js`](/nx-api/js) plugin's [`@nx/js:tsc` executor](/nx-api/js/executors/tsc) combines Nx's understanding of your repository with Typescript's native batch mode feature to make your builds [even more performant](/technologies/typescript/recipes/enable-tsc-batch-mode).
|
||||
- [Configure Nx cache settings](/concepts/inferred-tasks) for a tool. The [`@nx/webpack`](/technologies/build-tools/webpack/api) plugin can automatically configure the [inputs](/recipes/running-tasks/configure-inputs) and [outputs](/recipes/running-tasks/configure-outputs) for a `build` task based on the settings in the `webpack.config.js` file it uses.
|
||||
- [Update tooling configuration](/features/automate-updating-dependencies) when upgrading the tool version. When Storybook 7 introduced a [new format](https://storybook.js.org/blog/storybook-csf3-is-here) for their configuration files, anyone using the [`@nx/storybook`](/technologies/test-tools/storybook/api) plugin could automatically apply those changes to their repository when upgrading.
|
||||
- [Set up a tool](/features/generate-code) for the first time. With the [`@nx/playwright`](/technologies/test-tools/playwright/api) plugin installed, you can use the `@nx/playwright:configuration` code generator to set up Playwright tests in an existing project.
|
||||
- [Run a tool in an advanced way](/concepts/executors-and-configurations). The [`@nx/js`](/technologies/typescript/api) plugin's [`@nx/js:tsc` executor](/technologies/typescript/api/executors/tsc) combines Nx's understanding of your repository with Typescript's native batch mode feature to make your builds [even more performant](/technologies/typescript/recipes/enable-tsc-batch-mode).
|
||||
|
||||
## Plugin Features
|
||||
|
||||
@ -26,7 +26,6 @@ For example, plugins can accomplish the following:
|
||||
## Types of Plugins
|
||||
|
||||
{% cards %}
|
||||
{% card title="Official Plugins" description="The API documentation for Nx Plugins maintained by the Nx core team" type="documentation" url="/nx-api" /%}
|
||||
{% card title="Community Plugins" description="Browse the plugin registry to discover plugins created by the community" type="documentation" url="/plugin-registry" /%}
|
||||
{% card title="Official and Community Plugins" description="Browse the plugin registry to discover plugins created by the Nx core team and the community" type="documentation" url="/plugin-registry" /%}
|
||||
{% card title="Build Your Own Plugin" description="Build your own plugin to use internally or share with the community" type="documentation" url="/extending-nx/tutorials/organization-specific-plugin" /%}
|
||||
{% /cards %}
|
||||
|
||||
@ -13,12 +13,12 @@ To switch from using the Angular CLI to using the Nx CLI follow the [migrating a
|
||||
|
||||
## Interop between Nx Generators and Angular Schematics
|
||||
|
||||
You can wrap any Nx generator with the [convertNxGenerator](/nx-api/devkit/documents/convertNxGenerator) function and re-export it in your own plugin as a schematic. This is helpful if you still want to support the Angular CLI.
|
||||
You can wrap any Nx generator with the [convertNxGenerator](/reference/core-api/devkit/documents/convertNxGenerator) function and re-export it in your own plugin as a schematic. This is helpful if you still want to support the Angular CLI.
|
||||
|
||||
To convert an existing Angular Schematic to an Nx Generator, use the [wrapAngularDevkitSchematic](/nx-api/devkit/documents/ngcli_adapter/wrapAngularDevkitSchematic) utility function. This is helpful if you want to [programmatically call](/extending-nx/recipes/composing-generators) an Angular Schematic inside of a [custom Nx Generator](/extending-nx/recipes/local-generators).
|
||||
To convert an existing Angular Schematic to an Nx Generator, use the [wrapAngularDevkitSchematic](/reference/core-api/devkit/documents/ngcli_adapter/wrapAngularDevkitSchematic) utility function. This is helpful if you want to [programmatically call](/extending-nx/recipes/composing-generators) an Angular Schematic inside of a [custom Nx Generator](/extending-nx/recipes/local-generators).
|
||||
|
||||
## Interop between Nx Executors and Angular Builders
|
||||
|
||||
You can wrap any Nx executor with the [convertNxExecutor](/nx-api/devkit/documents/convertNxExecutor) function and re-export it in your own plugin as a builder.
|
||||
You can wrap any Nx executor with the [convertNxExecutor](/reference/core-api/devkit/documents/convertNxExecutor) function and re-export it in your own plugin as a builder.
|
||||
|
||||
There is no existing utility function to convert an Angular Builder to an Nx Executor. If you want to [programmatically call](/extending-nx/recipes/compose-executors) an Angular Builder inside of a [custom Nx Executor](extending-nx/recipes/local-executors), you can import the Angular Builder into your Nx Executor's implementation and call it directly.
|
||||
|
||||
@ -84,7 +84,7 @@ This makes app or lib generators behave in the following way:
|
||||
- `nx g app my-app --directory=nested` creates a new application named `nested-my-app` in the `/demos/nested/my-app` folder
|
||||
- `nx g lib my-lib --directory=shared/ui` creates a new library named `shared-ui-my-lib` in the `/packages/shared/ui/my-lib` folder
|
||||
|
||||
If you accidentally generate a project in the wrong folder, use the [move generator](/nx-api/workspace/generators/move) to move it to the correct location.
|
||||
If you accidentally generate a project in the wrong folder, use the [move generator](/reference/core-api/workspace/generators/move) to move it to the correct location.
|
||||
|
||||
## Code Generators
|
||||
|
||||
|
||||
@ -20,7 +20,7 @@ Read more in our [documentation](/recipes/running-tasks/self-hosted-caching).
|
||||
|
||||
### Migrating from `@nx-aws-plugin`
|
||||
|
||||
If you've been using the `@nx-aws-plugin/nx-aws-cache` community plugin, you should be easily able to migrate to the free [Nx S3 cache plugin](/nx-api/s3-cache). The specific modification depends on your repository's configuration.
|
||||
If you've been using the `@nx-aws-plugin/nx-aws-cache` community plugin, you should be easily able to migrate to the free [Nx S3 cache plugin](/reference/core-api/s3-cache). The specific modification depends on your repository's configuration.
|
||||
|
||||
The following is one example, where a custom tasks runner configuration in `nx.json` will be removed:
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ If you are using a custom tasks runner to customize your cache, you have the fol
|
||||
|
||||
Use [Nx Cloud](/nx-cloud) for your remote cache. This is the safest, lowest-maintenance, most recommended option.
|
||||
|
||||
If you cannot use Nx Cloud, consider an [Nx Powerpack](/powerpack) plugin for caching: [Amazon S3](/nx-api/s3-cache), [Google Cloud](/nx-api/gcs-cache), [Azure](/nx-api/azure-cache) or a [shared network drive](/nx-api/shared-fs-cache). If there is no Powerpack plugin that supports the service where you want to store the remote cache, [file an issue](https://github.com/nrwl/nx/issues/new).
|
||||
If you cannot use Nx Cloud, consider an [Nx Powerpack](/powerpack) plugin for caching: [Amazon S3](/reference/core-api/s3-cache), [Google Cloud](/reference/core-api/gcs-cache), [Azure](/reference/core-api/azure-cache) or a [shared network drive](/reference/core-api/shared-fs-cache). If there is no Powerpack plugin that supports the service where you want to store the remote cache, [file an issue](https://github.com/nrwl/nx/issues/new).
|
||||
|
||||
**To learn more about migrating from custom task runners, [please refer to this detailed guide](/deprecated/custom-tasks-runner).**
|
||||
|
||||
@ -33,5 +33,5 @@ The `NX_REJECT_UNKNOWN_LOCAL_CACHE` environment variable does not work with the
|
||||
If you are using `NX_REJECT_UNKNOWN_LOCAL_CACHE` to share your local cache on a network drive, you have a few options moving forward:
|
||||
|
||||
1. Use [Nx Cloud](/nx-cloud) for your remote cache. This is the safest, lowest-maintenance, most recommended option
|
||||
2. Use the [Nx Powerpack Shared Fs Cache](/nx-api/shared-fs-cache) which recognizes artifacts from other machines
|
||||
3. Use another [Nx Powerpack](/powerpack) plugin for caching on a cloud provider: [Amazon S3](/nx-api/s3-cache), [Google Cloud](/nx-api/gcs-cache), or [Azure](/nx-api/azure-cache)
|
||||
2. Use the [Nx Powerpack Shared Fs Cache](/reference/core-api/shared-fs-cache) which recognizes artifacts from other machines
|
||||
3. Use another [Nx Powerpack](/powerpack) plugin for caching on a cloud provider: [Amazon S3](/reference/core-api/s3-cache), [Google Cloud](/reference/core-api/gcs-cache), or [Azure](/reference/core-api/azure-cache)
|
||||
|
||||
@ -22,7 +22,7 @@ To remove `workspace.json` in favor of `project.json` files, run:
|
||||
nx g @nx/workspace:fix-configuration
|
||||
```
|
||||
|
||||
See [fix-configuration](/nx-api/workspace/generators/fix-configuration) for more options.
|
||||
See [fix-configuration](/reference/core-api/workspace/generators/fix-configuration) for more options.
|
||||
|
||||
After this command, `workspace.json` should look like this:
|
||||
|
||||
|
||||
@ -29,9 +29,9 @@ Want a more visual and guided way to migrate? Check out the [Migrate UI](/recipe
|
||||
|
||||
## How Does It Work?
|
||||
|
||||
Nx knows where its configuration files are located and ensures they match the expected format. This automated update process, commonly referred to as "migration," becomes even **more powerful when you leverage [Nx plugins](/nx-api)**. Each plugin can provide migrations for its area of competency.
|
||||
Nx knows where its configuration files are located and ensures they match the expected format. This automated update process, commonly referred to as "migration," becomes even **more powerful when you leverage [Nx plugins](/plugin-registry)**. Each plugin can provide migrations for its area of competency.
|
||||
|
||||
For example, the [Nx React plugin](/nx-api/react) knows where to look for React and Nx specific configuration files and knows how to apply certain changes when updating to a given version of React.
|
||||
For example, the [Nx React plugin](/technologies/react/api) knows where to look for React and Nx specific configuration files and knows how to apply certain changes when updating to a given version of React.
|
||||
|
||||
In the example below, the React plugin defines a migration script (`./src/migrations/.../add-babel-core`) that runs when upgrading to Nx `16.7.0-beta.2` (or higher).
|
||||
|
||||
|
||||
@ -178,4 +178,4 @@ Caching is hard. If you run into issues, check out the following resources:
|
||||
- [Debug cache misses](/troubleshooting/troubleshoot-cache-misses)
|
||||
- [Turn off or skip the cache](/recipes/running-tasks/skipping-cache)
|
||||
- [Change the cache location](/recipes/running-tasks/change-cache-location)
|
||||
- [Clear the local or remote cache](/nx-api/nx/documents/reset)
|
||||
- [Clear the local or remote cache](/reference/core-api/nx/documents/reset)
|
||||
|
||||
@ -9,7 +9,7 @@ description: 'Learn how to use Nx code generators to automate repetitive tasks,
|
||||
|
||||
Code generators are like automation scripts designed to streamline your workflow. Essentially, they are TypeScript functions that accept parameters and help boost your productivity by:
|
||||
|
||||
- Allowing you to **scaffold new projects** or **augment existing projects** with new features, like [adding Storybook support](/nx-api/storybook#generating-storybook-configuration)
|
||||
- Allowing you to **scaffold new projects** or **augment existing projects** with new features, like [adding Storybook support](/technologies/test-tools/storybook/api#generating-storybook-configuration)
|
||||
- **Automating repetitive tasks** in your development workflow
|
||||
- Ensuring your **code is consistent and follows best practices**
|
||||
|
||||
|
||||
@ -7,14 +7,14 @@ description: 'Learn how to use Nx Powerpack conformance rules to enforce organiz
|
||||
|
||||
{% youtube src="https://youtu.be/6wg23sLveTQ" title="Nx Powerpack workspace conformance" /%}
|
||||
|
||||
The [`@nx/conformance`](/nx-api/conformance) plugin allows [Nx Powerpack](/powerpack) users to write and apply rules for your entire workspace that help with **consistency**, **maintainability**, **reliability** and **security**. Powerpack is available for Nx version 19.8 and higher.
|
||||
The [`@nx/conformance`](/reference/core-api/conformance) plugin allows [Nx Powerpack](/powerpack) users to write and apply rules for your entire workspace that help with **consistency**, **maintainability**, **reliability** and **security**. Powerpack is available for Nx version 19.8 and higher.
|
||||
|
||||
The conformance plugin allows you to **encode your own organization's standards** so that they can be enforced automatically. Conformance rules can also **complement linting tools** by enforcing that those tools are configured in the recommended way. The rules are written in TypeScript but can be **applied to any language in the codebase** or focus entirely on configuration files.
|
||||
|
||||
The plugin also provides the following pre-written rules:
|
||||
|
||||
- **Enforce Project Boundaries**: Similar to the Nx [ESLint Enforce Module Boundaries rule](/features/enforce-module-boundaries), but enforces the boundaries on every project dependency, not just those created from TypeScript imports or `package.json` dependencies.
|
||||
- **Ensure Owners**: Require every project to have an owner defined for the [`@nx/owners` plugin](/nx-api/owners)
|
||||
- **Ensure Owners**: Require every project to have an owner defined for the [`@nx/owners` plugin](/reference/core-api/owners)
|
||||
|
||||
## Setup
|
||||
|
||||
@ -24,11 +24,11 @@ The `@nx/conformance` plugin requires an Nx Powerpack license to function. [Acti
|
||||
|
||||
Then, add the Conformance plugin to your workspace.
|
||||
|
||||
{% link-card title="Conformance" type="Nx Plugin" url="/nx-api/conformance" icon="CheckBadgeIcon" /%}
|
||||
{% link-card title="Conformance" type="Nx Plugin" url="/reference/core-api/conformance/overview" icon="CheckBadgeIcon" /%}
|
||||
|
||||
## Configure Conformance Rules
|
||||
|
||||
Conformance rules are configured in the `conformance` property of the `nx.json` file. You can use the pre-defined rules or reference [your own custom rule](/nx-api/conformance#custom-conformance-rules). See the [plugin documentation](/nx-api/conformance) for more details.
|
||||
Conformance rules are configured in the `conformance` property of the `nx.json` file. You can use the pre-defined rules or reference [your own custom rule](/reference/core-api/conformance#custom-conformance-rules). See the [plugin documentation](/reference/core-api/conformance) for more details.
|
||||
|
||||
```jsonc {% fileName="nx.json" %}
|
||||
{
|
||||
|
||||
@ -19,11 +19,11 @@ The `@nx/owners` plugin requires an Nx Powerpack license to function. [Activatin
|
||||
|
||||
Then, add the Owners plugin to your workspace.
|
||||
|
||||
{% link-card title="Owners" type="Nx Plugin" url="/nx-api/owners" icon="UserGroupIcon" /%}
|
||||
{% link-card title="Owners" type="Nx Plugin" url="/reference/core-api/owners/overview" icon="UserGroupIcon" /%}
|
||||
|
||||
## Project or File-based Configuration
|
||||
|
||||
The ownership configuration is defined in the `nx.json` file or in individual project configuration files. Nx then uses a [sync generator](/concepts/sync-generators) to automatically compile those settings into a valid CODEOWNERS file for GitHub, Bitbucket or GitLab. See the [plugin documentation](/nx-api/owners) for more details.
|
||||
The ownership configuration is defined in the `nx.json` file or in individual project configuration files. Nx then uses a [sync generator](/concepts/sync-generators) to automatically compile those settings into a valid CODEOWNERS file for GitHub, Bitbucket or GitLab. See the [plugin documentation](/reference/core-api/owners) for more details.
|
||||
|
||||
{% cards smCols="2" mdCols="2" lgCols="2" %}
|
||||
|
||||
|
||||
@ -138,7 +138,7 @@ npx nx run-many -t build lint test -p header footer
|
||||
|
||||
Nx parallelizes these tasks, ensuring they **run in the correct order based on their dependencies** and [task pipeline configuration](/concepts/task-pipeline-configuration). You can also [control how many tasks run in parallel at once](/recipes/running-tasks/run-tasks-in-parallel).
|
||||
|
||||
Learn more about the [run-many](/nx-api/nx/documents/run-many) command.
|
||||
Learn more about the [run-many](/reference/core-api/nx/documents/run-many) command.
|
||||
|
||||
### Run Tasks on Projects Affected by a PR
|
||||
|
||||
@ -250,7 +250,7 @@ Sometimes, you need tasks that apply to the entire codebase rather than a single
|
||||
|
||||
> Note the `nx: {}` property on the `package.json`. This is necessary to inform Nx about this root-level project. The property can also be expanded to specify cache inputs and outputs.
|
||||
|
||||
If you want Nx to cache the task, but prefer to use npm (or pnpm/yarn) to run the script (i.e. `npm run docs`) you can use the [nx exec](/nx-api/nx/documents/exec) command:
|
||||
If you want Nx to cache the task, but prefer to use npm (or pnpm/yarn) to run the script (i.e. `npm run docs`) you can use the [nx exec](/reference/core-api/nx/documents/exec) command:
|
||||
|
||||
```json {% fileName="package.json" %}
|
||||
{
|
||||
|
||||
@ -80,14 +80,14 @@ Also, here are some recipes that give you more details based on the technology s
|
||||
|
||||
{% cards cols="3" lgCols="8" mdCols="6" smCols="5" moreLink="/showcase/example-repos" %}
|
||||
|
||||
{% link-card title="Express" appearance="small" url="/nx-api/express" icon="express" /%}
|
||||
{% link-card title="Vue" appearance="small" url="/nx-api/vue" icon="vue" /%}
|
||||
{% link-card title="Next" appearance="small" url="/nx-api/next" icon="nextjs" /%}
|
||||
{% link-card title="Nuxt" appearance="small" url="/nx-api/nuxt" icon="nuxt" /%}
|
||||
{% link-card title="Nest" appearance="small" url="/nx-api/nest" icon="nestjs" /%}
|
||||
{% link-card title="Remix" appearance="small" url="/nx-api/remix" icon="remix" /%}
|
||||
{% link-card title="Expo" appearance="small" url="/nx-api/expo" icon="expo" /%}
|
||||
{% link-card title="React Native" appearance="small" url="/nx-api/react-native" icon="react" /%}
|
||||
{% link-card title="Express" appearance="small" url="/technologies/node/express" icon="express" /%}
|
||||
{% link-card title="Vue" appearance="small" url="/technologies/vue/introduction" icon="vue" /%}
|
||||
{% link-card title="Next" appearance="small" url="/technologies/react/next" icon="nextjs" /%}
|
||||
{% link-card title="Nuxt" appearance="small" url="/technologies/vue/nuxt/introduction" icon="nuxt" /%}
|
||||
{% link-card title="Nest" appearance="small" url="/technologies/node/nest" icon="nestjs" /%}
|
||||
{% link-card title="Remix" appearance="small" url="/technologies/react/remix" icon="remix" /%}
|
||||
{% link-card title="Expo" appearance="small" url="/technologies/react/expo" icon="expo" /%}
|
||||
{% link-card title="React Native" appearance="small" url="/technologies/react/react-native" icon="react" /%}
|
||||
{% link-card title="Fastify" appearance="small" url="/showcase/example-repos/mongo-fastify" icon="fastify" /%}
|
||||
{% link-card title="Svelte" appearance="small" url="/showcase/example-repos/add-svelte" icon="svelte" /%}
|
||||
{% link-card title="Solid" appearance="small" url="/showcase/example-repos/add-solid" icon="solid" /%}
|
||||
@ -98,12 +98,12 @@ Also, here are some recipes that give you more details based on the technology s
|
||||
{% link-card title="Rust" appearance="small" url="/showcase/example-repos/add-rust" icon="rust" /%}
|
||||
{% link-card title="Go" appearance="small" url="https://github.com/nrwl/nx-recipes/blob/main/go/README.md" icon="go" /%}
|
||||
{% link-card title=".NET" appearance="small" url="https://github.com/nrwl/nx-recipes/tree/main/dot-net-standalone" icon="dotnet" /%}
|
||||
{% link-card title="Cypress" appearance="small" url="/nx-api/cypress" icon="cypress" /%}
|
||||
{% link-card title="Playwright" appearance="small" url="/nx-api/playwright" icon="playwright" /%}
|
||||
{% link-card title="Vite" appearance="small" url="/nx-api/vite" icon="vite" /%}
|
||||
{% link-card title="Storybook" appearance="small" url="/nx-api/storybook" icon="storybook" /%}
|
||||
{% link-card title="Jest" appearance="small" url="/nx-api/jest" icon="jest" /%}
|
||||
{% link-card title="Rspack" appearance="small" url="/nx-api/rspack" icon="rspack" /%}
|
||||
{% link-card title="Cypress" appearance="small" url="/technologies/test-tools/cypress/introduction" icon="cypress" /%}
|
||||
{% link-card title="Playwright" appearance="small" url="/technologies/test-tools/playwright/introduction" icon="playwright" /%}
|
||||
{% link-card title="Vite" appearance="small" url="/technologies/build-tools/vite" icon="vite" /%}
|
||||
{% link-card title="Storybook" appearance="small" url="/technologies/test-tools/storybook" icon="storybook" /%}
|
||||
{% link-card title="Jest" appearance="small" url="/technologies/test-tools/jest/introduction" icon="jest" /%}
|
||||
{% link-card title="Rspack" appearance="small" url="/technologies/build-tools/rspack/introduction" icon="rspack" /%}
|
||||
|
||||
{% /cards %}
|
||||
|
||||
|
||||
@ -100,7 +100,7 @@ After generating the application, you will notice the following:
|
||||
- A `rspack.config.ts` file in the root of the project
|
||||
- The `project.json` file does not have a `targets.build` or `targets.serve` target
|
||||
|
||||
The `rspack.config.ts` file is a configuration file for Rspack. It contains the configuration options for Rspack and for Angular Rspack a helper [createConfig](/nx-api/angular-rspack/documents/create-config)
|
||||
The `rspack.config.ts` file is a configuration file for Rspack. It contains the configuration options for Rspack and for Angular Rspack a helper [createConfig](/technologies/angular/angular-rspack/api)
|
||||
function is used to map the options you would expect to set in the `project.json` or `angular.json` files to the Rspack configuration.
|
||||
|
||||
The `project.json` file does not contain the `targets.build` or `targets.serve` targets because Angular Rspack uses Nx's [Inferred Tasks](concepts/inferred-tasks) to build and serve your application with Rspack.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user