diff --git a/docs/generated/packages/cypress.json b/docs/generated/packages/cypress.json index 0352b6e085..13f28e1cf3 100644 --- a/docs/generated/packages/cypress.json +++ b/docs/generated/packages/cypress.json @@ -11,7 +11,7 @@ "id": "overview", "path": "/packages/cypress", "file": "shared/cypress-plugin", - "content": "![Cypress logo](/shared/cypress-logo.png)\n\nCypress is a test runner built for the modern web. It has a lot of great features:\n\n- Time travel\n- Real-time reloads\n- Automatic waiting\n- Spies, stubs, and clocks\n- Network traffic control\n- Screenshots and videos\n\n## Setting Up Cypress\n\n> Info about [Cypress Component Testing can be found here](/cypress/cypress-component-testing)\n\nIf the `@nrwl/cypress` package is not installed, install the version that matches your `nx` package version.\n\n```bash\nyarn add --dev @nrwl/cypress\n```\n\n```bash\nnpm install --save-dev @nrwl/cypress\n```\n\n## E2E Testing\n\nBy default, when creating a new frontend application, Nx will use Cypress to create the e2e tests project.\n\n```bash\nnx g @nrwl/web:app frontend\n```\n\n### Creating a Cypress E2E project for an existing project\n\nTo generate an E2E project based on an existing project, run the following generator\n\n```bash\nnx g @nrwl/cypress:cypress-project your-app-name-e2e --project=your-app-name\n```\n\nOptionally, you can use the `--baseUrl` option if you don't want cypress plugin to serve `your-app-name`.\n\n```bash\nnx g @nrwl/cypress:cypress-project your-app-name-e2e --baseUrl=http://localhost:4200\n```\n\nReplace `your-app-name` with the app's name as defined in your `workspace.json` file.\n\n### Testing Applications\n\nRun `nx e2e frontend-e2e` to execute e2e tests with Cypress.\n\nYou can run your e2e test against a production build by using the `production` [configuration](https://nx.dev/recipe/use-executor-configurations#use-executor-configurations)\n\n```bash\nnx e2e frontend-e2e --configuration=production\n```\n\nBy default, Cypress will run in headless mode. You will have the result of all the tests and errors (if any) in your\nterminal. Screenshots and videos will be accessible in `dist/cypress/apps/frontend/screenshots` and `dist/cypress/apps/frontend/videos`.\n\n### Watching for Changes (Headed Mode)\n\nWith, `nx e2e frontend-e2e --watch` Cypress will start in headed mode where you can see your application being tested.\n\nRunning Cypress with `--watch` is a great way to enhance dev workflow - you can build up test files with the application\nrunning and Cypress will re-run those tests as you enhance and add to the suite.\n\n```bash\nnx e2e frontend-e2e --watch\n```\n\n### Specifying a Custom Url to Test\n\nThe `baseUrl` property provides you the ability to test an application hosted on a specific domain.\n\n```bash\nnx e2e frontend-e2e --baseUrl=https://frontend.com\n```\n\n> If no `baseUrl` and no `devServerTarget` are provided, Cypress will expect to have the `baseUrl` property in\n> the cypress config file, or will error.\n\n## Using cypress.config.ts\n\nIf you need to fine tune your Cypress setup, you can do so by modifying `cypress.config.ts` in the project root. For\ninstance,\nyou can easily add your `projectId` to save all the screenshots and videos into your Cypress dashboard. The complete\nconfiguration is documented\non [the official website](https://docs.cypress.io/guides/references/configuration.html#Options).\n\n## Environment Variables\n\nIf you're needing to pass a variable to cypress that you wish to not commit to your repository, i.e. API keys, or dynamic values based on configurations, i.e. API Urls. This is where [Cypress environment variables](https://docs.cypress.io/guides/guides/environment-variables) can be used.\n\nThere are a handful of ways to pass environment variables to Cypress, but the most common is going to be via the [`cypress.env.json` file](https://docs.cypress.io/guides/guides/environment-variables#Option-1-configuration-file), the [env executor option for cypress](https://nx.dev/packages/cypress/executors/cypress#env) or the commandline.\n\nCreate a `cypress.env.json` file in the projects root i.e. `apps/my-cool-app-e2e/cypress.env.json`. Cypress will automatically pick up this file. This method is helpful for configurations that you want to not commit. Just don't forget to add the file to the `.gitignore` and add documentation so people in your repo know what values to popluate in their local copy of the `cypress.env.json` file.\n\nUsing [@nrwl/cypress:cypress](/packages/cypress/executors/cypress) env executor option is a good way to add values you want to define that you don't mine commit to the repository, such as a base API url. You can leverage [target configurations](/reference/project-configuration#targets) to define different values as well.\n\nOptionally, you can pass environment variables via the commandline with the `--env` flag.\n\n{% callout type=\"warning\" title=\"Executor options and --env\" %}\nWhen using the `--env` flag, this will not be merged with any values used in the `env` executor option.\n{% /callout %}\n\n```bash\nnx e2e frontend-e2e --env.API_URL=\"https://api.my-nx-website.com\" --env.API_KEY=\"abc-123\"\n```\n" + "content": "![Cypress logo](/shared/cypress-logo.png)\n\nCypress is a test runner built for the modern web. It has a lot of great features:\n\n- Time travel\n- Real-time reloads\n- Automatic waiting\n- Spies, stubs, and clocks\n- Network traffic control\n- Screenshots and videos\n\n## Setting Up Cypress\n\n> Info about [Cypress Component Testing can be found here](/cypress/cypress-component-testing)\n\nIf the `@nrwl/cypress` package is not installed, install the version that matches your `nx` package version.\n\n```bash\nyarn add --dev @nrwl/cypress\n```\n\n```bash\nnpm install --save-dev @nrwl/cypress\n```\n\n## E2E Testing\n\nBy default, when creating a new frontend application, Nx will use Cypress to create the e2e tests project.\n\n```bash\nnx g @nrwl/web:app frontend\n```\n\n### Creating a Cypress E2E project for an existing project\n\nTo generate an E2E project based on an existing project, run the following generator\n\n```bash\nnx g @nrwl/cypress:cypress-project your-app-name-e2e --project=your-app-name\n```\n\nOptionally, you can use the `--baseUrl` option if you don't want cypress plugin to serve `your-app-name`.\n\n```bash\nnx g @nrwl/cypress:cypress-project your-app-name-e2e --baseUrl=http://localhost:4200\n```\n\nReplace `your-app-name` with the app's name as defined in your `tsconfig.base.json` file or the `name` property of your `package.json`.\n\n### Testing Applications\n\nRun `nx e2e frontend-e2e` to execute e2e tests with Cypress.\n\nYou can run your e2e test against a production build by using the `production` [configuration](https://nx.dev/recipe/use-executor-configurations#use-executor-configurations)\n\n```bash\nnx e2e frontend-e2e --configuration=production\n```\n\nBy default, Cypress will run in headless mode. You will have the result of all the tests and errors (if any) in your\nterminal. Screenshots and videos will be accessible in `dist/cypress/apps/frontend/screenshots` and `dist/cypress/apps/frontend/videos`.\n\n### Watching for Changes (Headed Mode)\n\nWith, `nx e2e frontend-e2e --watch` Cypress will start in headed mode where you can see your application being tested.\n\nRunning Cypress with `--watch` is a great way to enhance dev workflow - you can build up test files with the application\nrunning and Cypress will re-run those tests as you enhance and add to the suite.\n\n```bash\nnx e2e frontend-e2e --watch\n```\n\n### Specifying a Custom Url to Test\n\nThe `baseUrl` property provides you the ability to test an application hosted on a specific domain.\n\n```bash\nnx e2e frontend-e2e --baseUrl=https://frontend.com\n```\n\n> If no `baseUrl` and no `devServerTarget` are provided, Cypress will expect to have the `baseUrl` property in\n> the cypress config file, or will error.\n\n## Using cypress.config.ts\n\nIf you need to fine tune your Cypress setup, you can do so by modifying `cypress.config.ts` in the project root. For\ninstance,\nyou can easily add your `projectId` to save all the screenshots and videos into your Cypress dashboard. The complete\nconfiguration is documented\non [the official website](https://docs.cypress.io/guides/references/configuration.html#Options).\n\n## Environment Variables\n\nIf you're needing to pass a variable to cypress that you wish to not commit to your repository, i.e. API keys, or dynamic values based on configurations, i.e. API Urls. This is where [Cypress environment variables](https://docs.cypress.io/guides/guides/environment-variables) can be used.\n\nThere are a handful of ways to pass environment variables to Cypress, but the most common is going to be via the [`cypress.env.json` file](https://docs.cypress.io/guides/guides/environment-variables#Option-1-configuration-file), the [env executor option for cypress](https://nx.dev/packages/cypress/executors/cypress#env) or the commandline.\n\nCreate a `cypress.env.json` file in the projects root i.e. `apps/my-cool-app-e2e/cypress.env.json`. Cypress will automatically pick up this file. This method is helpful for configurations that you want to not commit. Just don't forget to add the file to the `.gitignore` and add documentation so people in your repo know what values to popluate in their local copy of the `cypress.env.json` file.\n\nUsing [@nrwl/cypress:cypress](/packages/cypress/executors/cypress) env executor option is a good way to add values you want to define that you don't mine commit to the repository, such as a base API url. You can leverage [target configurations](/reference/project-configuration#targets) to define different values as well.\n\nOptionally, you can pass environment variables via the commandline with the `--env` flag.\n\n{% callout type=\"warning\" title=\"Executor options and --env\" %}\nWhen using the `--env` flag, this will not be merged with any values used in the `env` executor option.\n{% /callout %}\n\n```bash\nnx e2e frontend-e2e --env.API_URL=\"https://api.my-nx-website.com\" --env.API_KEY=\"abc-123\"\n```\n" }, { "name": "Component Testing", diff --git a/docs/generated/packages/detox.json b/docs/generated/packages/detox.json index 51656758a7..113635504c 100644 --- a/docs/generated/packages/detox.json +++ b/docs/generated/packages/detox.json @@ -11,7 +11,7 @@ "name": "Overview", "path": "/packages/detox", "file": "shared/detox-plugin", - "content": "![Detox logo](/shared/detox-logo.png)\n\nDetox is gray box end-to-end testing and automation library for mobile apps. It has a lot of great features:\n\n- Cross Platform\n- Runs on Devices\n- Automatically Synchronized\n- Test Runner Independent\n- Debuggable\n\n## Setting Up Detox\n\n### Install applesimutils (Mac only)\n\n[applesimutils](https://github.com/wix/AppleSimulatorUtils) is a collection of utils for Apple simulators.\n\n```sh\nbrew tap wix/brew\nbrew install applesimutils\n```\n\n### Install Jest Globally\n\n```sh\nnpm install -g jest\n```\n\n### Generating Applications\n\nBy default, when creating a mobile application, Nx will use Detox to create the e2e tests project.\n\n```bash\nnx g @nrwl/react-native:app frontend\n```\n\n### Creating a Detox E2E project for an existing project\n\nYou can create a new Detox E2E project for an existing mobile project.\n\nIf the `@nrwl/detox` package is not installed, install the version that matches your `@nrwl/workspace` version.\n\n```sh\n# yarn\nyarn add --dev @nrwl/detox\n```\n\n```sh\n# npm\nnpm install --save-dev @nrwl/detox\n```\n\nNext, generate an E2E project based on an existing project.\n\n```sh\nnx g @nrwl/detox:app your-app-name-e2e --project=your-app-name\n```\n\nReplace `your-app-name` with the app's name as defined in your `workspace.json` file.\n\nIn addition, you need to follow [instructions at Detox](https://github.com/wix/Detox/blob/master/docs/Introduction.Android.md) to do manual setup for Android files.\n\n## Using Detox\n\n### Testing Applications\n\n- Run `nx test-ios frontend-e2e` to build the iOS app and execute e2e tests with Detox for iOS (Mac only)\n- Run `nx test-android frontend-e2e` to build the Android app and execute e2e tests with Detox for Android\n\nYou can run below commands:\n\n- `nx build-ios frontend-e2e`: build the iOS app (Mac only)\n- `nx build-android frontend-e2e`: build the Android app\n\n### Testing against Prod Build\n\nYou can run your e2e test against a production build:\n\n- `nx test-ios frontend-e2e --prod`: to build the iOS app and execute e2e tests with Detox for iOS with Release configuration (Mac only)\n- `nx test-android frontend-e2e`: rto build the Android app and execute e2e tests with Detox for Android with release build type\n- `nx build-ios frontend-e2e --prod`: build the iOS app using Release configuration (Mac only)\n- `nx build-android frontend-e2e --prod`: build the Android app using release build type\n\n## Configuration\n\n### Using .detoxrc.json\n\nIf you need to fine tune your Detox setup, you can do so by modifying `.detoxrc.json` in the e2e project.\n\n#### Change Testing Simulator/Emulator\n\nFor iOS, in terminal, run `xcrun simctl list` to view a list of simulators on your Mac. To open your active simulator, `run open -a simulator`. In `frontend-e2e/.detoxrc.json`, you could change the simulator under `devices.simulator.device`.\n\nFor Android, in terminal, run `emulator -list-avds` to view a list of emulators installed. To open your emulator, run `emulator -avd `. In `frontend-e2e/.detoxrc.json`, you could change the simulator under `devices.emulator.device`.\n\nIn additon, to override the device name specified in a configuration, you could use `--device-name` option: `nx test-ios --device-name \"iPhone 11\"`. The `device-name` property provides you the ability to test an application run on specific device.\n\n```bash\nnx test-ios frontend-e2e --device-name \"iPhone 11\"\nnx test-android frontend-e2e --device-name \"Pixel_4a_API_30\"\n```\n" + "content": "![Detox logo](/shared/detox-logo.png)\n\nDetox is gray box end-to-end testing and automation library for mobile apps. It has a lot of great features:\n\n- Cross Platform\n- Runs on Devices\n- Automatically Synchronized\n- Test Runner Independent\n- Debuggable\n\n## Setting Up Detox\n\n### Install applesimutils (Mac only)\n\n[applesimutils](https://github.com/wix/AppleSimulatorUtils) is a collection of utils for Apple simulators.\n\n```sh\nbrew tap wix/brew\nbrew install applesimutils\n```\n\n### Install Jest Globally\n\n```sh\nnpm install -g jest\n```\n\n### Generating Applications\n\nBy default, when creating a mobile application, Nx will use Detox to create the e2e tests project.\n\n```bash\nnx g @nrwl/react-native:app frontend\n```\n\n### Creating a Detox E2E project for an existing project\n\nYou can create a new Detox E2E project for an existing mobile project.\n\nIf the `@nrwl/detox` package is not installed, install the version that matches your `@nrwl/workspace` version.\n\n```sh\n# yarn\nyarn add --dev @nrwl/detox\n```\n\n```sh\n# npm\nnpm install --save-dev @nrwl/detox\n```\n\nNext, generate an E2E project based on an existing project.\n\n```sh\nnx g @nrwl/detox:app your-app-name-e2e --project=your-app-name\n```\n\nReplace `your-app-name` with the app's name as defined in your `tsconfig.base.json` file or the `name` property of your `package.json`.\n\nIn addition, you need to follow [instructions at Detox](https://github.com/wix/Detox/blob/master/docs/Introduction.Android.md) to do manual setup for Android files.\n\n## Using Detox\n\n### Testing Applications\n\n- Run `nx test-ios frontend-e2e` to build the iOS app and execute e2e tests with Detox for iOS (Mac only)\n- Run `nx test-android frontend-e2e` to build the Android app and execute e2e tests with Detox for Android\n\nYou can run below commands:\n\n- `nx build-ios frontend-e2e`: build the iOS app (Mac only)\n- `nx build-android frontend-e2e`: build the Android app\n\n### Testing against Prod Build\n\nYou can run your e2e test against a production build:\n\n- `nx test-ios frontend-e2e --prod`: to build the iOS app and execute e2e tests with Detox for iOS with Release configuration (Mac only)\n- `nx test-android frontend-e2e`: rto build the Android app and execute e2e tests with Detox for Android with release build type\n- `nx build-ios frontend-e2e --prod`: build the iOS app using Release configuration (Mac only)\n- `nx build-android frontend-e2e --prod`: build the Android app using release build type\n\n## Configuration\n\n### Using .detoxrc.json\n\nIf you need to fine tune your Detox setup, you can do so by modifying `.detoxrc.json` in the e2e project.\n\n#### Change Testing Simulator/Emulator\n\nFor iOS, in terminal, run `xcrun simctl list` to view a list of simulators on your Mac. To open your active simulator, `run open -a simulator`. In `frontend-e2e/.detoxrc.json`, you could change the simulator under `devices.simulator.device`.\n\nFor Android, in terminal, run `emulator -list-avds` to view a list of emulators installed. To open your emulator, run `emulator -avd `. In `frontend-e2e/.detoxrc.json`, you could change the simulator under `devices.emulator.device`.\n\nIn additon, to override the device name specified in a configuration, you could use `--device-name` option: `nx test-ios --device-name \"iPhone 11\"`. The `device-name` property provides you the ability to test an application run on specific device.\n\n```bash\nnx test-ios frontend-e2e --device-name \"iPhone 11\"\nnx test-android frontend-e2e --device-name \"Pixel_4a_API_30\"\n```\n" } ], "generators": [ diff --git a/docs/generated/packages/nest.json b/docs/generated/packages/nest.json index 477c2ddcc8..babf89fa76 100644 --- a/docs/generated/packages/nest.json +++ b/docs/generated/packages/nest.json @@ -11,7 +11,7 @@ "name": "Overview", "path": "/packages/nest", "file": "shared/nest-plugin", - "content": "![NestJS logo](/shared/nest-logo.png)\n\nNest.js is a framework designed for building scalable server-side applications. In many ways, Nest is familiar to Angular developers:\n\n- It has excellent TypeScript support.\n- Its dependency injection system is similar to the one in Angular.\n- It emphasises testability.\n- Its configuration APIs are similar to Angular as well.\n\nMany conventions and best practices used in Angular applications can be also be used in Nest.\n\n## Setting Up Nest\n\nTo create a new workspace with Nest, run the following command:\n\n```shell\nnpx create-nx-workspace my-workspace --preset=nest\n```\n\nYarn users can use the following command instead:\n\n```shell\nyarn create nx-workspace my-workspace --preset=nest\n```\n\nTo add the Nest plugin to an existing workspace, run one the following commands:\n\n```shell\nnpm install -D @nrwl/nest\n```\n\n```shell\nyarn add -D @nrwl/nest\n```\n\n### Create Applications\n\nYou can add a new Nest application with the following command:\n\n```shell\nnx g @nrwl/nest:app my-nest-app\n```\n\n#### Application Proxies\n\nGenerating Nest applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for.\n\n```shell\nnx g @nrwl/nest:app my-nest-app --frontendProject my-angular-app\n```\n\n### Create Libraries\n\nYou can add a new Nest library with the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib\n```\n\nTo make the library `buildable`, use the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib --buildable\n```\n\nTo make the library `publishable`, use the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib --publishable --importPath=@my-workspace/my-nest-lib\n```\n\n> Read more about [building and publishing libraries here](/more-concepts/buildable-and-publishable-libraries).\n\n### Nest Generators\n\nThe Nest plugin for Nx extends the generators provided by Nest. Any commands that can be used with the Nest CLI can also be used with the `nx` command. The `--project` flag should be used for all Nest generators.\n\n> `--project` is used to infer the root of the project where the generators will generate the files.\n\n## Using Nest\n\n### Build\n\nYou can build an application with the following command:\n\n```shell\nnx build my-nest-app\n```\n\nThis applies to `buildable` libraries as well\n\n```shell\nnx build my-nest-lib\n```\n\n#### Waiting for other builds\n\nSetting the `waitUntilTargets` option with an array of projects (with the following format: `\"project:architect\"`) will execute those commands before serving the Nest application.\n\n### Serve\n\nYou can serve an application with the following command:\n\n```shell\nnx serve my-nest-app\n```\n\nThe `serve` command runs the `build` target, and executes the application.\n\nBy default, the serve command will run in `watch` mode. This allows code to be changed, and the Nest application to be rebuilt automatically.\n\n#### Debugging\n\nNest applications also have the `inspect` flag set, so you can attach your debugger to the running instance.\n\nDebugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port `.\n\nFor additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients).\n\n### Lint\n\nYou can lint an application with the following command:\n\n```shell\nnx lint my-nest-app\n```\n\nYou can lint a library with the following command:\n\n```shell\nnx lint my-nest-lib\n```\n\n### Unit Test\n\nYou can run unit test for an application with the following command:\n\n```shell\nnx test my-nest-app\n```\n\nYou can run unit test for a library with the following command:\n\n```shell\nnx test my-nest-lib\n```\n\n## More Documentation\n\n- [Todo Tutorial](/node-tutorial/01-create-application)\n- [Using Jest](/packages/jest)\n" + "content": "![NestJS logo](/shared/nest-logo.png)\n\nNest.js is a framework designed for building scalable server-side applications. In many ways, Nest is familiar to Angular developers:\n\n- It has excellent TypeScript support.\n- Its dependency injection system is similar to the one in Angular.\n- It emphasises testability.\n- Its configuration APIs are similar to Angular as well.\n\nMany conventions and best practices used in Angular applications can be also be used in Nest.\n\n## Setting Up Nest\n\nTo create a new workspace with Nest, run the following command:\n\n```shell\nnpx create-nx-workspace my-workspace --preset=nest\n```\n\nYarn users can use the following command instead:\n\n```shell\nyarn create nx-workspace my-workspace --preset=nest\n```\n\nTo add the Nest plugin to an existing workspace, run one the following commands:\n\n```shell\nnpm install -D @nrwl/nest\n```\n\n```shell\nyarn add -D @nrwl/nest\n```\n\n### Create Applications\n\nYou can add a new Nest application with the following command:\n\n```shell\nnx g @nrwl/nest:app my-nest-app\n```\n\n#### Application Proxies\n\nGenerating Nest applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for.\n\n```shell\nnx g @nrwl/nest:app my-nest-app --frontendProject my-angular-app\n```\n\n### Create Libraries\n\nYou can add a new Nest library with the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib\n```\n\nTo make the library `buildable`, use the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib --buildable\n```\n\nTo make the library `publishable`, use the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib --publishable --importPath=@my-workspace/my-nest-lib\n```\n\n> Read more about [building and publishing libraries here](/more-concepts/buildable-and-publishable-libraries).\n\n### Nest Generators\n\nThe Nest plugin for Nx extends the generators provided by Nest. Any commands that can be used with the Nest CLI can also be used with the `nx` command. The `--project` flag should be used for all Nest generators.\n\n> `--project` is used to infer the root of the project where the generators will generate the files.\n\n## Using Nest\n\n### Build\n\nYou can build an application with the following command:\n\n```shell\nnx build my-nest-app\n```\n\nThis applies to `buildable` libraries as well\n\n```shell\nnx build my-nest-lib\n```\n\n#### Waiting for other builds\n\nSetting the `waitUntilTargets` option with an array of projects (with the following format: `\"project:architect\"`) will execute those commands before serving the Nest application.\n\n### Serve\n\nYou can serve an application with the following command:\n\n```shell\nnx serve my-nest-app\n```\n\nThe `serve` command runs the `build` target, and executes the application.\n\nBy default, the serve command will run in `watch` mode. This allows code to be changed, and the Nest application to be rebuilt automatically.\n\n#### Debugging\n\nNest applications also have the `inspect` flag set, so you can attach your debugger to the running instance.\n\nDebugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` target in the `project.json`. Or by running the serve command with `--port `.\n\nFor additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients).\n\n### Lint\n\nYou can lint an application with the following command:\n\n```shell\nnx lint my-nest-app\n```\n\nYou can lint a library with the following command:\n\n```shell\nnx lint my-nest-lib\n```\n\n### Unit Test\n\nYou can run unit test for an application with the following command:\n\n```shell\nnx test my-nest-app\n```\n\nYou can run unit test for a library with the following command:\n\n```shell\nnx test my-nest-lib\n```\n\n## More Documentation\n\n- [Todo Tutorial](/node-tutorial/01-create-application)\n- [Using Jest](/packages/jest)\n" } ], "generators": [ diff --git a/docs/generated/packages/nx-plugin.json b/docs/generated/packages/nx-plugin.json index 1657908747..ecf64cf04f 100644 --- a/docs/generated/packages/nx-plugin.json +++ b/docs/generated/packages/nx-plugin.json @@ -11,7 +11,7 @@ "name": "Overview", "path": "/packages/nx-plugin", "file": "shared/nx-plugin", - "content": "Nx plugins are npm packages that contain generators and executors to extend a Nx workspace. Generators are blueprints to create new files from templates, and executors run those files. These plugins also update the `nx.json` when generating new libs or apps.\n\n> A list of plugins that is maintained by Nrwl is found in the [Nrwl/nx repo](https://github.com/nrwl/nx/tree/master/packages). \\\n> A list of custom plugins created by the community is found in the [Community](/community) section.\n> Plugins are written using Nx Devkit. **Read [Nx Devkit](/devkit/index) for more information.**\n\n{% youtube\nsrc=\"https://www.youtube.com/embed/fC1-4fAZDP4\"\ntitle=\"Nx Tutorial: Building Custom Plugins for Nx\"\nwidth=\"100%\" /%}\n\n## Generating a Plugin\n\nTo get started with building a Nx Plugin, run the following command:\n\n```bash\nnpx create-nx-plugin my-org --pluginName my-plugin\n```\n\nThis command creates a brand-new workspace, and sets up a pre-configured plugin with the specified name.\n\n> Note, the command above will create a plugin the package name set to `@my-org/my-plugin`. You can pass `--importPath` to provide a different package name.\n\n> If you do not want to create a new workspace, install the `@nrwl/nx-plugin` dependency in an already existing workspace with npm or yarn. Then run `nx g @nrwl/nx-plugin:plugin [pluginName]`.\n\nA new plugin is created with a default generator, executor, and e2e app.\n\n## Generator\n\nThe created generator contains boilerplate that will do the following:\n\n- Normalize a schema (the options that the generator accepts)\n- Update the `workspace.json`\n- Add the plugin's project to the `nx.json` file\n- Add files to the disk using templates\n\nThere will be an exported default function that will be the main entry for the generator.\n\n### Generator options\n\nThe `schema.d.ts` file contains all the options that the generator supports. By default, it includes `directory`, `tags`, and `name` as the options. If more options need to be added, please update this file and the `schema.json` file.\n\n{% callout type=\"note\" title=\"More details\" %}\nThe `schema.d.ts` file is used for type checking inside the implementation file. It should match the properties in `schema.json`.\n{% /callout %}\n\n### Adding more generators\n\nTo add more generators to the plugin, run the following command:\n`nx generate @nrwl/nx-plugin:generator [generatorName] --project=[pluginName]`.\n\nThis will scaffold out a new generator and update the necessary files to support it.\n\n### Generator Testing\n\nThe generator spec file includes boilerplate to help get started with testing. This includes setting up an empty workspace.\n\nThese tests should ensure that files within the tree (created with `createTreeWithEmptyWorkspace`) are in the correct place, and contain the right content.\n\nFull E2Es are supported (and recommended) and will run everything on the file system like a user would.\n\n## Executor\n\nThe default executor is set up to just emit a console log. Some examples of what an executor can do are:\n\n- Support different languages, (Java, Go, Python, C#)\n- Compile new UI framework components\n- Deploy an app on a CDN\n- Publish to NPM\n- and many more!\n\n### Adding more executors\n\nTo add more executors to the plugin, run the following command:\n`nx generate @nrwl/nx-plugin:executor [executor] --project=[pluginName]`.\n\nThis will scaffold out a new generator and update the necessary files to support it.\n\n### Executor testing\n\nThe executor spec file contains boilerplate to run the default exported function from the executor.\n\nThese tests should make sure that the executor is executing and calling the functions that it relies on.\n\nFull E2Es are supported (and recommended) and will run everything on the file system like a user would.\n\n## Testing your plugin\n\nOne of the biggest benefits that the Nx Plugin package provides is support for E2E and unit testing.\n\nWhen the E2E app runs, a temporary E2E directory is created in the root of the workspace. This directory is a blank Nx workspace, and will have the plugin's built package installed locally.\n\n### E2E Testing file\n\nWhen the plugin is generated, a test file is created in the `my-plugin-e2e` app. Inside this test file, there are already tests for making sure that the executor ran, checking if directories are created with the `--directory` option, and checking if tags are added to the project configuration.\n\nWe'll go over a few parts of a test file below:\n\n```typescript\nit('should create my-plugin', async (done) => {\n const plugin = uniq('my-plugin');\n ensureNxProject('@my-org/my-plugin', 'dist/packages/my-plugin');\n await runNxCommandAsync(`generate @my-org/my-plugin:myPlugin ${plugin}`);\n\n const result = await runNxCommandAsync(`build ${plugin}`);\n expect(result.stdout).toContain('Executor ran');\n\n done();\n});\n```\n\n- The `uniq` function creates a random name with the prefix and a random number.\n- The `ensureNxProject` is the function that will create the temporary directory. It takes two arguments, the plugin package name and the dist directory of when it's built.\n- The `runNxCommandAsync` will execute a `nx` command in the E2E directory.\n\nThere are additional functions that the `@nrwl/nx-plugin/testing` package exports. Most of them are file utilities to manipulate and read files in the E2E directory.\n\n## Including Assets\n\nSometimes you might want to include some assets with the plugin. This might be a image or some additional binaries.\n\nTo make sure that assets are copied to the dist folder, open the plugin's `project.json` file. Inside the `build` property, add additional assets. By default, all `.md` files in the root, all non-ts files in folders, and the `generators.json` and `executors.json` files are included.\n\n```json\n\"build\": {\n \"executor\": \"@nrwl/node:package\",\n \"options\": {\n // shortened...\n \"assets\": [\n \"packages/my-plugin/*.md\",\n {\n \"input\": \"./packages/my-plugin/src\",\n \"glob\": \"**/*.!(ts)\",\n \"output\": \"./src\"\n },\n {\n \"input\": \"./packages/my-plugin\",\n \"glob\": \"generators.json\",\n \"output\": \".\"\n },\n {\n \"input\": \"./packages/my-plugin\",\n \"glob\": \"executors.json\",\n \"output\": \".\"\n }\n ]\n }\n}\n```\n\n## Using your Nx Plugin\n\nTo use your plugin, simply list it in `nx.json` or use its generators and executors as you would for any other plugin. This could look like `nx g @my-org/my-plugin:lib` for generators or `\"executor\": \"@my-org/my-plugin:build\"` for executors. It should be usable in all of the same ways as published plugins in your local workspace immediately after generating it. This includes setting it up as the default collection in `nx.json`, which would allow you to run `nx g lib` and hit your plugin's generator.\n\n## Publishing your Nx Plugin\n\nIn order to use your plugin in other workspaces or share it with the community, you will need to publish it to an npm registry. To publish your plugin follow these steps:\n\n1. Build your plugin with the command `nx run my-plugin:build`\n1. `npm publish ./dist/package/my-plugin` and follow the prompts from npm.\n1. That's it!\n\n{% callout type=\"warning\" title=\"Version bump\" %}\nCurrently you will have to modify the `package.json` version by yourself or with a tool.\n{% /callout %}\n\nAfter that, you can then install your plugin like any other npm package,\n`npm i -D @my-org/my-plugin` or `yarn add -D @my-org/my-plugin`.\n\n### Listing your Nx Plugin\n\nNx provides a utility (`nx list`) that lists both core and community plugins. To submit your plugin, please follow the steps below:\n\n- Fork the [Nx repo](https://github.com/nrwl/nx/fork) (if you haven't already)\n- Update the [`community/approved-plugins.json` file](https://github.com/nrwl/nx/blob/master/community/approved-plugins.json) with a new entry for your plugin that includes name, url and description\n- Use the following commit message template: `chore(core): nx plugin submission [PLUGIN_NAME]`\n- push your changes, and run `yarn submit-plugin`\n\n> The `yarn submit-plugin` command automatically opens the Github pull request process with the correct template.\n\nWe will then verify the plugin, offer suggestions or merge the pull request!\n\n## Preset\n\nA Preset is a customization option which you provide when creating a new workspace. TS, Node, React are some internal presets that Nx provides by default.\n\n{% youtube\nsrc=\"https://www.youtube.com/embed/yGUrF0-uqaU\"\ntitle=\"Develop a Nx Preset for your Nx Plugin\"\nwidth=\"100%\" /%}\n\n### Custom Preset\n\nAt its core a preset is a generator, which we can create inside of a plugin.\nIf you **don't** have an existing plugin you can create one by running\n\n```bash\n npx create-nx-plugin my-org --pluginName my-plugin\n```\n\nTo create our preset inside of our plugin we can run\n\n```bash\n nx generate @nrwl/nx-plugin:generator --name=preset --project=happynrwl\n```\n\n{% callout type=\"warning\" title=\"Double check\" %}\nThe word `preset` is required for the name of this generator\n{% /callout %}\n\nYou should have a similar structure to this:\n\n```treeview\nhappynrwl/\n\t├── e2e\n\t├── jest.config.js\n\t├── jest.preset.js\n\t├── nx.json\n\t├── package-lock.json\n\t├── package.json\n\t├── packages\n\t│ └── happynrwl\n\t│ ├── src\n\t│ │ ├── executors\n\t│ │ ├── generators\n\t│ │ │ ├── happynrwl\n\t│ │ │ └── preset \t\t// <------------- Here\n\t│ │ └── index.ts\n\t├── tools\n\t├── tsconfig.base.json\n\t└── workspace.json\n```\n\nAfter the command is finished, the preset generator is created under the folder named **preset**.\nThe **generator.ts** provides an entry point to the generator. This file contains a function that is called to perform manipulations on a tree that represents the file system. The **schema.json** provides a description of the generator, available options, validation information, and default values.\n\nHere is the sample generator function which you can customize to meet your needs.\n\n```typescript\nexport default async function (tree: Tree, options: PresetGeneratorSchema) {\n const normalizedOptions = normalizeOptions(tree, options);\n addProjectConfiguration(tree, normalizedOptions.projectName, {\n root: normalizedOptions.projectRoot,\n projectType: 'application',\n sourceRoot: `${normalizedOptions.projectRoot}/src`,\n targets: {\n exec: {\n executor: 'nx:run-commands',\n options: {\n command: `node ${projectRoot}/src/index.js`,\n },\n },\n },\n tags: normalizedOptions.parsedTags,\n });\n addFiles(tree, normalizedOptions);\n await formatFiles(tree);\n}\n```\n\nTo get an in-depth guide on customizing/running or debugging your generator see [workspace generators](/recipe/workspace-generators#running-a-workspace-generator).\n\n#### Usage\n\nBefore you are able to use your newly created preset you must package and publish it to a registry.\n\nAfter you have published your plugin to a registry you can now use your preset when creating a new workspace\n\n```bash\nnpx create-nx-workspace my-workspace --preset=my-plugin-name\n```\n" + "content": "Nx plugins are npm packages that contain generators and executors to extend a Nx workspace. Generators are blueprints to create new files from templates, and executors run those files. These plugins also update the `nx.json` when generating new libs or apps.\n\n> A list of plugins that is maintained by Nrwl is found in the [Nrwl/nx repo](https://github.com/nrwl/nx/tree/master/packages). \\\n> A list of custom plugins created by the community is found in the [Community](/community) section.\n> Plugins are written using Nx Devkit. **Read [Nx Devkit](/devkit/index) for more information.**\n\n{% youtube\nsrc=\"https://www.youtube.com/embed/fC1-4fAZDP4\"\ntitle=\"Nx Tutorial: Building Custom Plugins for Nx\"\nwidth=\"100%\" /%}\n\n## Generating a Plugin\n\nTo get started with building a Nx Plugin, run the following command:\n\n```bash\nnpx create-nx-plugin my-org --pluginName my-plugin\n```\n\nThis command creates a brand-new workspace, and sets up a pre-configured plugin with the specified name.\n\n> Note, the command above will create a plugin the package name set to `@my-org/my-plugin`. You can pass `--importPath` to provide a different package name.\n\n> If you do not want to create a new workspace, install the `@nrwl/nx-plugin` dependency in an already existing workspace with npm or yarn. Then run `nx g @nrwl/nx-plugin:plugin [pluginName]`.\n\nA new plugin is created with a default generator, executor, and e2e app.\n\n## Generator\n\nThe created generator contains boilerplate that will do the following:\n\n- Normalize a schema (the options that the generator accepts)\n- Update the `project.json`\n- Add the plugin's project to the `nx.json` file\n- Add files to the disk using templates\n\nThere will be an exported default function that will be the main entry for the generator.\n\n### Generator options\n\nThe `schema.d.ts` file contains all the options that the generator supports. By default, it includes `directory`, `tags`, and `name` as the options. If more options need to be added, please update this file and the `schema.json` file.\n\n{% callout type=\"note\" title=\"More details\" %}\nThe `schema.d.ts` file is used for type checking inside the implementation file. It should match the properties in `schema.json`.\n{% /callout %}\n\n### Adding more generators\n\nTo add more generators to the plugin, run the following command:\n`nx generate @nrwl/nx-plugin:generator [generatorName] --project=[pluginName]`.\n\nThis will scaffold out a new generator and update the necessary files to support it.\n\n### Generator Testing\n\nThe generator spec file includes boilerplate to help get started with testing. This includes setting up an empty workspace.\n\nThese tests should ensure that files within the tree (created with `createTreeWithEmptyWorkspace`) are in the correct place, and contain the right content.\n\nFull E2Es are supported (and recommended) and will run everything on the file system like a user would.\n\n## Executor\n\nThe default executor is set up to just emit a console log. Some examples of what an executor can do are:\n\n- Support different languages, (Java, Go, Python, C#)\n- Compile new UI framework components\n- Deploy an app on a CDN\n- Publish to NPM\n- and many more!\n\n### Adding more executors\n\nTo add more executors to the plugin, run the following command:\n`nx generate @nrwl/nx-plugin:executor [executor] --project=[pluginName]`.\n\nThis will scaffold out a new generator and update the necessary files to support it.\n\n### Executor testing\n\nThe executor spec file contains boilerplate to run the default exported function from the executor.\n\nThese tests should make sure that the executor is executing and calling the functions that it relies on.\n\nFull E2Es are supported (and recommended) and will run everything on the file system like a user would.\n\n## Testing your plugin\n\nOne of the biggest benefits that the Nx Plugin package provides is support for E2E and unit testing.\n\nWhen the E2E app runs, a temporary E2E directory is created in the root of the workspace. This directory is a blank Nx workspace, and will have the plugin's built package installed locally.\n\n### E2E Testing file\n\nWhen the plugin is generated, a test file is created in the `my-plugin-e2e` app. Inside this test file, there are already tests for making sure that the executor ran, checking if directories are created with the `--directory` option, and checking if tags are added to the project configuration.\n\nWe'll go over a few parts of a test file below:\n\n```typescript\nit('should create my-plugin', async (done) => {\n const plugin = uniq('my-plugin');\n ensureNxProject('@my-org/my-plugin', 'dist/packages/my-plugin');\n await runNxCommandAsync(`generate @my-org/my-plugin:myPlugin ${plugin}`);\n\n const result = await runNxCommandAsync(`build ${plugin}`);\n expect(result.stdout).toContain('Executor ran');\n\n done();\n});\n```\n\n- The `uniq` function creates a random name with the prefix and a random number.\n- The `ensureNxProject` is the function that will create the temporary directory. It takes two arguments, the plugin package name and the dist directory of when it's built.\n- The `runNxCommandAsync` will execute a `nx` command in the E2E directory.\n\nThere are additional functions that the `@nrwl/nx-plugin/testing` package exports. Most of them are file utilities to manipulate and read files in the E2E directory.\n\n## Including Assets\n\nSometimes you might want to include some assets with the plugin. This might be a image or some additional binaries.\n\nTo make sure that assets are copied to the dist folder, open the plugin's `project.json` file. Inside the `build` property, add additional assets. By default, all `.md` files in the root, all non-ts files in folders, and the `generators.json` and `executors.json` files are included.\n\n```json\n\"build\": {\n \"executor\": \"@nrwl/node:package\",\n \"options\": {\n // shortened...\n \"assets\": [\n \"packages/my-plugin/*.md\",\n {\n \"input\": \"./packages/my-plugin/src\",\n \"glob\": \"**/*.!(ts)\",\n \"output\": \"./src\"\n },\n {\n \"input\": \"./packages/my-plugin\",\n \"glob\": \"generators.json\",\n \"output\": \".\"\n },\n {\n \"input\": \"./packages/my-plugin\",\n \"glob\": \"executors.json\",\n \"output\": \".\"\n }\n ]\n }\n}\n```\n\n## Using your Nx Plugin\n\nTo use your plugin, simply list it in `nx.json` or use its generators and executors as you would for any other plugin. This could look like `nx g @my-org/my-plugin:lib` for generators or `\"executor\": \"@my-org/my-plugin:build\"` for executors. It should be usable in all of the same ways as published plugins in your local workspace immediately after generating it. This includes setting it up as the default collection in `nx.json`, which would allow you to run `nx g lib` and hit your plugin's generator.\n\n## Publishing your Nx Plugin\n\nIn order to use your plugin in other workspaces or share it with the community, you will need to publish it to an npm registry. To publish your plugin follow these steps:\n\n1. Build your plugin with the command `nx run my-plugin:build`\n1. `npm publish ./dist/package/my-plugin` and follow the prompts from npm.\n1. That's it!\n\n{% callout type=\"warning\" title=\"Version bump\" %}\nCurrently you will have to modify the `package.json` version by yourself or with a tool.\n{% /callout %}\n\nAfter that, you can then install your plugin like any other npm package,\n`npm i -D @my-org/my-plugin` or `yarn add -D @my-org/my-plugin`.\n\n### Listing your Nx Plugin\n\nNx provides a utility (`nx list`) that lists both core and community plugins. To submit your plugin, please follow the steps below:\n\n- Fork the [Nx repo](https://github.com/nrwl/nx/fork) (if you haven't already)\n- Update the [`community/approved-plugins.json` file](https://github.com/nrwl/nx/blob/master/community/approved-plugins.json) with a new entry for your plugin that includes name, url and description\n- Use the following commit message template: `chore(core): nx plugin submission [PLUGIN_NAME]`\n- push your changes, and run `yarn submit-plugin`\n\n> The `yarn submit-plugin` command automatically opens the Github pull request process with the correct template.\n\nWe will then verify the plugin, offer suggestions or merge the pull request!\n\n## Preset\n\nA Preset is a customization option which you provide when creating a new workspace. TS, Node, React are some internal presets that Nx provides by default.\n\n{% youtube\nsrc=\"https://www.youtube.com/embed/yGUrF0-uqaU\"\ntitle=\"Develop a Nx Preset for your Nx Plugin\"\nwidth=\"100%\" /%}\n\n### Custom Preset\n\nAt its core a preset is a generator, which we can create inside of a plugin.\nIf you **don't** have an existing plugin you can create one by running\n\n```bash\n npx create-nx-plugin my-org --pluginName my-plugin\n```\n\nTo create our preset inside of our plugin we can run\n\n```bash\n nx generate @nrwl/nx-plugin:generator --name=preset --project=happynrwl\n```\n\n{% callout type=\"warning\" title=\"Double check\" %}\nThe word `preset` is required for the name of this generator\n{% /callout %}\n\nYou should have a similar structure to this:\n\n```treeview\nhappynrwl/\n\t├── e2e\n\t├── jest.config.js\n\t├── jest.preset.js\n\t├── nx.json\n\t├── package-lock.json\n\t├── package.json\n\t├── packages\n\t│ └── happynrwl\n\t│ ├── src\n\t│ │ ├── executors\n\t│ │ ├── generators\n\t│ │ │ ├── happynrwl\n\t│ │ │ └── preset \t\t// <------------- Here\n\t│ │ └── index.ts\n\t├── tools\n\t└── tsconfig.base.json\n```\n\nAfter the command is finished, the preset generator is created under the folder named **preset**.\nThe **generator.ts** provides an entry point to the generator. This file contains a function that is called to perform manipulations on a tree that represents the file system. The **schema.json** provides a description of the generator, available options, validation information, and default values.\n\nHere is the sample generator function which you can customize to meet your needs.\n\n```typescript\nexport default async function (tree: Tree, options: PresetGeneratorSchema) {\n const normalizedOptions = normalizeOptions(tree, options);\n addProjectConfiguration(tree, normalizedOptions.projectName, {\n root: normalizedOptions.projectRoot,\n projectType: 'application',\n sourceRoot: `${normalizedOptions.projectRoot}/src`,\n targets: {\n exec: {\n executor: 'nx:run-commands',\n options: {\n command: `node ${projectRoot}/src/index.js`,\n },\n },\n },\n tags: normalizedOptions.parsedTags,\n });\n addFiles(tree, normalizedOptions);\n await formatFiles(tree);\n}\n```\n\nTo get an in-depth guide on customizing/running or debugging your generator see [local generators](/recipe/local-generators).\n\n#### Usage\n\nBefore you are able to use your newly created preset you must package and publish it to a registry.\n\nAfter you have published your plugin to a registry you can now use your preset when creating a new workspace\n\n```bash\nnpx create-nx-workspace my-workspace --preset=my-plugin-name\n```\n" } ], "generators": [ diff --git a/docs/generated/packages/react-native.json b/docs/generated/packages/react-native.json index e3a359e387..dbeedf01ea 100644 --- a/docs/generated/packages/react-native.json +++ b/docs/generated/packages/react-native.json @@ -11,7 +11,7 @@ "name": "Overview", "path": "/packages/react-native", "file": "shared/react-native-plugin", - "content": "![React Logo](/shared/react-logo.png)\n\nReact Native brings React's declarative UI framework to iOS and Android. With React Native, you use native UI controls and have full access to the native platform.\n\nThe Nx Plugin for React Native contains generators for managing React Native applications and libraries within an Nx workspace. It provides:\n\n- Integration with libraries such as Jest, Detox, and Storybook.\n- Scaffolding for creating buildable libraries that can be published to npm.\n- Utilities for automatic workspace refactoring.\n\n## Setting Up React Native\n\n### Create a New Workspace\n\nThe easiest way to create your workspace is via `npx`.\n\n```bash\nnpx create-nx-workspace your-workspace-name \\\n--preset=react-native \\\n--appName=your-app-name\n```\n\n{% callout type=\"note\" title=\"Don't know what you need?\" %}\nYou can also run the command without arguments to go through the interactive prompts.\n{% /callout %}\n\n```bash\nnpx create-nx-workspace your-workspace-name\n```\n\n### Adding React Native to an Existing Workspace\n\nFor existing Nx workspaces, install the `@nrwl/react-native` package to add React Native capabilities to it.\n\n```bash\nnpm install @nrwl/react-native --save-dev\n\n# Or with yarn\nyarn add @nrwl/react-native --dev\n```\n\n### Generating Applications\n\nTo create additional React Native apps run:\n\n```bash\nnx g @nrwl/react-native:app your-app-name\n```\n\n### Generating Libraries\n\nTo generate a new library run:\n\n```bash\nnpx nx g @nrwl/react-native:lib your-lib-name\n```\n\n### Generating Components\n\nTo generate a new component inside library run:\n\n```bash\nnpx nx g @nrwl/react-native:component your-component-name --project=your-lib-name --export\n```\n\nReplace `your-lib-name` with the app's name as defined in your workspace.json file.\n\n## Using React Native\n\n- [run-ios](/packages/react-native/executors/run-ios) - Builds your app and starts it on iOS simulator or device\n- [run-android](/packages/react-native/executors/run-android) - Builds your app and starts it on a connected Android emulator or device\n- [build-android](/packages/react-native/executors/build-android) - Release Build for Android\n- [start](/packages/react-native/executors/start) - Starts the server that communicates with connected devices\n- [bundle](/packages/react-native/executors/bundle) - Builds the JavaScript bundle for offline use\n- [sync-deps](/packages/react-native/executors/sync-deps) - Syncs dependencies to package.json (required for autolinking)\n- [ensure-symlink](/packages/react-native/executors/ensure-symlink) - Ensure workspace node_modules is symlink under app's node_modules folder\n\n## More Documentation\n\n- [Using Detox](/packages/detox)\n- [Using Jest](/packages/jest)\n" + "content": "![React Logo](/shared/react-logo.png)\n\nReact Native brings React's declarative UI framework to iOS and Android. With React Native, you use native UI controls and have full access to the native platform.\n\nThe Nx Plugin for React Native contains generators for managing React Native applications and libraries within an Nx workspace. It provides:\n\n- Integration with libraries such as Jest, Detox, and Storybook.\n- Scaffolding for creating buildable libraries that can be published to npm.\n- Utilities for automatic workspace refactoring.\n\n## Setting Up React Native\n\n### Create a New Workspace\n\nThe easiest way to create your workspace is via `npx`.\n\n```bash\nnpx create-nx-workspace your-workspace-name \\\n--preset=react-native \\\n--appName=your-app-name\n```\n\n{% callout type=\"note\" title=\"Don't know what you need?\" %}\nYou can also run the command without arguments to go through the interactive prompts.\n{% /callout %}\n\n```bash\nnpx create-nx-workspace your-workspace-name\n```\n\n### Adding React Native to an Existing Workspace\n\nFor existing Nx workspaces, install the `@nrwl/react-native` package to add React Native capabilities to it.\n\n```bash\nnpm install @nrwl/react-native --save-dev\n\n# Or with yarn\nyarn add @nrwl/react-native --dev\n```\n\n### Generating Applications\n\nTo create additional React Native apps run:\n\n```bash\nnx g @nrwl/react-native:app your-app-name\n```\n\n### Generating Libraries\n\nTo generate a new library run:\n\n```bash\nnpx nx g @nrwl/react-native:lib your-lib-name\n```\n\n### Generating Components\n\nTo generate a new component inside library run:\n\n```bash\nnpx nx g @nrwl/react-native:component your-component-name --project=your-lib-name --export\n```\n\nReplace `your-lib-name` with the app's name as defined in your `tsconfig.base.json` file or the `name` property of your `package.json`\n\n## Using React Native\n\n- [run-ios](/packages/react-native/executors/run-ios) - Builds your app and starts it on iOS simulator or device\n- [run-android](/packages/react-native/executors/run-android) - Builds your app and starts it on a connected Android emulator or device\n- [build-android](/packages/react-native/executors/build-android) - Release Build for Android\n- [start](/packages/react-native/executors/start) - Starts the server that communicates with connected devices\n- [bundle](/packages/react-native/executors/bundle) - Builds the JavaScript bundle for offline use\n- [sync-deps](/packages/react-native/executors/sync-deps) - Syncs dependencies to package.json (required for autolinking)\n- [ensure-symlink](/packages/react-native/executors/ensure-symlink) - Ensure workspace node_modules is symlink under app's node_modules folder\n\n## More Documentation\n\n- [Using Detox](/packages/detox)\n- [Using Jest](/packages/jest)\n" } ], "generators": [ diff --git a/docs/generated/packages/workspace.json b/docs/generated/packages/workspace.json index a61a8e6ba9..faf8afbdcd 100644 --- a/docs/generated/packages/workspace.json +++ b/docs/generated/packages/workspace.json @@ -11,7 +11,7 @@ "id": "overview", "path": "/packages/workspace", "file": "shared/workspace-plugin", - "content": "The workspace plugin contains executors and generators that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it.\n\n## Creating Workspace Generators\n\nCodifying your organization's best practices into workspace generators is a great way to ensure that the best practices are easy to follow and implement. Running `nx g @nrwl/workspace:workspace-generator feature` will create a workspace generator which is written the same way generators are written for Nx plugins. The workspace generator can then be run with `nx workspace-generator feature`.\n\n> See more about [workspace generators](/recipe/workspace-generators)\n\n## Reorganizing Projects\n\nAfter some time of working within a workspace, projects might need to be moved or sometimes even removed.\nThe workspace plugin provides the [`@nrwl/workspace:move`](/packages/workspace/generators/move) and [`@nrwl/workspace:remove`](/packages/workspace/generators/remove) generators to help aid with this.\n\n### Moving Projects\n\nRunning `nx g @nrwl/workspace:move --projectName my-lib --destination new/location/my-lib` will move the `my-lib` library to `libs/new/location/my-lib`.\n\nMoving the files manually can be done easily but a lot of steps are often missed when projects are moved. This generator will also handle the following:\n\n1. The project's files will be moved\n2. The project will be renamed to `new-location-my-lib`\n3. The path mapping in `tsconfig.base.json` will be changed to `@npmScope/new/location/my-lib`\n4. Imports in other projects will be changed to `@npmScope/new/location/my-lib`\n5. Paths in target options such as output path will be changed\n6. 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`\n\n> See more about [`@nrwl/workspace:move`](/packages/workspace/generators/move)\n\n### Removing Projects\n\nRunning `nx g @nrwl/workspace:remove my-lib` will remove the `my-lib` from the workspace. It is important to note that sometimes, projects cannot be removed if they are still depended on by other projects.\n\nLike when moving projects, some steps are often missed when removing projects. This generator will also handle the following:\n\n1. Checks if other projects depend on the project being removed. This can be ignored via the `--forceRemove` flag.\n2. The project's files will be deleted.\n3. The project's configuration will be removed.\n4. The path mapping in `tsconfig.base.json` will be removed.\n\n> See more about [`@nrwl/workspace:remove`](/packages/workspace/generators/remove)\n\n## Running custom commands\n\nExecutors provide an optimized way of running targets but unfortunately, not every target has an executor written for it. The [`nx:run-commands`](/packages/nx/executors/run-commands) executor is an executor that runs any command or multiple commands in the shell. This can be useful when integrating with other tools which do not have an executor provided. There is also a generator to help configure this executor.\n\nRunning `nx g @nrwl/workspace:run-commands printhello --project my-feature-lib --command 'echo hello'` will create a `my-feature-lib:printhello` target that executes `echo hello` in the shell.\n\n> See more about [`nx:run-commands`](/packages/nx/executors/run-commands)\n" + "content": "The workspace plugin contains executors and generators that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it.\n\n## Creating Local Generators\n\nCodifying your organization's best practices into local generators is a great way to ensure that the best practices are easy to follow and implement. Running `nx g @nrwl/nx-plugin:plugin feature` will create a local plugin with a generator which is written the same way generators are written for Nx plugins.\n\n> See more about [local generators](/recipe/local-generators)\n\n## Reorganizing Projects\n\nAfter some time of working within a workspace, projects might need to be moved or sometimes even removed.\nThe workspace plugin provides the [`@nrwl/workspace:move`](/packages/workspace/generators/move) and [`@nrwl/workspace:remove`](/packages/workspace/generators/remove) generators to help aid with this.\n\n### Moving Projects\n\nRunning `nx g @nrwl/workspace:move --projectName my-lib --destination new/location/my-lib` will move the `my-lib` library to `libs/new/location/my-lib`.\n\nMoving the files manually can be done easily but a lot of steps are often missed when projects are moved. This generator will also handle the following:\n\n1. The project's files will be moved\n2. The project will be renamed to `new-location-my-lib`\n3. The path mapping in `tsconfig.base.json` will be changed to `@npmScope/new/location/my-lib`\n4. Imports in other projects will be changed to `@npmScope/new/location/my-lib`\n5. Paths in target options such as output path will be changed\n6. 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`\n\n> See more about [`@nrwl/workspace:move`](/packages/workspace/generators/move)\n\n### Removing Projects\n\nRunning `nx g @nrwl/workspace:remove my-lib` will remove the `my-lib` from the workspace. It is important to note that sometimes, projects cannot be removed if they are still depended on by other projects.\n\nLike when moving projects, some steps are often missed when removing projects. This generator will also handle the following:\n\n1. Checks if other projects depend on the project being removed. This can be ignored via the `--forceRemove` flag.\n2. The project's files will be deleted.\n3. The project's configuration will be removed.\n4. The path mapping in `tsconfig.base.json` will be removed.\n\n> See more about [`@nrwl/workspace:remove`](/packages/workspace/generators/remove)\n\n## Running custom commands\n\nExecutors provide an optimized way of running targets but unfortunately, not every target has an executor written for it. The [`nx:run-commands`](/packages/nx/executors/run-commands) executor is an executor that runs any command or multiple commands in the shell. This can be useful when integrating with other tools which do not have an executor provided. There is also a generator to help configure this executor.\n\nRunning `nx g @nrwl/workspace:run-commands printhello --project my-feature-lib --command 'echo hello'` will create a `my-feature-lib:printhello` target that executes `echo hello` in the shell.\n\n> See more about [`nx:run-commands`](/packages/nx/executors/run-commands)\n" }, { "name": "Nx, NodeJS and Typescript Versions", diff --git a/docs/map.json b/docs/map.json index e7ba9b0250..483348e106 100644 --- a/docs/map.json +++ b/docs/map.json @@ -613,10 +613,10 @@ "file": "shared/recipes/use-executor-configurations" }, { - "name": "Creating Custom Executors", + "name": "Local Executors", "id": "creating-custom-executors", "tags": ["use-task-executors"], - "file": "shared/tools-workspace-builders" + "file": "shared/recipes/local-executors" }, { "name": "Compose Executors", @@ -625,10 +625,10 @@ "file": "shared/recipes/compose-executors" }, { - "name": "Workspace Generators", - "id": "workspace-generators", + "name": "Local Generators", + "id": "local-generators", "tags": ["use-code-generators"], - "file": "shared/generators/workspace-generators" + "file": "shared/recipes/local-generators" }, { "name": "Composing Generators", @@ -885,6 +885,38 @@ "isExternal": true } ] + }, + { + "name": "Deprecated", + "id": "deprecated", + "description": "Functionality that has been superseded in the current version of Nx. Listed here for those running older versions.", + "itemList": [ + { + "name": "workspace.json", + "id": "workspace-json", + "file": "shared/deprecated/workspace-json" + }, + { + "name": "Workspace Generators", + "id": "workspace-generators", + "file": "shared/deprecated/workspace-generators" + }, + { + "name": "Workspace Executors", + "id": "workspace-executors", + "file": "shared/deprecated/workspace-executors" + }, + { + "name": "defaultCollection", + "id": "default-collection", + "file": "shared/deprecated/default-collection" + }, + { + "name": "runtimeCacheInputs", + "id": "runtime-cache-inputs", + "file": "shared/deprecated/runtime-cache-inputs" + } + ] } ] }, diff --git a/docs/shared/cypress-plugin.md b/docs/shared/cypress-plugin.md index 638afa170f..207e1200ce 100644 --- a/docs/shared/cypress-plugin.md +++ b/docs/shared/cypress-plugin.md @@ -45,7 +45,7 @@ Optionally, you can use the `--baseUrl` option if you don't want cypress plugin nx g @nrwl/cypress:cypress-project your-app-name-e2e --baseUrl=http://localhost:4200 ``` -Replace `your-app-name` with the app's name as defined in your `workspace.json` file. +Replace `your-app-name` with the app's name as defined in your `tsconfig.base.json` file or the `name` property of your `package.json`. ### Testing Applications diff --git a/docs/shared/deprecated/default-collection.md b/docs/shared/deprecated/default-collection.md new file mode 100644 index 0000000000..7b89432e58 --- /dev/null +++ b/docs/shared/deprecated/default-collection.md @@ -0,0 +1,40 @@ +# defaultCollection + +In the `nx.json` you can set a `defaultCollection` property like this: + +```jsonc +{ + "cli": { + "defaultCollection": "@nrwl/next" + } +} +``` + +This would cause the following command + +```bash +nx g library my-lib +``` + +To create a `@nrwl/next:library` library instead of some other generator with the name `library`. + +This property is no longer needed because the Nx cli automatically will prompt you to choose between the available options if there is any ambiguity. The output looks like this: + +```bash +> nx g lib my-lib +? Which generator would you like to use? … +@nrwl/react-native:library +@nrwl/angular:library +@nrwl/expo:library +@nrwl/nest:library +@nrwl/node:library + +@nestjs/schematics:library +@schematics/angular:library +@nrwl/js:library +@nrwl/next:library +@nrwl/react:library +@nrwl/workspace:library + +None of the above +``` diff --git a/docs/shared/deprecated/runtime-cache-inputs.md b/docs/shared/deprecated/runtime-cache-inputs.md new file mode 100644 index 0000000000..c205f23b52 --- /dev/null +++ b/docs/shared/deprecated/runtime-cache-inputs.md @@ -0,0 +1,34 @@ +# runtimeCacheInputs + +The `runtimeCacheInputs` property was used as a way to add extra inputs to the Nx cache, like the version of node on that particular machine. + +`runtimeCacheInputs` were set as follows: + +```json +{ + "tasksRunnerOptions": { + "default": { + "runner": "nx/tasks-runners/default", + "options": { + "cacheableOperations": ["build", "lint", "test", "e2e"], + "runtimeCacheInputs": ["node -v"] + } + } + } +} +``` + +Instead of specifying the runtime inputs in `tasksRunnerOptions`, you can now include them as runtime inputs in the standard [`inputs` and `namedInputs` area of your project configuration](/reference/project-configuration#inputs-&-namedinputs) or [`nx.json`](/reference/nx-json#inputs-&-namedinputs). + +The new style looks like this: + +```jsonc +{ + "targets": { + "build": { + "inputs": ["^build", { "runtime": "node -v" }] + // ... + } + } +} +``` diff --git a/docs/shared/deprecated/workspace-executors.md b/docs/shared/deprecated/workspace-executors.md new file mode 100644 index 0000000000..a913bd4df7 --- /dev/null +++ b/docs/shared/deprecated/workspace-executors.md @@ -0,0 +1,29 @@ +# Workspace Executors + +In Nx 13.10+, local nx plugins can contain executors that are used in the workspace. When creating a custom executor for your workspace, look into the [nx-plugin guide](/packages/nx-plugin) to simplify the build process. + +## Converting workspace executors to local executors + +- If you don't already have a local plugin, use Nx to generate one: + +```bash +# replace `latest` with the version that matches your Nx version +npm install @nrwl/nx-plugin@latest +nx g @nrwl/nx-plugin:plugin my-plugin +``` + +- Use the Nx CLI to generate the initial files needed for your executor. Replace `my-executor` with the name of your workspace executor. + +```bash +nx generate @nrwl/nx-plugin:executor my-executor --project=my-plugin +``` + +- Copy the code for your workspace executor into the newly created executor's folder. e.g. `libs/my-plugin/src/executors/my-executor/` + +- Now you can reference the executor like this: + +```jsonc +{ + "executor": "@my-org/my-plugin:my-executor" +} +``` diff --git a/docs/shared/deprecated/workspace-generators.md b/docs/shared/deprecated/workspace-generators.md new file mode 100644 index 0000000000..061e4fa90e --- /dev/null +++ b/docs/shared/deprecated/workspace-generators.md @@ -0,0 +1,31 @@ +# Workspace Generators + +In Nx 13.10, we introduced the ability to run generators from Nx plugins in the workspace they were created in. + +By using a "local" plugin, you can set the plugin as your workspace's default collection and get several other affordances that are not provided to workspace generators. This is the preferred method for "workspace generators", and existing generators will eventually be transitioned to use a local plugin. + +Check the [nx-plugin guide](/packages/nx-plugin) for information on creating a new plugin. + +## Converting workspace generators to local generators + +- If you don't already have a local plugin, use Nx to generate one: + +```bash +# replace `latest` with the version that matches your Nx version +npm install @nrwl/nx-plugin@latest +nx g @nrwl/nx-plugin:plugin my-plugin +``` + +- Use the Nx CLI to generate the initial files needed for your generator. Replace `my-generator` with the name of your workspace generator. + +```bash +nx generate @nrwl/nx-plugin:generator my-generator --project=my-plugin +``` + +- Copy the code for your workspace generator into the newly created generator's folder. e.g. `libs/my-plugin/src/generators/my-generator/` + +- Now you can run the generator like this: + +```bash +nx g my-generator +``` diff --git a/docs/shared/deprecated/workspace-json.md b/docs/shared/deprecated/workspace-json.md new file mode 100644 index 0000000000..0efbaf142a --- /dev/null +++ b/docs/shared/deprecated/workspace-json.md @@ -0,0 +1,36 @@ +# workspace.json + +Nx used to have a `workspace.json` file at the root of the repo that at various points performed these functions: + +1. Identified the locations of all project in the repo +2. Contained the target configuration for all projects + +Identifying the locations of projects is now done automatically through project inference. You can even customize how projects are inferred with a [project inference plugin](/recipe/project-inference-plugins). + +The target configuration for each project is now stored in individual `project.json` files or `package.json` files. + +## Removing workspace.json + +To remove `workspace.json` in favor of `project.json` files, run: + +```bash +nx g @nrwl/workspace:convert-to-nx-project --all +``` + +See [convert-to-nx-project](/packages/workspace/generators/convert-to-nx-project) for more options. + +After this command, `workspace.json` should look like this: + +```jsonc +{ + "version": 2, + "projects": { + "my-app": "apps/my-app", + "some-lib": "libs/some-lib" + // ... + }, + "$schema": "./node_modules/nx/schemas/workspace-schema.json" +} +``` + +If every project is listed as a string, instead of an object with project configuration properties, then it is safe to delete the `workspace.json` file. diff --git a/docs/shared/detox-plugin.md b/docs/shared/detox-plugin.md index ec2ba5e4a9..fa7b6399c3 100644 --- a/docs/shared/detox-plugin.md +++ b/docs/shared/detox-plugin.md @@ -55,7 +55,7 @@ Next, generate an E2E project based on an existing project. nx g @nrwl/detox:app your-app-name-e2e --project=your-app-name ``` -Replace `your-app-name` with the app's name as defined in your `workspace.json` file. +Replace `your-app-name` with the app's name as defined in your `tsconfig.base.json` file or the `name` property of your `package.json`. In addition, you need to follow [instructions at Detox](https://github.com/wix/Detox/blob/master/docs/Introduction.Android.md) to do manual setup for Android files. diff --git a/docs/shared/extending-nx/project-graph-plugins.md b/docs/shared/extending-nx/project-graph-plugins.md index 6b7b605d0f..0c19a1dc15 100644 --- a/docs/shared/extending-nx/project-graph-plugins.md +++ b/docs/shared/extending-nx/project-graph-plugins.md @@ -80,7 +80,7 @@ You can designate any type for the node. This differentiates third party project ## Adding New Dependencies to the Project Graph -It's more common for plugins to create new dependencies. First-party code contained in the workspace is registered in `workspace.json` and is added to the project graph automatically. Whether your project contains TypeScript or say Java, both projects will be created in the same way. However, Nx does not know how to analyze Java sources, and that's what plugins can do. +It's more common for plugins to create new dependencies. First-party code contained in the workspace is added to the project graph automatically. Whether your project contains TypeScript or say Java, both projects will be created in the same way. However, Nx does not know how to analyze Java sources, and that's what plugins can do. You can create 2 types of dependencies. diff --git a/docs/shared/extending-nx/project-inference-plugins.md b/docs/shared/extending-nx/project-inference-plugins.md index 371f6f6c38..0db2828213 100644 --- a/docs/shared/extending-nx/project-inference-plugins.md +++ b/docs/shared/extending-nx/project-inference-plugins.md @@ -4,9 +4,9 @@ This API is experimental and might change. {% /callout %} -Project inference describes the ability of Nx to discover and work with projects based on source code and configuration files in your repo. +Project inference describes the ability of Nx to discover and work with projects based on source code and configuration files in your repo. Out of the box, Nx identifies projects based on the presence of `package.json` and `project.json` files. It also identifies targets in the `package.json` scripts and the `project.json` `target`s. -One of the best examples of this in Nx is that `package.json` scripts are automatically inferred as targets for your workspace. If using nx core, without `workspace.json`, `nx` can also infer projects defined in your `package.json` workspace are inferred as Nx projects. +Project inference plugins allow you to extend this functionality of Nx to other languages and file structures. ## Adding Plugins to Workspace @@ -25,7 +25,7 @@ You can register a plugin by adding it to the plugins array in `nx.json`: Project file patterns are used in two scenarios: -- Inferring projects when `workspace.json` is not present +- Inferring projects - Determining which files should be passed into `registerProjectTargets`. Let's use the below plugin and workspace layout as an example: @@ -55,9 +55,7 @@ my-workspace/ ``` -During initialization, we would expect to see "libs/my-project/my-other-project-file", "libs/nx-project/my-other-project-file", "libs/nx-project/project.json" all logged out to the console. Since `workspace.json` is not present, Nx was able to infer `my-project` from the layout. - -If `workspace.json` was present, `my-project` wouldn't be able to be inferred, since full project inference requires `workspace.json` to be absent. +During initialization, we would expect to see "libs/my-project/my-other-project-file", "libs/nx-project/my-other-project-file", "libs/nx-project/project.json" all logged out to the console. Nx was able to infer `my-project` from the layout. ## Implementing a Project Target Configurator diff --git a/docs/shared/generators/creating-files.md b/docs/shared/generators/creating-files.md index c18bfdde56..afafb79b22 100644 --- a/docs/shared/generators/creating-files.md +++ b/docs/shared/generators/creating-files.md @@ -68,7 +68,7 @@ Use the `-d` or `--dry-run` flag to see your changes without applying them. This {% /callout %} ```bash -nx workspace-generator my-generator mylib +nx generate my-generator mylib ``` The following information will be displayed. @@ -82,7 +82,6 @@ CREATE libs/mylib/src/lib/mylib.ts CREATE libs/mylib/tsconfig.json CREATE libs/mylib/tsconfig.lib.json UPDATE tsconfig.base.json -UPDATE workspace.json UPDATE nx.json CREATE libs/mylib/.eslintrc.json CREATE libs/mylib/jest.config.ts diff --git a/docs/shared/guides/integrated-repo-folder-structure.md b/docs/shared/guides/integrated-repo-folder-structure.md index 0474093c03..a431ddede8 100644 --- a/docs/shared/guides/integrated-repo-folder-structure.md +++ b/docs/shared/guides/integrated-repo-folder-structure.md @@ -7,7 +7,6 @@ myorg/ ├── apps/ ├── libs/ ├── tools/ -├── workspace.json ├── nx.json ├── package.json └── tsconfig.base.json @@ -17,9 +16,7 @@ myorg/ `/libs/` contains the library projects. There are many kinds of libraries, and each library defines its own external API so that boundaries between libraries remain clear. -`/tools/` contains scripts that act on your code base. This could be database scripts, [custom executors](/recipe/creating-custom-executors), or [workspace generators](/recipe/workspace-generators). - -`/workspace.json` lists every project in your workspace. (this file is optional) +`/tools/` contains scripts that act on your code base. This could be database scripts, [local executors](/recipe/creating-custom-executors), or [local generators](/recipe/local-generators). `/nx.json` configures the Nx CLI itself. It tells Nx what needs to be cached, how to run tasks etc. diff --git a/docs/shared/guides/nx-and-angular-cli.md b/docs/shared/guides/nx-and-angular-cli.md index 432b570ef8..e13a744da8 100644 --- a/docs/shared/guides/nx-and-angular-cli.md +++ b/docs/shared/guides/nx-and-angular-cli.md @@ -26,7 +26,7 @@ What we recommend instead is to split `angular.json` into multiple `project.json - Run `nx generate @nrwl/workspace:convert-to-nx-project --all=true` {% callout type="check" title="Nx and AngularCLI are compatible" %} -But regardless of whether you use `angular.json` or `project.json`, the configuration remains the same. So anything written about `project.json` or `workspace.json` applies to `angular.json` in the same way. For instance, everything in [project.json](/reference/project-configuration) and [nx.json](/reference/nx-json) applies to `angular.json` in the same way. +But regardless of whether you use `angular.json` or `project.json`, the configuration remains the same. So anything written about `project.json` applies to `angular.json` in the same way. For instance, everything in [project.json](/reference/project-configuration) and [nx.json](/reference/nx-json) applies to `angular.json` in the same way. {% /callout %} Note that even though the configuration is split, everything works the same way. All migrations and schematics that expect a single `angular.json` file, will receive a single file. Nx is smart, so it merges all the files in memory to make those migrations and schematics work. diff --git a/docs/shared/guides/react-native.md b/docs/shared/guides/react-native.md index 60e6f0eec8..d615061347 100644 --- a/docs/shared/guides/react-native.md +++ b/docs/shared/guides/react-native.md @@ -75,8 +75,7 @@ happynrwl/ ├── nx.json ├── package-lock.json ├── package.json -├── tsconfig.base.json -└── workspace.json +└── tsconfig.base.json ``` To run the application in development mode: @@ -190,8 +189,7 @@ happynrwl/ ├── nx.json ├── package-lock.json ├── package.json -├── tsconfig.base.json -└── workspace.json +└── tsconfig.base.json ``` Run: diff --git a/docs/shared/guides/using-tailwind-css-with-angular-projects.md b/docs/shared/guides/using-tailwind-css-with-angular-projects.md index f8ab5280dc..a0c4e4fb78 100644 --- a/docs/shared/guides/using-tailwind-css-with-angular-projects.md +++ b/docs/shared/guides/using-tailwind-css-with-angular-projects.md @@ -156,7 +156,7 @@ Add the project configuration for the project: If using the workspace configuration v2: ```json -// angular.json or workspace.json +// angular.json or project.json { "version": 2, "projects": { @@ -288,7 +288,7 @@ Add the project configuration for the project: If using the workspace configuration v2: ```json -// angular.json or workspace.json +// angular.json or project.json { "version": 2, "projects": { diff --git a/docs/shared/migration/manual.md b/docs/shared/migration/manual.md index 23e436a176..72a41ce3ab 100644 --- a/docs/shared/migration/manual.md +++ b/docs/shared/migration/manual.md @@ -67,7 +67,7 @@ In general, you should not replace the configuration files provided for you. You ### Nx Configuration Files -In addition to configuration files for external libraries, your Nx workspace will have configuration files for Nx itself. This will be `angular.json` for workspaces using the Angular CLI and `workspace.json` for workspaces using the Nx CLI. This file will define all of the individual projects in your workspace (of which your application is one) and the tasks available for them. +In addition to configuration files for external libraries, your Nx workspace will have configuration files for Nx itself. This will be `angular.json` for workspaces using the Angular CLI and `project.json` files for workspaces using the Nx CLI. This file will define all of the individual projects in your workspace (of which your application is one) and the tasks available for them. For example, your generated application should have four [tasks available](/plugin-features/use-task-executors) for it: `build`, `serve`, `lint`, and `test`. Each of these comes with its own configuration. If you find you need to adjust the configuration of a task for your codebase, this is the place to begin looking. diff --git a/docs/shared/migration/preserving-git-histories.md b/docs/shared/migration/preserving-git-histories.md index bef6222dc8..9848eee9b7 100644 --- a/docs/shared/migration/preserving-git-histories.md +++ b/docs/shared/migration/preserving-git-histories.md @@ -30,7 +30,7 @@ At this point, it is very likely that you'll have merge conflicts in your root f For your `package-lock.json` or `yarn.lock`, it's likely best to remove those entirely and allow a new lock file to be generated by installing when the merge is complete. -For other files (think `nx.json`, `workspace.json`, `angular.json`, `package.json`, `tsconfig.base.json`, etc.) you'll need to resolve these conflicts manually to ensure that considerations for both your existing workspace and the newly added project are accounted for. +For other files (think `nx.json`, `project.json`, `angular.json`, `package.json`, `tsconfig.base.json`, etc.) you'll need to resolve these conflicts manually to ensure that considerations for both your existing workspace and the newly added project are accounted for. Note that for these files, the file history of the standalone project will not be present after merging. You would see all changes from resolving conflicts in the single merge commit, and any further back would simply be the file history of your workspace. diff --git a/docs/shared/nest-plugin.md b/docs/shared/nest-plugin.md index 0657bbe2fd..e285f5c798 100644 --- a/docs/shared/nest-plugin.md +++ b/docs/shared/nest-plugin.md @@ -113,7 +113,7 @@ By default, the serve command will run in `watch` mode. This allows code to be c Nest applications also have the `inspect` flag set, so you can attach your debugger to the running instance. -Debugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port `. +Debugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` target in the `project.json`. Or by running the serve command with `--port `. For additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients). diff --git a/docs/shared/node-tutorial/01-create-application.md b/docs/shared/node-tutorial/01-create-application.md index 32fbc2ad5c..25d970192c 100644 --- a/docs/shared/node-tutorial/01-create-application.md +++ b/docs/shared/node-tutorial/01-create-application.md @@ -70,8 +70,7 @@ myorg/ ├── nx.json ├── package.json ├── README.md -├── tsconfig.base.json -└── workspace.json +└── tsconfig.base.json ``` The generate command added one project to our workspace: diff --git a/docs/shared/node-tutorial/04-create-libs.md b/docs/shared/node-tutorial/04-create-libs.md index a2fa1c84fe..694b185369 100644 --- a/docs/shared/node-tutorial/04-create-libs.md +++ b/docs/shared/node-tutorial/04-create-libs.md @@ -47,8 +47,7 @@ myorg/ ├── tools/ ├── nx.json ├── package.json -├── tsconfig.base.json -└── workspace.json +└── tsconfig.base.json ``` Modify the `libs/auth/src/lib/auth.controller.ts` file like this: diff --git a/docs/shared/nx-plugin.md b/docs/shared/nx-plugin.md index 51f633802d..65c37d341c 100644 --- a/docs/shared/nx-plugin.md +++ b/docs/shared/nx-plugin.md @@ -30,7 +30,7 @@ A new plugin is created with a default generator, executor, and e2e app. The created generator contains boilerplate that will do the following: - Normalize a schema (the options that the generator accepts) -- Update the `workspace.json` +- Update the `project.json` - Add the plugin's project to the `nx.json` file - Add files to the disk using templates @@ -227,8 +227,7 @@ happynrwl/ │ │ │ └── preset // <------------- Here │ │ └── index.ts ├── tools - ├── tsconfig.base.json - └── workspace.json + └── tsconfig.base.json ``` After the command is finished, the preset generator is created under the folder named **preset**. @@ -258,7 +257,7 @@ export default async function (tree: Tree, options: PresetGeneratorSchema) { } ``` -To get an in-depth guide on customizing/running or debugging your generator see [workspace generators](/recipe/workspace-generators#running-a-workspace-generator). +To get an in-depth guide on customizing/running or debugging your generator see [local generators](/recipe/local-generators). #### Usage diff --git a/docs/shared/plugin-features/create-your-own-plugin.md b/docs/shared/plugin-features/create-your-own-plugin.md index 92ec55e7f7..036353bb02 100644 --- a/docs/shared/plugin-features/create-your-own-plugin.md +++ b/docs/shared/plugin-features/create-your-own-plugin.md @@ -36,14 +36,14 @@ Plugins have: - Plugins can provide an array of glob patterns, `projectFilePatterns` that are used to infer project information. - Plugins can provide a function `registerProjectTargets` that takes in one of the matched project files, and returns an object containing inferred targets from the file. - - This allows plugins to add new projects to the workspace when it doesn't contain `workspace.json`, and infer extra + - This allows plugins to add new projects to the workspace that aren't identified by `project.json` or `package.json` files, and infer extra targets without adding them into project configuration. All the core plugins are written using Nx Devkit, and you can use the same utilities to write your own generators and executors. {% callout type="check" title="Plugins!" %} -The Nx team maintains a core set of plugins for many application and tooling frameworks. You can write [custom generators](/recipe/workspace-generators) and [executors](/recipe/creating-custom-executors) for your own workspace. You can also write your own plugin and share it with the community. The [Nx Plugin](/packages/nx-plugin) plugin provides guidance on how you can build your own custom plugins. +The Nx team maintains a core set of plugins for many application and tooling frameworks. You can write [custom generators](/recipe/local-generators) and [executors](/recipe/creating-custom-executors) for your own workspace. You can also write your own plugin and share it with the community. The [Nx Plugin](/packages/nx-plugin) plugin provides guidance on how you can build your own custom plugins. {% /callout %} ### Local workspace plugins @@ -82,6 +82,6 @@ and generators. ## Learn more -- [Workspace generators](/recipe/workspace-generators) -- [Workspace executors](/recipe/creating-custom-executors) +- [Local generators](/recipe/local-generators) +- [Local executors](/recipe/creating-custom-executors) - [Nx Community Plugins](/community) diff --git a/docs/shared/plugin-features/use-code-generators.md b/docs/shared/plugin-features/use-code-generators.md index fdf043dbc5..eae0aaaa28 100644 --- a/docs/shared/plugin-features/use-code-generators.md +++ b/docs/shared/plugin-features/use-code-generators.md @@ -7,7 +7,7 @@ Generators provide a way to automate many tasks you regularly perform as part of There are three main types of generators: 1. **Plugin Generators** are available when an Nx plugin has been installed in your workspace. -2. **Workspace Generators** are generators that you can create for your own workspace. [Workspace generators](/recipe/workspace-generators) allow you to codify the processes that are unique to your own organization. +2. **Local Generators** are generators that you can create for your own workspace. [Local generators](/recipe/local-generators) allow you to codify the processes that are unique to your own organization. 3. **Update Generators** are invoked by Nx plugins when you [update Nx](/recipes/adopting-nx) to keep your config files in sync with the latest versions of third party tools. ## Invoking Plugin Generators @@ -23,5 +23,4 @@ It is important to have a clean git working directory before invoking a generato ## See Also -- [nx.json defaultCollection property](/reference/nx-json#cli-options) - [nx.json generator defaults](/reference/nx-json#generators) diff --git a/docs/shared/react-native-plugin.md b/docs/shared/react-native-plugin.md index 333f629a49..5cf32dd16e 100644 --- a/docs/shared/react-native-plugin.md +++ b/docs/shared/react-native-plugin.md @@ -63,7 +63,7 @@ To generate a new component inside library run: npx nx g @nrwl/react-native:component your-component-name --project=your-lib-name --export ``` -Replace `your-lib-name` with the app's name as defined in your workspace.json file. +Replace `your-lib-name` with the app's name as defined in your `tsconfig.base.json` file or the `name` property of your `package.json` ## Using React Native diff --git a/docs/shared/react-tutorial/01-create-application.md b/docs/shared/react-tutorial/01-create-application.md index 1903dc5d67..8082a92571 100644 --- a/docs/shared/react-tutorial/01-create-application.md +++ b/docs/shared/react-tutorial/01-create-application.md @@ -96,8 +96,7 @@ myorg/ ├── nx.json ├── package.json ├── README.md -├── tsconfig.base.json -└── workspace.json +└── tsconfig.base.json ``` Two projects were added to the workspace: diff --git a/docs/shared/react-tutorial/05-add-node-app.md b/docs/shared/react-tutorial/05-add-node-app.md index f775f72910..6c27b23909 100644 --- a/docs/shared/react-tutorial/05-add-node-app.md +++ b/docs/shared/react-tutorial/05-add-node-app.md @@ -97,7 +97,6 @@ myorg/ │ └── todos-e2e/ ├── libs/ ├── tools/ -├── workspace.json ├── nx.json ├── package.json └── tsconfig.base.json diff --git a/docs/shared/react-tutorial/08-create-libs.md b/docs/shared/react-tutorial/08-create-libs.md index e72ac0e06b..db905c4cb7 100644 --- a/docs/shared/react-tutorial/08-create-libs.md +++ b/docs/shared/react-tutorial/08-create-libs.md @@ -103,7 +103,6 @@ myorg/ │ ├── tsconfig.lib.json │ └── tsconfig.spec.json ├── tools/ -├── workspace.json ├── nx.json ├── package.json └── tsconfig.base.json diff --git a/docs/shared/tools-workspace-builders.md b/docs/shared/recipes/local-executors.md similarity index 72% rename from docs/shared/tools-workspace-builders.md rename to docs/shared/recipes/local-executors.md index 978b3b10d9..29cdc7cc41 100644 --- a/docs/shared/tools-workspace-builders.md +++ b/docs/shared/recipes/local-executors.md @@ -1,28 +1,39 @@ -{% callout type="check" title="Local Nx plugins" %} -In Nx 13.10+, local nx plugins can contain executors that are used in the workspace. When creating a custom executor for your workspace, look into the [nx-plugin guide](/packages/nx-plugin) to simplify the build process. -{% /callout %} +# Local Executors -# Creating Custom Executors - -Creating Executors for your workspace standardizes scripts that are run during your development/building/deploying tasks in order to enable Nx's `affected` command and caching capabilities. +Creating Executors for your workspace standardizes scripts that are run during your development/building/deploying tasks in order to provide guidance in the terminal with `--help` and when invoking with [Nx Console](/core-features/integrate-with-editors) This guide shows you how to create, run, and customize executors within your Nx workspace. The examples use the trivial use-case of an `echo` command. ## Creating an executor -Your executor should be created within the `tools` directory of your Nx workspace like so: +If you don't already have a local plugin, use Nx to generate one: + +```bash +# replace `latest` with the version that matches your Nx version +npm install @nrwl/nx-plugin@latest +nx g @nrwl/nx-plugin:plugin my-plugin +``` + +Use the Nx CLI to generate the initial files needed for your executor. + +```bash +nx generate @nrwl/nx-plugin:executor echo --project=my-plugin +``` + +After the command is finished, the executor is created in the plugin `executors` folder. ```treeview happynrwl/ ├── apps/ ├── libs/ -├── tools/ -│ └── executors/ -│ └── echo/ -│ ├── executor.json -│ ├── impl.ts -│ ├── package.json -│ └── schema.json +│ ├── my-plugin +│ │ ├── src +│ │ │ ├── executors +│ │ │ | └── echo/ +│ │ │ | | ├── executor.spec.ts +│ │ │ | | ├── executor.ts +│ │ │ | | ├── schema.d.ts +│ │ │ | | └── schema.json ├── nx.json ├── package.json └── tsconfig.base.json @@ -48,11 +59,11 @@ This file describes the options being sent to the executor (very similar to the This example describes a single option for the executor that is a `string` called `textToEcho`. When using this executor, specify a `textToEcho` property inside the options. -In our `impl.ts` file, we're creating an `Options` interface that matches the json object being described here. +In our `executor.ts` file, we're creating an `Options` interface that matches the json object being described here. -### impl.ts +### executor.ts -The `impl.ts` contains the actual code for your executor. Your executor's implementation must export a function that takes an options object and returns a `Promise<{ success: boolean }>`. +The `executor.ts` contains the actual code for your executor. Your executor's implementation must export a function that takes an options object and returns a `Promise<{ success: boolean }>`. ```typescript import type { ExecutorContext } from '@nrwl/devkit'; @@ -81,43 +92,7 @@ export default async function echoExecutor( } ``` -### executor.json - -The `executor.json` file provides the description of your executor to the CLI. - -```json -{ - "executors": { - "echo": { - "implementation": "./impl", - "schema": "./schema.json", - "description": "Runs `echo` (to test executors out)." - } - } -} -``` - -Note that this `executor.json` file is naming our executor 'echo' for the CLI's purposes, and mapping that name to the given implementation file and schema. - -### package.json - -This is all that’s required from the `package.json` file: - -```json -{ - "executors": "./executor.json" -} -``` - -## Compiling and Running your Executor - -After your files are created, compile your executor with `tsc` (which is available locally in any Nx workspace): - -```bash -npx tsc tools/executors/echo/impl -``` - -This will create the `impl.js` file in your file directory, which will serve as the artifact used by the CLI. +## Running your Executor Our last step is to add this executor to a given project’s `targets` object in your project's `project.json` file: @@ -135,7 +110,7 @@ Our last step is to add this executor to a given project’s `targets` object in // ,,, }, "echo": { - "executor": "./tools/executors/echo:echo", + "executor": "@my-org/my-plugin:echo", "options": { "textToEcho": "Hello World" } @@ -144,18 +119,16 @@ Our last step is to add this executor to a given project’s `targets` object in } ``` -Note that the format of the `executor` string here is: `${Path to directory containing the executor's package.json}:${executor name}`. - Finally, you run the executor via the CLI as follows: ```bash -nx run platform:echo +nx run my-project:echo ``` To which we'll see the console output: ```bash -> nx run platform:echo +> nx run my-project:echo Executing "echo"... Options: { "textToEcho": "Hello World" @@ -163,18 +136,6 @@ Options: { Hello World ``` -## Debugging Executors - -As part of Nx's computation cache process, Nx forks the node process, which can make it difficult to debug an executor command. Follow these steps to debug an executor: - -1. Use VS Code's command pallette to open a `Javascript Debug Terminal` -2. Find the compiled (`*.js`) executor code and set a breakpoint. -3. Run the executor in the debug terminal - -```bash -nx run platform:echo -``` - ## Using Node Child Process [Node’s `childProcess`](https://nodejs.org/api/child_process.html) is often useful in executors. diff --git a/docs/shared/generators/workspace-generators.md b/docs/shared/recipes/local-generators.md similarity index 52% rename from docs/shared/generators/workspace-generators.md rename to docs/shared/recipes/local-generators.md index e62f6e4316..c55e9ba2d0 100644 --- a/docs/shared/generators/workspace-generators.md +++ b/docs/shared/recipes/local-generators.md @@ -1,36 +1,39 @@ -{% callout type="check" title="Local Nx plugins" %} -In Nx 13.10, we introduced the ability to run generators from Nx plugins in the workspace they were created in. +# Local Generators -By using a "local" plugin, you can set the plugin as your workspace's default collection and get several other affordances that are not provided to workspace generators. This is the preferred method for "workspace generators", and existing generators will eventually be transitioned to use a local plugin. +Local plugin generators provide a way to automate many tasks you regularly perform as part of your development workflow. Whether it is scaffolding out components, features, or ensuring libraries are generated and structured in a certain way, generators help you standardize these tasks in a consistent, and predictable manner. -Check the [nx-plugin guide](/packages/nx-plugin) for information on creating a new plugin. -{% /callout %} +Nx provides tooling around creating, and running custom generators from within your workspace. This guide shows you how to create, run, and customize generators within your Nx workspace. -# Workspace Generators +## Creating a generator -Workspace generators provide a way to automate many tasks you regularly perform as part of your development workflow. Whether it is scaffolding out components, features, or ensuring libraries are generated and structured in a certain way, generators help you standardize these tasks in a consistent, and predictable manner. - -Nx provides tooling around creating, and running custom generators from within your workspace. This guide shows you how to create, run, and customize workspace generators within your Nx workspace. - -## Creating a workspace generator - -Use the Nx CLI to generate the initial files needed for your workspace generator. +If you don't already have a local plugin, use Nx to generate one: ```bash -nx generate @nrwl/workspace:workspace-generator my-generator +# replace `latest` with the version that matches your Nx version +npm install @nrwl/nx-plugin@latest +nx g @nrwl/nx-plugin:plugin my-plugin ``` -After the command is finished, the workspace generator is created under the `tools/generators` folder. +Use the Nx CLI to generate the initial files needed for your generator. + +```bash +nx generate @nrwl/nx-plugin:generator my-generator --project=my-plugin +``` + +After the command is finished, the generator is created in the plugin `generators` folder. ```treeview happynrwl/ ├── apps/ ├── libs/ -├── tools/ -│ ├── generators -│ | └── my-generator/ -│ | | ├── index.ts -│ | | └── schema.json +│ ├── my-plugin +│ │ ├── src +│ │ │ ├── generators +│ │ │ | └── my-generator/ +│ │ │ | | ├── generator.spec.ts +│ │ │ | | ├── generator.ts +│ │ │ | | ├── scehma.d.ts +│ │ │ | | └── schema.json ├── nx.json ├── package.json └── tsconfig.base.json @@ -79,25 +82,25 @@ In the schema.json file for your generator, the `name` is provided as a default The `$default` object is used to read arguments from the command-line that are passed to the generator. The first argument passed to this schematic is used as the `name` property. -## Running a workspace generator +## Running a generator -To run a generator, invoke the `nx workspace-generator` command with the name of the generator. +To run a generator, invoke the `nx generate` command with the name of the generator. ```bash -nx workspace-generator my-generator mylib +nx generate @myorg/my-plugin:my-generator mylib ``` -## Debugging Workspace generators +## Debugging generators ### With Visual Studio Code 1. Open the Command Palette and choose `Debug: Create JavaScript Debug Terminal`. This will open a terminal with debugging enabled. 2. Set breakpoints in your code -3. Run `nx workspace-generator my-generator` in the debug terminal. +3. Run `nx g my-generator` in the debug terminal. ![](/shared/vscode-schematics-debug.png) -## Workspace Generator Utilities +## Generator Utilities -The `@nrwl/devkit` package provides many utility functions that can be used in schematics to help with modifying files, reading and updating configuration files, and working with an Abstract Syntax Tree (AST). +The [`@nrwl/devkit` package](/devkit/index) provides many utility functions that can be used in generators to help with modifying files, reading and updating configuration files, and working with an Abstract Syntax Tree (AST). diff --git a/docs/shared/recipes/recipe-list.md b/docs/shared/recipes/recipe-list.md index bcc4d1060c..b925aa0dc3 100644 --- a/docs/shared/recipes/recipe-list.md +++ b/docs/shared/recipes/recipe-list.md @@ -39,7 +39,7 @@ ## Generators -- [Workspace Generators](/recipe/workspace-generators) +- [Local Generators](/recipe/local-generators) - [Composing Generators](/recipe/composing-generators) - [Generator Options](/recipe/generator-options) - [Creating Files](/recipe/creating-files) diff --git a/docs/shared/reference/nx-json.md b/docs/shared/reference/nx-json.md index 605e0d5d27..ec373010e6 100644 --- a/docs/shared/reference/nx-json.md +++ b/docs/shared/reference/nx-json.md @@ -15,7 +15,6 @@ The following is an expanded version showing all options. Your `nx.json` will li "libsDir": "packages" }, "implicitDependencies": { - "workspace.json": "*", "package.json": { "dependencies": "*", "devDependencies": "*" @@ -33,9 +32,6 @@ The following is an expanded version showing all options. Your `nx.json` will li "dependsOn": ["^build"] } }, - "cli": { - "defaultCollection": "@nrwl/js" - }, "generators": { "@nrwl/js:library": { "buildable": true @@ -87,7 +83,6 @@ statically. You can configure those using `implicitDependencies`. ```json { "implicitDependencies": { - "workspace.json": "*", "package.json": { "dependencies": "*", "devDependencies": { @@ -105,7 +100,6 @@ statically. You can configure those using `implicitDependencies`. In the example above: -- Changing `workspace.json` affects every project. - Changing the `dependencies` property in `package.json` affects every project. - Changing the `mypackage` property in `package.json` only affects `mylib`. - Changing any of the custom check `scripts` in `package.json` affects every project. @@ -180,19 +174,6 @@ Another target default you can configure is `outputs`: } ``` -### CLI Options - -The following command generates a new library: `nx g @nrwl/js:lib mylib`. After setting the `defaultCollection`property, -the lib is generated without mentioning the collection name: `nx g lib mylib`. - -```json -{ - "cli": { - "defaultCollection": "@nrwl/js" - } -} -``` - ### Generators Default generator options are configured in `nx.json` as well. For instance, the following tells Nx to always @@ -226,24 +207,7 @@ by `"nx/tasks-runners/default"` and `"@nrwl/nx-cloud"`. | skipNxCache | defines whether the Nx Cache should be skipped (defaults to `false`) | | cacheDirectory | defines where the local cache is stored (defaults to `node_modules/.cache/nx`) | | encryptionKey | (when using `"@nrwl/nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner normalizes the key length, so any length of key is acceptable | -| runtimeCacheInputs | defines the list of commands that are run by the runner to include into the computation hash value | | selectivelyHashTsConfig | only hash the path mapping of the active project in the `tsconfig.base.json` (e.g., adding/removing projects doesn't affect the hash of existing projects) (defaults to `false`) | -`runtimeCacheInputs` are set as follows: - -```json -{ - "tasksRunnerOptions": { - "default": { - "runner": "nx/tasks-runners/default", - "options": { - "cacheableOperations": ["build", "lint", "test", "e2e"], - "runtimeCacheInputs": ["node -v"] - } - } - } -} -``` - You can configure `parallel` in `nx.json`, but you can also pass them in the terminal `nx run-many --target=test --parallel=5`. diff --git a/docs/shared/workspace-plugin.md b/docs/shared/workspace-plugin.md index a5722f778b..663cec0430 100644 --- a/docs/shared/workspace-plugin.md +++ b/docs/shared/workspace-plugin.md @@ -1,10 +1,10 @@ The workspace plugin contains executors and generators that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it. -## Creating Workspace Generators +## Creating Local Generators -Codifying your organization's best practices into workspace generators is a great way to ensure that the best practices are easy to follow and implement. Running `nx g @nrwl/workspace:workspace-generator feature` will create a workspace generator which is written the same way generators are written for Nx plugins. The workspace generator can then be run with `nx workspace-generator feature`. +Codifying your organization's best practices into local generators is a great way to ensure that the best practices are easy to follow and implement. Running `nx g @nrwl/nx-plugin:plugin feature` will create a local plugin with a generator which is written the same way generators are written for Nx plugins. -> See more about [workspace generators](/recipe/workspace-generators) +> See more about [local generators](/recipe/local-generators) ## Reorganizing Projects diff --git a/nx-dev/nx-dev/redirect-rules.config.js b/nx-dev/nx-dev/redirect-rules.config.js index 3948762b4e..4c442a2262 100644 --- a/nx-dev/nx-dev/redirect-rules.config.js +++ b/nx-dev/nx-dev/redirect-rules.config.js @@ -255,6 +255,7 @@ const diataxis = { '/examples/apollo-react': '/recipe/apollo-react', '/examples/caching': '/recipe/caching', '/examples/dte': '/recipe/dte', + '/recipe/workspace-generators': '/recipe/local-generators', }; /**