docs(nxdev): deprecated section (#12054)
This commit is contained in:
Isaac Mann
GitHub
parent
a411e85e42
commit
5cab39b9aa
@ -11,7 +11,7 @@
|
||||
"id": "overview",
|
||||
"path": "/packages/cypress",
|
||||
"file": "shared/cypress-plugin",
|
||||
"content": "\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": "\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",
|
||||
|
||||
@ -11,7 +11,7 @@
|
||||
"name": "Overview",
|
||||
"path": "/packages/detox",
|
||||
"file": "shared/detox-plugin",
|
||||
"content": "\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 <your emulator name>`. 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 <app-name-e2e> --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": "\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 <your emulator name>`. 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 <app-name-e2e> --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": [
|
||||
|
||||
@ -11,7 +11,7 @@
|
||||
"name": "Overview",
|
||||
"path": "/packages/nest",
|
||||
"file": "shared/nest-plugin",
|
||||
"content": "\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 <number>`.\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": "\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 <number>`.\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": [
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -11,7 +11,7 @@
|
||||
"name": "Overview",
|
||||
"path": "/packages/react-native",
|
||||
"file": "shared/react-native-plugin",
|
||||
"content": "\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": "\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": [
|
||||
|
||||
@ -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",
|
||||
|
||||
@ -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"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
40
docs/shared/deprecated/default-collection.md
Normal file
40
docs/shared/deprecated/default-collection.md
Normal file
@ -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
|
||||
```
|
||||
34
docs/shared/deprecated/runtime-cache-inputs.md
Normal file
34
docs/shared/deprecated/runtime-cache-inputs.md
Normal file
@ -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" }]
|
||||
// ...
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
29
docs/shared/deprecated/workspace-executors.md
Normal file
29
docs/shared/deprecated/workspace-executors.md
Normal file
@ -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"
|
||||
}
|
||||
```
|
||||
31
docs/shared/deprecated/workspace-generators.md
Normal file
31
docs/shared/deprecated/workspace-generators.md
Normal file
@ -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
|
||||
```
|
||||
36
docs/shared/deprecated/workspace-json.md
Normal file
36
docs/shared/deprecated/workspace-json.md
Normal file
@ -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.
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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": {
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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 <number>`.
|
||||
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 <number>`.
|
||||
|
||||
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).
|
||||
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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)
|
||||
|
||||
@ -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)
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -97,7 +97,6 @@ myorg/
|
||||
│ └── todos-e2e/
|
||||
├── libs/
|
||||
├── tools/
|
||||
├── workspace.json
|
||||
├── nx.json
|
||||
├── package.json
|
||||
└── tsconfig.base.json
|
||||
|
||||
@ -103,7 +103,6 @@ myorg/
|
||||
│ ├── tsconfig.lib.json
|
||||
│ └── tsconfig.spec.json
|
||||
├── tools/
|
||||
├── workspace.json
|
||||
├── nx.json
|
||||
├── package.json
|
||||
└── tsconfig.base.json
|
||||
|
||||
@ -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.
|
||||
@ -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.
|
||||
|
||||
|
||||
|
||||
## 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).
|
||||
@ -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)
|
||||
|
||||
@ -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`.
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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',
|
||||
};
|
||||
|
||||
/**
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user