docs(nxdev): fix 404 links (#11134)
This commit is contained in:
Benjamin Cabanes
GitHub
parent
c075e69898
commit
b05f9e0eee
@ -10,7 +10,7 @@
|
||||
"id": "overview",
|
||||
"path": "/packages/angular",
|
||||
"file": "shared/angular-plugin",
|
||||
"content": "\n\nThe Nx Plugin for Angular contains executors, generators, and utilities for managing Angular applications and libraries within an Nx workspace. It provides:\n\n- Integration with libraries such as Storybook, Jest, Cypress, Karma, and Protractor.\n- Generators to help scaffold code quickly, including:\n - Micro Frontends\n - Libraries, both internal to your codebase and publishable to npm\n - Upgrading AngularJS applications\n - Single Component Application Modules (SCAMs)\n- NgRx helpers.\n- Utilities for automatic workspace refactoring.\n\n## Setting up the Angular plugin\n\nAdding the Angular plugin to an existing Nx workspace can be done with the following:\n\n```bash\nyarn add -D @nrwl/angular\n```\n\n```bash\nnpm install -D @nrwl/angular\n```\n\n## Using the Angular Plugin\n\n### Generating an application\n\nIt's straightforward to generate an Angular application:\n\n```bash\nnx g @nrwl/angular:app appName\n```\n\nBy default, the application will be generated with:\n\n- ESLint as the linter.\n- Jest as the unit test runner.\n- Cypress as the E2E test runner.\n\nWe can then serve, build, test, lint, and run e2e tests on the application with the following commands:\n\n```bash\nnx serve appName\nnx build appName\nnx test appName\nnx lint appName\nnx e2e appName\n```\n\n### Generating a library\n\nGenerating an Angular library is very similar to generating an application:\n\n```bash\nnx g @nrwl/angular:lib libName\n```\n\nBy default, the library will be generated with:\n\n- ESLint as the linter.\n- Jest as the unit test runner.\n\nWe can then test and lint the library with the following commands:\n\n```bash\nnx test libName\nnx lint libName\n```\n\nRead more about:\n\n- [Creating Libraries](/structure/creating-libraries)\n- [Library Types](/structure/library-types)\n- [Buildable and Publishable Libraries](/structure/buildable-and-publishable-libraries)\n\n## More Documentation\n\n- [Angular Nx Tutorial](/angular-tutorial/01-create-application)\n- [Setup Module Federation with Angular and Nx](/module-federation/faster-builds)\n- [Using NgRx](/guides/misc-ngrx)\n- [Using DataPersistence](/guides/misc-data-persistence)\n- [Upgrading an AngularJS application to Angular](/guides/misc-upgrade)\n- [Using Tailwind CSS with Angular projects](/guides/using-tailwind-css-with-angular-projects)\n"
|
||||
"content": "\n\nThe Nx Plugin for Angular contains executors, generators, and utilities for managing Angular applications and libraries within an Nx workspace. It provides:\n\n- Integration with libraries such as Storybook, Jest, Cypress, Karma, and Protractor.\n- Generators to help scaffold code quickly, including:\n - Micro Frontends\n - Libraries, both internal to your codebase and publishable to npm\n - Upgrading AngularJS applications\n - Single Component Application Modules (SCAMs)\n- NgRx helpers.\n- Utilities for automatic workspace refactoring.\n\n## Setting up the Angular plugin\n\nAdding the Angular plugin to an existing Nx workspace can be done with the following:\n\n```bash\nyarn add -D @nrwl/angular\n```\n\n```bash\nnpm install -D @nrwl/angular\n```\n\n## Using the Angular Plugin\n\n### Generating an application\n\nIt's straightforward to generate an Angular application:\n\n```bash\nnx g @nrwl/angular:app appName\n```\n\nBy default, the application will be generated with:\n\n- ESLint as the linter.\n- Jest as the unit test runner.\n- Cypress as the E2E test runner.\n\nWe can then serve, build, test, lint, and run e2e tests on the application with the following commands:\n\n```bash\nnx serve appName\nnx build appName\nnx test appName\nnx lint appName\nnx e2e appName\n```\n\n### Generating a library\n\nGenerating an Angular library is very similar to generating an application:\n\n```bash\nnx g @nrwl/angular:lib libName\n```\n\nBy default, the library will be generated with:\n\n- ESLint as the linter.\n- Jest as the unit test runner.\n\nWe can then test and lint the library with the following commands:\n\n```bash\nnx test libName\nnx lint libName\n```\n\nRead more about:\n\n- [Creating Libraries](/structure/creating-libraries)\n- [Library Types](/structure/library-types)\n- [Buildable and Publishable Libraries](/structure/buildable-and-publishable-libraries)\n\n## More Documentation\n\n- [Angular Nx Tutorial](/angular-tutorial/01-create-application)\n- [Setup Module Federation with Angular and Nx](/module-federation/faster-builds)\n- [Using NgRx](/guides/misc-ngrx)\n- [Using DataPersistence](/guides/misc-data-persistence)\n- [Upgrading an AngularJS application to Angular](/migration/migration-angularjs)\n- [Using Tailwind CSS with Angular projects](/guides/using-tailwind-css-with-angular-projects)\n"
|
||||
}
|
||||
],
|
||||
"generators": [
|
||||
|
||||
@ -16,7 +16,7 @@
|
||||
"name": "Component Testing",
|
||||
"id": "cypress-component-testing",
|
||||
"file": "shared/cypress-component-testing",
|
||||
"content": "# Cypress Component Testing\n\n> Component testing is in a early preview and requires Cypress v10 and above.\n> See our [guide for more information](/cypress/cypress-v10-migration) to migrate to Cypress v10.\n\nUnlike [E2E testing](/packages/cypress), component testing does not create a new project. Instead, Cypress component testing is added\ndirectly to a project.\n\n```bash\nnx g @nrwl/react:cypress-component-configuration --project=your-react-lib\n```\n\nYou can optionally pass in `--generate-tests` to create component tests for all components within the library.\n\n## Testing Projects\n\nRun `nx component-test your-lib` to execute the component tests with Cypress.\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/libs/your-lib/screenshots` and `dist/cypress/libs/your-lib/videos`.\n\n## Watching for Changes (Headed Mode)\n\nWith, `nx component-test your-lib --watch` Cypress will start in headed mode. Where you can see your component being tested.\n\nRunning Cypress with `--watch` is a great way to iterate on your components since cypress will rerun your tests as you make those changes validating the new behavior.\n\n## More Information\n\nYou can read more on component testing in the [Cypress documentation](https://docs.cypress.io/guides/component-testing/writing-your-first-component-test).\n"
|
||||
"content": "# Cypress Component Testing\n\n> Component testing is in a early preview and requires Cypress v10 and above.\n> See our [guide for more information](/cypress/v10-migration-guide) to migrate to Cypress v10.\n\nUnlike [E2E testing](/packages/cypress), component testing does not create a new project. Instead, Cypress component testing is added\ndirectly to a project.\n\n```bash\nnx g @nrwl/react:cypress-component-configuration --project=your-react-lib\n```\n\nYou can optionally pass in `--generate-tests` to create component tests for all components within the library.\n\n## Testing Projects\n\nRun `nx component-test your-lib` to execute the component tests with Cypress.\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/libs/your-lib/screenshots` and `dist/cypress/libs/your-lib/videos`.\n\n## Watching for Changes (Headed Mode)\n\nWith, `nx component-test your-lib --watch` Cypress will start in headed mode. Where you can see your component being tested.\n\nRunning Cypress with `--watch` is a great way to iterate on your components since cypress will rerun your tests as you make those changes validating the new behavior.\n\n## More Information\n\nYou can read more on component testing in the [Cypress documentation](https://docs.cypress.io/guides/component-testing/writing-your-first-component-test).\n"
|
||||
},
|
||||
{
|
||||
"name": "v10 Migration Guide",
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -10,7 +10,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**Note:** You can also run the command without arguments to go through the interactive prompts.\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](/react-native/run-ios) - Builds your app and starts it on iOS simulator or device\n- [run-android](/react-native/run-android) - Builds your app and starts it on a connected Android emulator or device\n- [build-android](/react-native/build-android) - Release Build for Android\n- [start](/react-native/package) - Starts the server that communicates with connected devices\n- [bundle](/web/package) - Builds the JavaScript bundle for offline use\n- [sync-deps](/react-native/sync-deps) - Syncs dependencies to package.json (required for autolinking)\n- [ensure-symlink](/react-native/ensure-symlink) - Ensure workspace node_modules is symlink under app's node_modules folder\n\n## More Documentation\n\n- [Using Detox](/detox/overview)\n- [Using Jest](/jest/overview)\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**Note:** You can also run the command without arguments to go through the interactive prompts.\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"
|
||||
}
|
||||
],
|
||||
"generators": [
|
||||
|
||||
@ -10,7 +10,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](/generators/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`](/workspace/move) and [`@nrwl/workspace:remove`](/workspace/remove) generators to help aid with this.\n\n### Moving Projects\n\nRunning `nx g @nrwl/workspace:move new/location/my-lib --projectName 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`](/workspace/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`](/workspace/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 nx: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 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](/generators/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 new/location/my-lib --projectName 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 nx: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"
|
||||
}
|
||||
],
|
||||
"generators": [
|
||||
|
||||
@ -44,7 +44,7 @@ Every organization manages their CI/CD pipelines differently, so the examples do
|
||||
|
||||
Read the guides for more information on how to configure them in CI.
|
||||
|
||||
- [Overview](/ci/overview#distributed-ci-with-nx-cloud)
|
||||
- [Overview](/using-nx/ci-overview#distributed-ci-with-nx-cloud)
|
||||
- [Azure Pipelines](/ci/monorepo-ci-azure#distributed-ci-with-nx-cloud)
|
||||
- [Circle CI](/ci/monorepo-ci-circle-ci#distributed-ci-with-nx-cloud)
|
||||
- [GitHub Actions](/ci/monorepo-ci-github-actions#distributed-ci-with-nx-cloud)
|
||||
|
||||
@ -81,5 +81,5 @@ Read more about:
|
||||
- [Setup Module Federation with Angular and Nx](/module-federation/faster-builds)
|
||||
- [Using NgRx](/guides/misc-ngrx)
|
||||
- [Using DataPersistence](/guides/misc-data-persistence)
|
||||
- [Upgrading an AngularJS application to Angular](/guides/misc-upgrade)
|
||||
- [Upgrading an AngularJS application to Angular](/migration/migration-angularjs)
|
||||
- [Using Tailwind CSS with Angular projects](/guides/using-tailwind-css-with-angular-projects)
|
||||
|
||||
@ -14,7 +14,7 @@ But they come with their own technical challenges. The more code you add into yo
|
||||
|
||||
Adding Nx to your CI pipeline makes this more efficient.
|
||||
|
||||
Nx provides out-of-the-box implementation of CI workflows for `GitHub`, `Azure` and `CircleCI` during the [creation of the Nx workspace](/cli/create-nx-workspace#ci) or later using the [ci-workflow](/packages/workspace/generators/ci-workflow) generator.
|
||||
Nx provides out-of-the-box implementation of CI workflows for `GitHub`, `Azure` and `CircleCI` during the [creation of the Nx workspace](/nx/create-nx-workspace#ci) or later using the [ci-workflow](/packages/workspace/generators/ci-workflow) generator.
|
||||
|
||||
{% nx-cloud-section %}
|
||||
|
||||
@ -56,4 +56,4 @@ The following guides cover optimizing your CI/CD environments with affected comm
|
||||
- [Setting up CI using GitHub Actions](/ci/monorepo-ci-github-actions)
|
||||
- [Setting up CI using Jenkins](/ci/monorepo-ci-jenkins)
|
||||
- [Setting up CI using GitLab](/ci/monorepo-ci-gitlab)
|
||||
- [Setting up CI using Bitbucket](/ci/monorepo-ci-bitbucket)
|
||||
- [Setting up CI using Bitbucket](/ci/monorepo-ci-bitbucket-pipelines)
|
||||
|
||||
@ -655,7 +655,7 @@ a [`.gitignore` file](https://git-scm.com/book/en/v2/Git-Basics-Recording-Change
|
||||
## Validating the configuration
|
||||
|
||||
If at any point in time you want to check if your configuration is in sync, you can use
|
||||
the [workspace-lint](/cli/workspace-lint) executor:
|
||||
the [workspace-lint](/nx/workspace-lint) executor:
|
||||
|
||||
```bash
|
||||
nx workspace-lint
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Cypress Component Testing
|
||||
|
||||
> Component testing is in a early preview and requires Cypress v10 and above.
|
||||
> See our [guide for more information](/cypress/cypress-v10-migration) to migrate to Cypress v10.
|
||||
> See our [guide for more information](/cypress/v10-migration-guide) to migrate to Cypress v10.
|
||||
|
||||
Unlike [E2E testing](/packages/cypress), component testing does not create a new project. Instead, Cypress component testing is added
|
||||
directly to a project.
|
||||
|
||||
@ -77,7 +77,7 @@ As with most things in Nx, the core of Nx Devkit is very simple. It only uses la
|
||||
objects (the tree being the only exception). See [Simplest Generator](/generators/creating-files)
|
||||
and [Simplest Executor](/executors/using-builders#simplest-executor) for examples on creating generators
|
||||
and executors. The [Using Executors](/executors/using-builders)
|
||||
and [Using Generators](/generators/using-schematics) guides also have additional information on executors
|
||||
and [Using Generators](/generators/using-generators) guides also have additional information on executors
|
||||
and generators.
|
||||
|
||||
## Learn more
|
||||
|
||||
@ -16,7 +16,7 @@ There are three main types of generators:
|
||||
|
||||
## Invoking Plugin Generators
|
||||
|
||||
Generators allow you to create or modify your codebase in a simple and repeatable way. Generators are invoked using the [`nx generate`](/cli/generate) command.
|
||||
Generators allow you to create or modify your codebase in a simple and repeatable way. Generators are invoked using the [`nx generate`](/nx/generate) command.
|
||||
|
||||
```bash
|
||||
nx generate [plugin]:[generator-name] [options]
|
||||
|
||||
@ -21,7 +21,7 @@ It is also a good idea to read the [mental model guide](/using-nx/mental-model)
|
||||
|
||||
Nx plugins helps you develop [Angular](/packages/angular) applications with fully integrated support for
|
||||
modern tools and libraries like [Jest](/jest/overview), [Cypress](/cypress/overview),
|
||||
[ESLint](/linter/eslint), [Storybook](/packages/storybook), [NgRx](/guides/misc-ngrx) and more.
|
||||
[ESLint](/packages/linter), [Storybook](/packages/storybook), [NgRx](/guides/misc-ngrx) and more.
|
||||
|
||||
{% youtube
|
||||
src="https://www.youtube.com/embed/cXOkmOy-8dk"
|
||||
|
||||
@ -20,7 +20,7 @@ It is also a good idea to read the [mental model guide](/using-nx/mental-model)
|
||||
|
||||
Nx plugins help you develop [React](/packages/react) applications with fully integrated support for modern tools
|
||||
and libraries like [Jest](/jest/overview), [Cypress](/cypress/overview),
|
||||
[Storybook](/packages/storybook), [ESLint](/linter/eslint), and more. Nx also supports React
|
||||
[Storybook](/packages/storybook), [ESLint](/packages/linter), and more. Nx also supports React
|
||||
frameworks like [Next.js](/next/overview), Remix, and has great support for [React Native](/react-native/overview).
|
||||
|
||||
{% youtube
|
||||
|
||||
@ -30,7 +30,7 @@ npx create-nx-workspace --preset=react-native
|
||||
npx create-nx-workspace --preset=angular
|
||||
```
|
||||
|
||||
For more information about possible options see the [create-nx-workspace command](/cli/create-nx-workspace).
|
||||
For more information about possible options see the [create-nx-workspace command](/nx/create-nx-workspace).
|
||||
|
||||
## Add Nx to an Existing Project
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ For most apps, the default configuration of webpack is sufficient, but sometimes
|
||||
|
||||
Note: For Angular developers, use an executor like [`ngx-build-plus`](https://github.com/manfredsteyer/ngx-build-plus).
|
||||
|
||||
In your `project.json` configuration for the `@nrwl/web:build` or `@nrwl/node:build` executor, set the [`webpackConfig`](/web/build#webpackconfig) option to point to your custom webpack config file. i.e. `apps/my-app/custom-webpack.config.js`
|
||||
In your `project.json` configuration for the `@nrwl/web:build` or `@nrwl/node:build` executor, set the [`webpackConfig`](/packages/web/executors/webpack) option to point to your custom webpack config file. i.e. `apps/my-app/custom-webpack.config.js`
|
||||
|
||||
The custom webpack file contains a function that takes as input the existing webpack config and then returns a modified config object. `context` includes all the options specified for the executor.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
A monorepo is a single git repository that holds the source code for multiple applications and libraries, along with the tooling for them.
|
||||
|
||||
{% callout type="note" title="Lerna users" %}
|
||||
If you are familiar with Lerna or Yarn workspaces, check out [this guide](/guides/lerna-and-nx) (with a quick video) showing how to add Nx to a Lerna/Yarn workspace, what the difference is, when to use both and when to use just Nx.
|
||||
If you are familiar with Lerna or Yarn workspaces, check out [this guide](/migration/lerna-and-nx) (with a quick video) showing how to add Nx to a Lerna/Yarn workspace, what the difference is, when to use both and when to use just Nx.
|
||||
{% /callout %}
|
||||
|
||||
## What are the benefits of a monorepo?
|
||||
@ -38,7 +38,7 @@ Nx provides tools to give you the benefits of a monorepo without the drawbacks o
|
||||
|
||||
- **Consistent Code Generation** - Generators allow you to customize and standardize organizational conventions and structure, removing the need to perform the same manual setup tasks repetitively.
|
||||
|
||||
- **Affected Commands** - [Nx’s affected commands](/cli/affected) analyze your source code, the context of the changes, and only runs tasks on the affected projects impacted by the source code changes.
|
||||
- **Affected Commands** - [Nx’s affected commands](/nx/affected) analyze your source code, the context of the changes, and only runs tasks on the affected projects impacted by the source code changes.
|
||||
|
||||
- **Distributed Caching** - Nx provides local caching and support for distributed caching of command executions. With distributed caching, when someone on your team runs a command, everyone else gets access to those artifacts to speed up their command executions, bringing them down from minutes to seconds. Nx helps you scale your development to massive applications and libraries even more with distributed task execution and incremental builds.
|
||||
|
||||
@ -46,6 +46,6 @@ Nx provides tools to give you the benefits of a monorepo without the drawbacks o
|
||||
|
||||
- **Controlled Code Sharing** - While sharing code becomes much easier to share, there should also be constraints of when and how code should be depended on. Libraries are defined with specific enforced APIs. Rules should be put in place to define which libraries can depend on each other. Also, even though everyone has access to the repo does not mean that anyone should change any project. Projects should have owners such that changes to that project requires their approval. This can be defined using a `CODEOWNERS` file.
|
||||
|
||||
- **Consistent Code Generation** - Generators allow you to automate code creation and modification tasks. Instead of writing a 7 step guide in a readme file, you can create a generator to prompt the developer for inputs and modify the code directly. Nrwl provides plugins containing useful executors and generators for many popular tools. Also, Nx workspaces are extended further through a growing number of community-provided plugins.
|
||||
- **Consistent Code Generation** - Generators allow you to automate code creation and modification tasks. Instead of writing a 7 steps guide in a readme file, you can create a generator to prompt the developer for inputs and modify the code directly. Nrwl provides plugins containing useful executors and generators for many popular tools. Also, Nx workspaces are extended further through a growing number of community-provided plugins.
|
||||
|
||||
- **Accurate Architecture Diagram** - Most architecture diagrams become obsolete in an instant. And every diagram becomes out of date as soon as the code changes. Because Nx understands your code, it generates an up-to-date and accurate diagram of how projects depend on each other. The Nx project dependencies are also pluggable to extend to other programming languages and ecosystems.
|
||||
|
||||
@ -100,7 +100,7 @@ Primary configurations for Jest will be via the `jest.config.js` file that gener
|
||||
|
||||
### Nx
|
||||
|
||||
Nx Jest Plugin options can be configured via the [project config file](/configuration/projectjson) or via the [command line flags](/jest/jest).
|
||||
Nx Jest Plugin options can be configured via the [project config file](/configuration/projectjson) or via the [command line flags](/packages/jest).
|
||||
|
||||
> Hint: Use `--help` to see all available options
|
||||
>
|
||||
@ -146,4 +146,4 @@ Enter [chrome://inspect](chrome://inspect) in Chrome address bar and inspect the
|
||||
## More Documentation
|
||||
|
||||
- [Jest Docs](https://jestjs.io/)
|
||||
- [@nrwl/jest options](/jest/jest)
|
||||
- [@nrwl/jest options](/packages/jest)
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Adding Nx to Lerna/Yarn/PNPM/NPM Workspace
|
||||
|
||||
{% callout type="note" title="Migrating from Lerna?" %}
|
||||
Interested in migrating from [Lerna](https://github.com/lerna/lerna) in particular? In case you missed it, Nrwl, the company behind Nx, [took over stewardship of Lerna](https://blog.nrwl.io/lerna-is-dead-long-live-lerna-61259f97dbd9). This allows for a much better integration between the two. [Read more in our dedicated guide](/guides/lerna-and-nx).
|
||||
Interested in migrating from [Lerna](https://github.com/lerna/lerna) in particular? In case you missed it, Nrwl, the company behind Nx, [took over stewardship of Lerna](https://blog.nrwl.io/lerna-is-dead-long-live-lerna-61259f97dbd9). This allows for a much better integration between the two. [Read more in our dedicated guide](/migration/lerna-and-nx).
|
||||
{% /callout %}
|
||||
|
||||
**Short story:** you can use Nx easily together with your current Lerna/Yarn/PNPM/NPM monorepo setup. Why? To speed up
|
||||
@ -37,9 +37,9 @@ If you are familiar with Turborepo, check out [this guide](/guides/turbo-and-nx)
|
||||
This sets up [Nx core](/getting-started/nx-core) in your existing monorepo which comes with a series of interesting
|
||||
features that help intelligenty schedule tasks and make sure operations are quick:
|
||||
|
||||
- **Run any npm script -** with Nx installed, you can use it's powerful task scheduler which automatically picks up your
|
||||
- **Run any npm script -** with Nx installed, you can use its powerful task scheduler which automatically picks up your
|
||||
npm scripts from your package's script section. For instance if package `myproj` has a `build` script, you can just
|
||||
run it using `nx build myproj`. Similarly for running tests use `nx test myproj` and so on.
|
||||
run it using `nx build myproj`. Similarly, for running tests use `nx test myproj` and so on.
|
||||
- **Parallelization and task dependencies -** Nx
|
||||
automatically [knows how your projects relate to each other](/structure/dependency-graph). As a result, if `project-a`
|
||||
depends on `project-b` and you run `nx build project-a`, Nx first runs the builds for all of `project-a`'s
|
||||
@ -63,7 +63,7 @@ features that help intelligenty schedule tasks and make sure operations are quic
|
||||
|
||||
## Looking for integrating Lerna and Nx?
|
||||
|
||||
Check out our dedicated guide: [Lerna and Nx](/guides/lerna-and-nx)
|
||||
Check out our dedicated guide: [Lerna and Nx](/migration/lerna-and-nx)
|
||||
|
||||
## Further customizations
|
||||
|
||||
|
||||
@ -103,8 +103,6 @@ nx serve my-application
|
||||
|
||||
If this doesn’t work for you, you may need to add or modify some configuration on the `build` task in your workspace configuration file.
|
||||
|
||||
[Learn more about local serving](/cli/serve)
|
||||
|
||||
### Unit tests
|
||||
|
||||
Each application will have a unit test process defined by your choices (Jest or Karma) during the creation of the application. To run tests for your application:
|
||||
@ -117,8 +115,6 @@ It is recommended that unit tests live next to the code they exercise and code s
|
||||
|
||||
Testing configuration files can be found in the root of your application as well as the workspace configuration file.
|
||||
|
||||
[Learn more about unit testing](/cli/test)
|
||||
|
||||
### End to End Tests
|
||||
|
||||
Each application will have an e2e configuration created as a separate application, appended with `-e2e`. In our example, you’ll see `my-application-e2e`. This `e2e` task uses the test runner you chose during generation, Protractor or Cypress. Your application’s e2e tests should be migrated to this directory. There will be an e2e test scaffolded for you to make sure everything works before you start adding your own. To run the e2e tests:
|
||||
@ -127,9 +123,7 @@ Each application will have an e2e configuration created as a separate applicatio
|
||||
nx e2e my-application-e2e
|
||||
```
|
||||
|
||||
All of the configuration for your e2e tests should be in this directory.
|
||||
|
||||
[Learn more about end-to-end testing](/cli/e2e)
|
||||
All the configuration for your e2e tests should be in this directory.
|
||||
|
||||
### Linting
|
||||
|
||||
@ -149,8 +143,6 @@ nx lint my-application
|
||||
|
||||
Global configuration files for linting will be at the root of your workspace. Each application and library will extend those configuration files. Global configuration changes should be made in the root, while application-or-library-specific changes should occur in the application or library configuration files.
|
||||
|
||||
[Learn more about linting](/cli/lint)
|
||||
|
||||
### Formatting
|
||||
|
||||
Nx uses Prettier to ensure standard formatting across your codebase. Prettier configuration files are located in the root of the workspace. To format your workspace run:
|
||||
@ -159,7 +151,7 @@ Nx uses Prettier to ensure standard formatting across your codebase. Prettier co
|
||||
nx format:write
|
||||
```
|
||||
|
||||
[Learn more about formatting](/cli/format-write)
|
||||
[Learn more about formatting](/nx/format-write)
|
||||
|
||||
### Adding tasks
|
||||
|
||||
|
||||
@ -187,7 +187,7 @@ Note `all the projects affected by a PR/commit`. This is very important. Monorep
|
||||
- The performance of CI checks will degrade over time. The time it takes to run the CI checks should be proportional to the impact of the change, not the size of the repo.
|
||||
- We will be affected by the code your change didn’t touch
|
||||
|
||||
We should utilize `affected:*` commands to build and test projects. Read more about them [here](/cli/affected).
|
||||
We should utilize `affected:*` commands to build and test projects. Read more about them [here](/nx/affected).
|
||||
|
||||
### Trunk-based development
|
||||
|
||||
|
||||
@ -147,7 +147,7 @@ Running `nx test complex` should work now.
|
||||
This example uses Yarn to connect the two packages. Most of the time, however, there are better ways to do it. The React,
|
||||
Node and Angular plugins for Nx allow different projects in your workspace to import each other without having to maintain
|
||||
cumbersome `package.json` files. Instead, they use Webpack, Rollup and Jest plugins to enable this use case in a more
|
||||
elegant way. [Read about the relationship between Nx and Yarn/Lerna/PNPM](/guides/lerna-and-nx).
|
||||
elegant way. [Read about the relationship between Nx and Yarn/Lerna/PNPM](/migration/lerna-and-nx).
|
||||
|
||||
## What Nx Core Provides
|
||||
|
||||
|
||||
@ -65,15 +65,15 @@ Replace `your-lib-name` with the app's name as defined in your workspace.json fi
|
||||
|
||||
## Using React Native
|
||||
|
||||
- [run-ios](/react-native/run-ios) - Builds your app and starts it on iOS simulator or device
|
||||
- [run-android](/react-native/run-android) - Builds your app and starts it on a connected Android emulator or device
|
||||
- [build-android](/react-native/build-android) - Release Build for Android
|
||||
- [start](/react-native/package) - Starts the server that communicates with connected devices
|
||||
- [bundle](/web/package) - Builds the JavaScript bundle for offline use
|
||||
- [sync-deps](/react-native/sync-deps) - Syncs dependencies to package.json (required for autolinking)
|
||||
- [ensure-symlink](/react-native/ensure-symlink) - Ensure workspace node_modules is symlink under app's node_modules folder
|
||||
- [run-ios](/packages/react-native/executors/run-ios) - Builds your app and starts it on iOS simulator or device
|
||||
- [run-android](/packages/react-native/executors/run-android) - Builds your app and starts it on a connected Android emulator or device
|
||||
- [build-android](/packages/react-native/executors/build-android) - Release Build for Android
|
||||
- [start](/packages/react-native/executors/start) - Starts the server that communicates with connected devices
|
||||
- [bundle](/packages/react-native/executors/bundle) - Builds the JavaScript bundle for offline use
|
||||
- [sync-deps](/packages/react-native/executors/sync-deps) - Syncs dependencies to package.json (required for autolinking)
|
||||
- [ensure-symlink](/packages/react-native/executors/ensure-symlink) - Ensure workspace node_modules is symlink under app's node_modules folder
|
||||
|
||||
## More Documentation
|
||||
|
||||
- [Using Detox](/detox/overview)
|
||||
- [Using Jest](/jest/overview)
|
||||
- [Using Detox](/packages/detox)
|
||||
- [Using Jest](/packages/jest)
|
||||
|
||||
@ -56,4 +56,4 @@ To run the executor for all affected projects:
|
||||
nx affected --target=make
|
||||
```
|
||||
|
||||
For more information, see the [nx affected](/cli/affected).
|
||||
For more information, see the [nx affected](/nx/affected).
|
||||
|
||||
@ -55,7 +55,7 @@ Each executor definition has an `executor` property and, optionally, an `options
|
||||
|
||||
## Running executors
|
||||
|
||||
The [`nx run`](/cli/run) cli command (or the shorthand versions) can be used to run executors.
|
||||
The [`nx run`](/nx/run) cli command (or the shorthand versions) can be used to run executors.
|
||||
|
||||
```bash
|
||||
nx run [project]:[command]
|
||||
@ -272,5 +272,5 @@ export default async function (opts) {
|
||||
|
||||
## See Also
|
||||
|
||||
- [`nx affected`](/cli/affected)
|
||||
- [`nx run-many`](/cli/run-many)
|
||||
- [`nx affected`](/nx/affected)
|
||||
- [`nx run-many`](/nx/run-many)
|
||||
|
||||
@ -15,7 +15,7 @@ Run the `nx help` command to see a full list of commands in the Nx CLI.
|
||||
|
||||
## Acting on Code
|
||||
|
||||
The [`nx run` command](/cli/run) executes a target on a single project. For convenience, you can also
|
||||
The [`nx run` command](/nx/run) executes a target on a single project. For convenience, you can also
|
||||
run `nx [target] [project]` which is an alias to `nx run [project]:[target]`.
|
||||
|
||||
```bash
|
||||
@ -36,14 +36,14 @@ argument you pass into `run` will be forwarded to the executor or the npm script
|
||||
Along with running a target on a single project, Nx provides some commands to run the same target across multiple
|
||||
projects.
|
||||
|
||||
The [`nx run-many` command](/cli/run-many) runs the same target name across a list of projects.
|
||||
The [`nx run-many` command](/nx/run-many) runs the same target name across a list of projects.
|
||||
|
||||
```bash
|
||||
nx run-many --target=build --projects=app1,app2
|
||||
nx run-many --target=test --all # Runs all projects that have a test target, use this sparingly.
|
||||
```
|
||||
|
||||
The [`nx affected` command](/cli/affected) isolates the set projects that may have changed in behavior and
|
||||
The [`nx affected` command](/nx/affected) isolates the set projects that may have changed in behavior and
|
||||
runs a target across them. This is more efficient than running all projects every time.
|
||||
|
||||
```bash
|
||||
@ -52,7 +52,7 @@ nx affected --target=build
|
||||
|
||||
## Modifying Code
|
||||
|
||||
The [`nx generate` command](/cli/generate) generates and modifies code.
|
||||
The [`nx generate` command](/nx/generate) generates and modifies code.
|
||||
|
||||
```bash
|
||||
nx generate @nrwl/js:lib my-lib
|
||||
@ -61,12 +61,12 @@ nx generate @nrwl/react:storybook-configuration shared-button # Configures story
|
||||
```
|
||||
|
||||
Again, like `nx run`, `nx generate` is only an abstraction over generating code. `nx generate` can generate anything you
|
||||
want via **generators**. **[Generators](/generators/using-schematics)** can be installed as part of a
|
||||
want via **generators**. **[Generators](/generators/using-generators)** can be installed as part of a
|
||||
plugin or developed locally within an Nx workspace to fit the needs of your organization.
|
||||
|
||||
A [workspace generator](/generators/workspace-generators) is a custom generator for your
|
||||
workspace. `nx generate workspace-generator my-generator` generates a workspace generator which can be run with
|
||||
the [`nx workspace-generator` command](/cli/workspace-generator). This can be useful to allow your
|
||||
the [`nx workspace-generator` command](/nx/workspace-generator). This can be useful to allow your
|
||||
organization to consistently generate projects according to your own standards.
|
||||
|
||||
```bash
|
||||
@ -74,7 +74,7 @@ nx workspace-generator my-generator
|
||||
```
|
||||
|
||||
Upgrading a package is not always as simple as bumping the version in `package.json`.
|
||||
The [`nx migrate` command](/cli/migrate) facilitates not only managing package versions but also runs
|
||||
The [`nx migrate` command](/nx/migrate) facilitates not only managing package versions but also runs
|
||||
migrations specified by package maintainers. See
|
||||
the [full guide to updating Nx](/using-nx/updating-nx).
|
||||
|
||||
@ -86,11 +86,11 @@ nx migrate --run-migrations # Runs the migrations scheduled by the previous comm
|
||||
## Understanding the codebase
|
||||
|
||||
Nx creates and maintains a project graph between projects based on import statements in your code and uses that
|
||||
information to run executors only on the [affected](/cli/affected) projects in a codebase. A visual
|
||||
information to run executors only on the [affected](/nx/affected) projects in a codebase. A visual
|
||||
version of the [project project graph](/structure/dependency-graph) is also available to help developers
|
||||
understand the architecture of the codebase.
|
||||
|
||||
The [`nx graph` command](/cli/dep-graph) displays this project graph in a web browser for you to
|
||||
The [`nx graph` command](/nx/dep-graph) displays this project graph in a web browser for you to
|
||||
explore.
|
||||
|
||||
{% callout type="note" title="Previously" %}
|
||||
@ -103,7 +103,7 @@ nx graph --watch # Updates the browser as code is changed
|
||||
nx affected:graph # Highlights projects which may have changed in behavior
|
||||
```
|
||||
|
||||
The [`nx list` command](/cli/list) lists the currently installed Nx plugins and other available plugins.
|
||||
The [`nx list` command](/nx/list) lists the currently installed Nx plugins and other available plugins.
|
||||
The `nx list` command can list the generators and executors that are available for a plugin.
|
||||
|
||||
**List installed plugins:**
|
||||
|
||||
@ -9,7 +9,7 @@ Codifying your organization's best practices into workspace generators is a grea
|
||||
## Reorganizing Projects
|
||||
|
||||
After some time of working within a workspace, projects might need to be moved or sometimes even removed.
|
||||
The workspace plugin provides the [`@nrwl/workspace:move`](/workspace/move) and [`@nrwl/workspace:remove`](/workspace/remove) generators to help aid with this.
|
||||
The 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.
|
||||
|
||||
### Moving Projects
|
||||
|
||||
@ -22,9 +22,9 @@ Moving the files manually can be done easily but a lot of steps are often missed
|
||||
3. The path mapping in `tsconfig.base.json` will be changed to `@npmScope/new/location/my-lib`
|
||||
4. Imports in other projects will be changed to `@npmScope/new/location/my-lib`
|
||||
5. Paths in target options such as output path will be changed
|
||||
6. Other configuration will be updated too such as `extends` in `tsconfig.json`, the name of the project in `jest.config.js`, and the extends in `.eslintrc.json`
|
||||
6. Other configuration will be updated too, such as `extends` in `tsconfig.json`, the name of the project in `jest.config.js`, and the extends in `.eslintrc.json`
|
||||
|
||||
> See more about [`@nrwl/workspace:move`](/workspace/move)
|
||||
> See more about [`@nrwl/workspace:move`](/packages/workspace/generators/move)
|
||||
|
||||
### Removing Projects
|
||||
|
||||
@ -37,7 +37,7 @@ Like when moving projects, some steps are often missed when removing projects. T
|
||||
3. The project's configuration will be removed.
|
||||
4. The path mapping in `tsconfig.base.json` will be removed.
|
||||
|
||||
> See more about [`@nrwl/workspace:remove`](/workspace/remove)
|
||||
> See more about [`@nrwl/workspace:remove`](/packages/workspace/generators/remove)
|
||||
|
||||
## Running custom commands
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ Libraries should be grouped by _scope_. A library's scope is either application
|
||||
|
||||
## Move Generator
|
||||
|
||||
Don't be too anxious about choosing the exact right folder structure from the beginning. Libraries can be moved or renamed using the [`@nrwl/workspace:move` generator](/workspace/move).
|
||||
Don't be too anxious about choosing the exact right folder structure from the beginning. Libraries can be moved or renamed using the [`@nrwl/workspace:move` generator](/packages/workspace/generators/move).
|
||||
|
||||
For instance, if a library under the `booking` folder is now being shared by multiple apps, you can move it to the shared folder like this:
|
||||
|
||||
@ -18,7 +18,7 @@ For Angular projects, you should use the [`@nrwl/angular:move` generator](/packa
|
||||
|
||||
## Remove Generator
|
||||
|
||||
Similarly, if you no longer need a library, you can remove it with the [`@nrwl/workspace:remove` generator](/workspace/remove).
|
||||
Similarly, if you no longer need a library, you can remove it with the [`@nrwl/workspace:remove` generator](/packages/workspace/generators/remove).
|
||||
|
||||
```bash
|
||||
nx g remove booking-some-library
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user