diff --git a/.gitignore b/.gitignore index 85bceb664e..c5d75639db 100644 --- a/.gitignore +++ b/.gitignore @@ -13,3 +13,4 @@ jest.debug.config.js /.nx-cache /.verdaccio/build/local-registry dep-graph/client/src/assets/environment.js +/nx-dev/nx-dev/public/documentation diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index bd6586f3e9..6c8c861555 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -117,15 +117,14 @@ We would love for you to contribute to our documentation as well! Please feel we #### Documentation Pages -Our documentation pages can be found within this repo under the `docs` directory. Pages that we consider framework specific are nested in their own subdirectories - otherwise they should be nested within the `docs/shared` directory. +Our documentation pages can be found within this repo under the `docs` directory. The `docs/map.json` file is considered our source of truth for our site's structure, and should be updated when adding a new page to our documentation to ensure that it is included in the documentation site. We also run automated scripts based on this `map.json` data to safeguard against common human errors that could break our site. #### Nx-Dev Application Our public `nx.dev` documentation site is a [Next.js](https://nextjs.org/) application, that can be found in the `nx-dev` directory of this repo. - -The `nx-dev/nx-dev/public/documentation` directory contains `.md` files that are generated from the `docs` directory when new releases are cut. As such, these should not be changed when submitting a change to existing docs. +The documentation site is consuming the `docs/` directly by copy-ing its content while deploying, so the website is always in sync and reflects the latest version of `docs/`. Jump to [Running the Documentation Site Locally](#running-the-documentation-site-locally) to see how to preview your changes while serving. @@ -153,10 +152,6 @@ npx nx serve nx-dev You can then access the application locally at `localhost:4200`. -By default, the site displays the `Latest` cut release of the docs. To see your current changes in the docs be sure to select `Preview` from the version selection box of the site. - -Selecting Preview from Version Selection box - #### Troubleshooting: `JavaScript heap out of memory` If you see an error that states: `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`, you need to [increase the max memory size of V8's old memory section](https://nodejs.org/api/cli.html#--max-old-space-sizesize-in-megabytes): diff --git a/images/selecting-preview-from-version-selection-box.png b/images/selecting-preview-from-version-selection-box.png deleted file mode 100644 index fe74e7c2aa..0000000000 Binary files a/images/selecting-preview-from-version-selection-box.png and /dev/null differ diff --git a/nx-dev/nx-dev/next.config.js b/nx-dev/nx-dev/next.config.js index d8f3568811..adbf3056a6 100644 --- a/nx-dev/nx-dev/next.config.js +++ b/nx-dev/nx-dev/next.config.js @@ -1,5 +1,16 @@ // nx-ignore-next-line const withNx = require('@nrwl/next/plugins/with-nx'); +const { copy } = require('fs-extra'); +const path = require('node:path'); + +/** + * TODO@ben: Temporary solution before Nextjs' assets management tasks is up and running + */ +copy( + path.resolve(__dirname + '/../../docs'), + path.resolve(__dirname + '/public/documentation'), + { overwrite: true } +); const redirects = { '/core-concepts/configuration': '/configuration/projectjson', diff --git a/nx-dev/nx-dev/pages/_app.tsx b/nx-dev/nx-dev/pages/_app.tsx index c4c2d2e175..d1ef3cf553 100644 --- a/nx-dev/nx-dev/pages/_app.tsx +++ b/nx-dev/nx-dev/pages/_app.tsx @@ -4,8 +4,8 @@ import Head from 'next/head'; import { useRouter } from 'next/router'; import { DefaultSeo } from 'next-seo'; import { sendPageViewEvent } from '@nrwl/nx-dev/feature-analytics'; -import '../styles/main.css'; import Script from 'next/script'; +import '../styles/main.css'; export default function CustomApp({ Component, pageProps }: AppProps) { const router = useRouter(); diff --git a/nx-dev/nx-dev/project.json b/nx-dev/nx-dev/project.json index dd17c559dd..82d2f65888 100644 --- a/nx-dev/nx-dev/project.json +++ b/nx-dev/nx-dev/project.json @@ -23,17 +23,6 @@ "command": "npx next-sitemap --config ./nx-dev/nx-dev/next-sitemap.js" } }, - "serve": { - "executor": "@nrwl/workspace:run-commands", - "outputs": [], - "options": { - "commands": [ - "npx ts-node -P ./scripts/tsconfig.scripts.json ./scripts/documentation/nx-dev-docs-latest-sync.ts --watch", - "nx run nx-dev:serve-nextjs" - ], - "parallel": true - } - }, "sync-documentation": { "executor": "@nrwl/workspace:run-commands", "outputs": ["nx-dev/nx-dev/public/documentation"], @@ -52,7 +41,7 @@ "production": {} } }, - "serve-nextjs": { + "serve": { "executor": "@nrwl/next:server", "options": { "buildTarget": "nx-dev:build-base", @@ -70,9 +59,7 @@ "outputs": ["nx-dev/nx-dev/public/documentation"], "options": { "commands": [ - "rm -r nx-dev/nx-dev/public/documentation", - "cp -R docs nx-dev/nx-dev/public/", - "mv nx-dev/nx-dev/public/docs nx-dev/nx-dev/public/documentation", + "echo \"🛑️ REPLACE ME WITH STANDARD BUILD COMMAND 🛑\"", "nx run nx-dev:build" ], "parallel": false diff --git a/nx-dev/nx-dev/public/documentation/builders.json b/nx-dev/nx-dev/public/documentation/builders.json deleted file mode 100644 index ee16974bd1..0000000000 --- a/nx-dev/nx-dev/public/documentation/builders.json +++ /dev/null @@ -1,12 +0,0 @@ -[ - "cypress", - "express", - "jest", - "linter", - "nest", - "node", - "storybook", - "web", - "workspace", - "js" -] diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/delegate-build.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/delegate-build.md deleted file mode 100644 index 254b3874aa..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/delegate-build.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: '@nrwl/angular:delegate-build executor' -description: 'Delegates the build to a different target while supporting incremental builds.' ---- - -# @nrwl/angular:delegate-build - -Delegates the build to a different target while supporting incremental builds. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### buildTarget (_**required**_) - -Type: `string` - -Build target used for building the application after its dependencies have been built. - -### outputPath (_**required**_) - -Type: `string` - -The full path for the output directory, relative to the workspace root. - -### tsConfig (_**required**_) - -Type: `string` - -The full path for the TypeScript configuration file, relative to the workspace root. - -### watch - -Default: `false` - -Type: `boolean` - -Whether to run a build when any file changes. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/ng-packagr-lite.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/ng-packagr-lite.md deleted file mode 100644 index 2e6d819931..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/ng-packagr-lite.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: '@nrwl/angular:ng-packagr-lite executor' -description: 'Builds a library with support for incremental builds.' ---- - -# @nrwl/angular:ng-packagr-lite - -Builds a library with support for incremental builds. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### project (_**required**_) - -Type: `string` - -The file path for the ng-packagr configuration file, relative to the workspace root. - -### buildableProjectDepsInPackageJsonType - -Default: `peerDependencies` - -Type: `string` - -Possible values: `dependencies`, `peerDependencies` - -When `updateBuildableProjectDepsInPackageJson` is `true`, this adds dependencies to either `peerDependencies` or `dependencies`. - -### tailwindConfig - -Type: `string` - -The full path for the Tailwind configuration file, relative to the workspace root. If not provided and a `tailwind.config.js` file exists in the project or workspace root, it will be used. Otherwise, Tailwind will not be configured. - -### tsConfig - -Type: `string` - -The full path for the TypeScript configuration file, relative to the workspace root. - -### updateBuildableProjectDepsInPackageJson - -Default: `true` - -Type: `boolean` - -Whether to update the buildable project dependencies in package.json. - -### watch - -Default: `false` - -Type: `boolean` - -Whether to run a build when any file changes. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/package.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/package.md deleted file mode 100644 index 5fa64ae3e3..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/package.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: '@nrwl/angular:package executor' -description: 'Builds and packages an Angular library to be distributed as an NPM package. It supports incremental builds.' ---- - -# @nrwl/angular:package - -Builds and packages an Angular library to be distributed as an NPM package. It supports incremental builds. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### project (_**required**_) - -Type: `string` - -The file path for the ng-packagr configuration file, relative to the workspace root. - -### buildableProjectDepsInPackageJsonType - -Default: `peerDependencies` - -Type: `string` - -Possible values: `dependencies`, `peerDependencies` - -When `updateBuildableProjectDepsInPackageJson` is `true`, this adds dependencies to either `peerDependencies` or `dependencies`. - -### tailwindConfig - -Type: `string` - -The full path for the Tailwind configuration file, relative to the workspace root. If not provided and a `tailwind.config.js` file exists in the project or workspace root, it will be used. Otherwise, Tailwind will not be configured. - -### tsConfig - -Type: `string` - -The full path for the TypeScript configuration file, relative to the workspace root. - -### updateBuildableProjectDepsInPackageJson - -Default: `true` - -Type: `boolean` - -Whether to update the buildable project dependencies in package.json. - -### watch - -Default: `false` - -Type: `boolean` - -Whether to run a build when any file changes. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/webpack-browser.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/webpack-browser.md deleted file mode 100644 index 55c3bfbfb4..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/webpack-browser.md +++ /dev/null @@ -1,300 +0,0 @@ ---- -title: '@nrwl/angular:webpack-browser executor' -description: 'Builds a browser application with support for incremental builds and custom webpack configuration.' ---- - -# @nrwl/angular:webpack-browser - -Builds a browser application with support for incremental builds and custom webpack configuration. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### index (_**required**_) - -Type: `string` - -Configures the generation of the application's HTML index. - -### main (_**required**_) - -Type: `string` - -The full path for the main entry point to the app, relative to the current workspace. - -### outputPath (_**required**_) - -Type: `string` - - The full path for the new output directory, relative to the current workspace. - -By default, writes output to a folder named dist/ in the current project. - -### tsConfig (_**required**_) - -Type: `string` - -The full path for the TypeScript configuration file, relative to the current workspace. - -### allowedCommonJsDependencies - -Type: `array` - -A list of CommonJS packages that are allowed to be used without a build time warning. - -### aot - -Default: `true` - -Type: `boolean` - -Build using Ahead of Time compilation. - -### assets - -Type: `array` - -List of static application assets. - -### baseHref - -Type: `string` - -Base url for the application being built. - -### budgets - -Type: `array` - -Budget thresholds to ensure parts of your application stay within boundaries which you set. - -### buildOptimizer - -Default: `true` - -Type: `boolean` - -Enables '@angular-devkit/build-optimizer' optimizations when using the 'aot' option. - -### commonChunk - -Default: `true` - -Type: `boolean` - -Generate a seperate bundle containing code used across multiple bundles. - -### crossOrigin - -Default: `none` - -Type: `string` - -Possible values: `none`, `anonymous`, `use-credentials` - -Define the crossorigin attribute setting of elements that provide CORS support. - -### deleteOutputPath - -Default: `true` - -Type: `boolean` - -Delete the output path before building. - -### ~~deployUrl~~ - -Type: `string` - -**Deprecated:** Use "baseHref" option, "APP_BASE_HREF" DI token or a combination of both instead. For more information, see https://angular.io/guide/deployment#the-deploy-url. - -URL where files will be deployed. - -### extractLicenses - -Default: `true` - -Type: `boolean` - -Extract all licenses in a separate file. - -### fileReplacements - -Type: `array` - -Replace compilation source files with other compilation source files in the build. - -### i18nMissingTranslation - -Default: `warning` - -Type: `string` - -Possible values: `warning`, `error`, `ignore` - -How to handle missing translations for i18n. - -### inlineStyleLanguage - -Default: `css` - -Type: `string` - -Possible values: `css`, `less`, `sass`, `scss` - -The stylesheet language to use for the application's inline component styles. - -### localize - -Type: `boolean | boolean[] ` - -Translate the bundles in one or more locales. - -### namedChunks - -Default: `false` - -Type: `boolean` - -Use file name for lazy loaded chunks. - -### ngswConfigPath - -Type: `string` - -Path to ngsw-config.json. - -### optimization - -Default: `true` - -Type: `boolean` - -Enables optimization of the build output. Including minification of scripts and styles, tree-shaking, dead-code elimination, inlining of critical CSS and fonts inlining. For more information, see https://angular.io/guide/workspace-config#optimization-configuration. - -### outputHashing - -Default: `none` - -Type: `string` - -Possible values: `none`, `all`, `media`, `bundles` - -Define the output filename cache-busting hashing mode. - -### poll - -Type: `number` - -Enable and define the file watching poll time period in milliseconds. - -### polyfills - -Type: `string` - -The full path for the polyfills file, relative to the current workspace. - -### preserveSymlinks - -Type: `boolean` - -Do not use the real path when resolving modules. If unset then will default to `true` if NodeJS option --preserve-symlinks is set. - -### progress - -Default: `true` - -Type: `boolean` - -Log progress to the console while building. - -### resourcesOutputPath - -Type: `string` - -The path where style resources will be placed, relative to outputPath. - -### scripts - -Type: `array` - -Global scripts to be included in the build. - -### serviceWorker - -Default: `false` - -Type: `boolean` - -Generates a service worker config for production builds. - -### ~~showCircularDependencies~~ - -Default: `false` - -Type: `boolean` - -**Deprecated:** The recommended method to detect circular dependencies in project code is to use either a lint rule or other external tooling. - -Show circular dependency warnings on builds. - -### sourceMap - -Default: `false` - -Type: `boolean` - -Output source maps for scripts and styles. For more information, see https://angular.io/guide/workspace-config#source-map-configuration. - -### statsJson - -Default: `false` - -Type: `boolean` - -Generates a 'stats.json' file which can be analyzed using tools such as 'webpack-bundle-analyzer'. - -### styles - -Type: `array` - -Global styles to be included in the build. - -### subresourceIntegrity - -Default: `false` - -Type: `boolean` - -Enables the use of subresource integrity validation. - -### vendorChunk - -Default: `false` - -Type: `boolean` - -Generate a seperate bundle containing only vendor libraries. This option should only used for development. - -### verbose - -Default: `false` - -Type: `boolean` - -Adds more details to output logging. - -### watch - -Default: `false` - -Type: `boolean` - -Run build when files change. - -### webWorkerTsConfig - -Type: `string` - -TypeScript configuration for Web Worker modules. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/webpack-server.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/webpack-server.md deleted file mode 100644 index 8cecec6f6e..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/executors/webpack-server.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -title: '@nrwl/angular:webpack-server executor' -description: 'Serves a browser application with support for a custom webpack configuration.' ---- - -# @nrwl/angular:webpack-server - -Serves a browser application with support for a custom webpack configuration. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### browserTarget (_**required**_) - -Type: `string` - -A browser builder target to serve in the format of `project:target[:configuration]`. You can also pass in more than one configuration name as a comma-separated list. Example: `project:target:production,staging`. - -### allowedHosts - -Type: `array` - -List of hosts that are allowed to access the dev server. - -### disableHostCheck - -Default: `false` - -Type: `boolean` - -Don't verify connected clients are part of allowed hosts. - -### hmr - -Default: `false` - -Type: `boolean` - -Enable hot module replacement. - -### host - -Default: `localhost` - -Type: `string` - -Host to listen on. - -### liveReload - -Default: `true` - -Type: `boolean` - -Whether to reload the page on change, using live-reload. - -### open - -Alias(es): o - -Default: `false` - -Type: `boolean` - -Opens the url in default browser. - -### poll - -Type: `number` - -Enable and define the file watching poll time period in milliseconds. - -### port - -Default: `4200` - -Type: `number` - -Port to listen on. - -### proxyConfig - -Type: `string` - -Proxy configuration file. For more information, see https://angular.io/guide/build#proxying-to-a-backend-server. - -### publicHost - -Type: `string` - -The URL that the browser client (or live-reload client, if enabled) should use to connect to the development server. Use for a complex dev server setup, such as one with reverse proxies. - -### servePath - -Type: `string` - -The pathname where the app will be served. - -### ssl - -Default: `false` - -Type: `boolean` - -Serve using HTTPS. - -### sslCert - -Type: `string` - -SSL certificate to use for serving HTTPS. - -### sslKey - -Type: `string` - -SSL key to use for serving HTTPS. - -### verbose - -Type: `boolean` - -Adds more details to output logging. - -### watch - -Default: `true` - -Type: `boolean` - -Rebuild on change. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/application.md deleted file mode 100644 index f8386b964e..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/application.md +++ /dev/null @@ -1,234 +0,0 @@ ---- -title: '@nrwl/angular:application generator' -description: 'Creates an Angular application.' ---- - -# @nrwl/angular:application - -Creates an Angular application. - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the application. - -### addTailwind - -Default: `false` - -Type: `boolean` - -Whether to configure TailwindCSS for the application. - -### backendProject - -Type: `string` - -Backend project that provides data to this application. This sets up `proxy.config.json`. - -### directory - -Type: `string` - -The directory of the new application. - -### e2eTestRunner - -Default: `cypress` - -Type: `string` - -Possible values: `protractor`, `cypress`, `none` - -Test runner to use for end to end (e2e) tests. - -### host - -Type: `string` - -The name of the host application that the remote application will be consumed by. - -### inlineStyle - -Alias(es): s - -Default: `false` - -Type: `boolean` - -Specifies if the style will be in the ts file. - -### inlineTemplate - -Alias(es): t - -Default: `false` - -Type: `boolean` - -Specifies if the template will be in the ts file. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `none` - -The tool to use for running lint checks. - -### mfe - -Default: `false` - -Type: `boolean` - -Generate a Module Federation configuration for the application - -### mfeType - -Default: `remote` - -Type: `string` - -Possible values: `host`, `remote` - -Type of application to generate the Module Federation configuration for. - -### port - -Type: `number` - -The port at which the remote application should be served. - -### prefix - -Alias(es): p - -Type: `string` - -The prefix to apply to generated selectors. - -### remotes - -Type: `array` - -A list of remote application names that the host application should consume. - -### routing - -Default: `false` - -Type: `boolean` - -Generate a routing module. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add dependencies to `package.json`. - -### skipTests - -Alias(es): S - -Default: `false` - -Type: `boolean` - -Skip creating spec files. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into `/project.json` rather than including it inside `workspace.json`. - -### strict - -Default: `true` - -Type: `boolean` - -Create an application with stricter type checking and build optimization options. - -### style - -Default: `css` - -Type: `string` - -Possible values: `css`, `scss`, `sass`, `less` - -The file extension to be used for style files. - -### tags - -Type: `string` - -Add tags to the application (used for linting). - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `karma`, `jest`, `none` - -Test runner to use for unit tests. - -### viewEncapsulation - -Type: `string` - -Possible values: `Emulated`, `Native`, `None` - -Specifies the view encapsulation strategy. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/convert-tslint-to-eslint.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/convert-tslint-to-eslint.md deleted file mode 100644 index db65a46a8a..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/convert-tslint-to-eslint.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: '@nrwl/angular:convert-tslint-to-eslint generator' -description: 'Converts a project from TSLint to ESLint.' ---- - -# @nrwl/angular:convert-tslint-to-eslint - -Converts a project from TSLint to ESLint. - -## Usage - -```bash -nx generate convert-tslint-to-eslint ... -``` - -By default, Nx will search for `convert-tslint-to-eslint` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:convert-tslint-to-eslint ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g convert-tslint-to-eslint ... --dry-run -``` - -### Examples - -The following will first configure the project, `myapp`, the same way a _new_ project is configured i.e. It will use Nx's new recommended ESLint config. By default, this also adds the existing TSLint configuration on top of the default ESLint config from Nx to continue checking what it checks today. This is done by migrating TSLint rules to their equivalent ESLint rules to the best of its abilities. Some TSLint rules may not have ESLint equivalents and will be reported during the conversion: - -```bash -nx g convert-tslint-to-eslint myapp -``` - -If your TSLint config isn't extremely important to you, ignoring it makes this process more deterministic. Unlike the prior example, this will discard the existing TSLint configuration, meaning that the project will only have the Nx's latest recommended ESLint configuration which may be good enough for some workspaces: - -```bash -nx g convert-tslint-to-eslint myapp --ignoreExistingTslintConfig=true -``` - -By default, this process removes the TSLint related dependencies and configuration once no more projects use TSLint. This can be disabled with the following flag to keep TSLint related dependencies and configuration in the repo: - -```bash -nx g convert-tslint-to-eslint myapp --removeTSLintIfNoMoreTSLintTargets=false -``` - -## Options - -### project (_**required**_) - -Type: `string` - -The name of the Angular project to convert. Please note, if the project is an Angular app with an associated Cypress e2e project, it will also attempt to convert that. - -### ignoreExistingTslintConfig - -Default: `false` - -Type: `boolean` - -If true, it will not use existing TSLint config as a reference, it will just reset the project with the latest recommended ESLint config. - -### removeTSLintIfNoMoreTSLintTargets - -Default: `true` - -Type: `boolean` - -If this conversion leaves no more TSLint usage in the workspace, it will remove TSLint and related dependencies and configuration. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/downgrade-module.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/downgrade-module.md deleted file mode 100644 index 99ac2aa89b..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/downgrade-module.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: '@nrwl/angular:downgrade-module generator' -description: 'Sets up a Downgrade Module.' ---- - -# @nrwl/angular:downgrade-module - -Sets up a Downgrade Module. - -## Usage - -```bash -nx generate downgrade-module ... -``` - -By default, Nx will search for `downgrade-module` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:downgrade-module ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g downgrade-module ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the main AngularJS module. - -### project (_**required**_) - -Type: `string` - -The name of the project. - -### angularJsImport - -Type: `string` - -Import expression of the AngularJS application (e.g., `--angularJsImport=some_node_module/my_app`). - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add `@angular/upgrade` to `package.json` (e.g., `--skipPackageJson`). diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/karma-project.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/karma-project.md deleted file mode 100644 index 12923a4179..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/karma-project.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: '@nrwl/angular:karma-project generator' -description: 'Adds Karma configuration to a project.' ---- - -# @nrwl/angular:karma-project - -Adds Karma configuration to a project. - -## Usage - -```bash -nx generate karma-project ... -``` - -By default, Nx will search for `karma-project` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:karma-project ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g karma-project ... --dry-run -``` - -## Options - -### project (_**required**_) - -Type: `string` - -The name of the project. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/karma.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/karma.md deleted file mode 100644 index 0e8c839427..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/karma.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: '@nrwl/angular:karma generator' -description: 'Adds Karma configuration to a workspace.' ---- - -# @nrwl/angular:karma - -Adds Karma configuration to a workspace. - -## Usage - -```bash -nx generate karma ... -``` - -By default, Nx will search for `karma` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:karma ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g karma ... --dry-run -``` - -## Options - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add dependencies to `package.json`. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/library-secondary-entry-point.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/library-secondary-entry-point.md deleted file mode 100644 index dd63569655..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/library-secondary-entry-point.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: '@nrwl/angular:library-secondary-entry-point generator' -description: 'Creates a secondary entry point for an Angular publishable library.' ---- - -# @nrwl/angular:library-secondary-entry-point - -Creates a secondary entry point for an Angular publishable library. - -## Usage - -```bash -nx generate library-secondary-entry-point ... -``` - -```bash -nx g secondary-entry-point ... # same -``` - -By default, Nx will search for `library-secondary-entry-point` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:library-secondary-entry-point ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g library-secondary-entry-point ... --dry-run -``` - -## Options - -### library (_**required**_) - -Type: `string` - -The name of the library to create the secondary entry point for. - -### name (_**required**_) - -Type: `string` - -The name of the secondary entry point. - -### skipModule - -Default: `false` - -Type: `boolean` - -Skip generating a module for the secondary entry point. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/library.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/library.md deleted file mode 100644 index 635802f743..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/library.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -title: '@nrwl/angular:library generator' -description: 'Creates an Angular library.' ---- - -# @nrwl/angular:library - -Creates an Angular library. - -## Usage - -```bash -nx generate library ... -``` - -```bash -nx g lib ... # same -``` - -By default, Nx will search for `library` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:library ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g library ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the library. - -### addModuleSpec - -Default: `false` - -Type: `boolean` - -Add a module spec file. - -### addTailwind - -Default: `false` - -Type: `boolean` - -Whether to configure TailwindCSS for the application. It can only be used with buildable and publishable libraries. Non-buildable libraries will use the application's Tailwind configuration. - -### buildable - -Default: `false` - -Type: `boolean` - -Generate a buildable library. - -### compilationMode - -Type: `string` - -Possible values: `full`, `partial` - -Specifies the compilation mode to use. If not specified, it will default to `partial` for publishable libraries and to `full` for buildable libraries. The `full` value can not be used for publishable libraries. - -### directory - -Type: `string` - -A directory where the library is placed. - -### importPath - -Type: `string` - -The library name used to import it, like `@myorg/my-awesome-lib`. Must be a valid npm name. - -### lazy - -Default: `false` - -Type: `boolean` - -Add `RouterModule.forChild` when set to true, and a simple array of routes when set to false. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `none` - -The tool to use for running lint checks. - -### parentModule - -Type: `string` - -Update the router configuration of the parent module using `loadChildren` or `children`, depending on what `lazy` is set to. - -### prefix - -Alias(es): p - -Type: `string` - -The prefix to apply to generated selectors. - -### publishable - -Default: `false` - -Type: `boolean` - -Generate a publishable library. - -### routing - -Default: `false` - -Type: `boolean` - -Add router configuration. See `lazy` for more information. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### simpleModuleName - -Default: `false` - -Type: `boolean` - -Keep the module name simple (when using `--directory`). - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipModule - -Default: `false` - -Type: `boolean` - -Whether to skip the creation of a default module when generating the library. - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add dependencies to `package.json`. - -### skipTsConfig - -Default: `false` - -Type: `boolean` - -Do not update `tsconfig.json` for development experience. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into `/project.json` rather than including it inside `workspace.json`. - -### strict - -Default: `true` - -Type: `boolean` - -Create a library with stricter type checking and build optimization options. - -### tags - -Type: `string` - -Add tags to the library (used for linting). - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `karma`, `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/move.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/move.md deleted file mode 100644 index 0a9a0d756f..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/move.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: '@nrwl/angular:move generator' -description: 'Moves an Angular application or library to another folder within the workspace and updates the project configuration.' ---- - -# @nrwl/angular:move - -Moves an Angular application or library to another folder within the workspace and updates the project configuration. - -## Usage - -```bash -nx generate move ... -``` - -```bash -nx g mv ... # same -``` - -By default, Nx will search for `move` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:move ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g move ... --dry-run -``` - -### Examples - -Move libs/my-feature-lib to libs/shared/my-feature-lib: - -```bash -nx g @nrwl/angular:move --project my-feature-lib shared/my-feature-lib -``` - -## Options - -### destination (_**required**_) - -Type: `string` - -The folder to move the Angular project into. - -### projectName (_**required**_) - -Alias(es): project - -Type: `string` - -The name of the Angular project to move. - -### importPath - -Type: `string` - -The new import path to use in the `tsconfig.base.json`. - -### skipFormat - -Alias(es): skip-format - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### updateImportPath - -Default: `true` - -Type: `boolean` - -Update the import path to reflect the new location. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/ngrx.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/ngrx.md deleted file mode 100644 index 433d6f2a30..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/ngrx.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: '@nrwl/angular:ngrx generator' -description: 'Adds NgRx support to an application or library.' ---- - -# @nrwl/angular:ngrx - -Adds NgRx support to an application or library. - -## Usage - -```bash -nx generate ngrx ... -``` - -By default, Nx will search for `ngrx` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:ngrx ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g ngrx ... --dry-run -``` - -## Options - -### module (_**required**_) - -Type: `string` - -The path to the `NgModule` where the feature state will be registered. The host directory will create/use the new state directory. - -### name (_**required**_) - -Type: `string` - -Name of the NgRx feature state, such as `products` or `users`. Recommended to use the plural form of the name. - -### barrels - -Default: `false` - -Type: `boolean` - -Use barrels to re-export actions, state and selectors. - -### directory - -Default: `+state` - -Type: `string` - -The name of the folder used to contain/group the generated NgRx files. - -### facade - -Default: `false` - -Type: `boolean` - -Create a Facade class for the the feature. - -### minimal - -Default: `true` - -Type: `boolean` - -Only register the root state management setup or feature state. - -### root - -Default: `false` - -Type: `boolean` - -Setup root or feature state management with NgRx. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipImport - -Default: `false` - -Type: `boolean` - -Generate NgRx feature files without registering the feature in the NgModule. - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not update the `package.json` with NgRx dependencies. - -### syntax - -Default: `creators` - -Type: `string` - -Possible values: `classes`, `creators` - -Specifies whether to use class-based or creator functions for actions, reducers, and effects. - -### useDataPersistence - -Default: `false` - -Type: `boolean` - -Generate NgRx Effects with the `DataPersistence` helper service. Set to false to use plain effects data persistence operators. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/scam-directive.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/scam-directive.md deleted file mode 100644 index 7a7a787337..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/scam-directive.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: '@nrwl/angular:scam-directive generator' -description: 'Generate a directive with an accompanying Single Component Angular Module (SCAM).' ---- - -# @nrwl/angular:scam-directive - -Generate a directive with an accompanying Single Component Angular Module (SCAM). - -## Usage - -```bash -nx generate scam-directive ... -``` - -By default, Nx will search for `scam-directive` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:scam-directive ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g scam-directive ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the directive. - -### export - -Default: `false` - -Type: `boolean` - -Specifies if the SCAM should be exported from the project's entry point (normally `index.ts`). It only applies to libraries. - -### flat - -Default: `true` - -Type: `boolean` - -Create the new files at the top level of the current project. - -### inlineScam - -Default: `true` - -Type: `boolean` - -Create the NgModule in the same file as the Directive. - -### path (**hidden**) - -Type: `string` - -The path at which to create the directive file, relative to the current workspace. Default is a folder with the same name as the directive in the project root. - -### prefix - -Alias(es): p - -Type: `string` - -The prefix to apply to the generated directive selector. - -### project - -Type: `string` - -The name of the project. - -### selector - -Type: `string` - -The HTML selector to use for this directive. - -### skipTests - -Default: `false` - -Type: `boolean` - -Do not create "spec.ts" test files for the new directive. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/scam-pipe.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/scam-pipe.md deleted file mode 100644 index 64739e7f66..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/scam-pipe.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: '@nrwl/angular:scam-pipe generator' -description: 'Generate a pipe with an accompanying Single Component Angular Module (SCAM).' ---- - -# @nrwl/angular:scam-pipe - -Generate a pipe with an accompanying Single Component Angular Module (SCAM). - -## Usage - -```bash -nx generate scam-pipe ... -``` - -By default, Nx will search for `scam-pipe` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:scam-pipe ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g scam-pipe ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the pipe. - -### export - -Default: `false` - -Type: `boolean` - -Specifies if the SCAM should be exported from the project's entry point (normally `index.ts`). It only applies to libraries. - -### flat - -Default: `true` - -Type: `boolean` - -Create the new files at the top level of the current project. - -### inlineScam - -Default: `true` - -Type: `boolean` - -Create the NgModule in the same file as the Pipe. - -### path (**hidden**) - -Type: `string` - -The path at which to create the pipe file, relative to the current workspace. Default is a folder with the same name as the pipe in the project root. - -### project - -Type: `string` - -The name of the project. - -### skipTests - -Default: `false` - -Type: `boolean` - -Do not create "spec.ts" test files for the new pipe. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/scam.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/scam.md deleted file mode 100644 index da181d31eb..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/scam.md +++ /dev/null @@ -1,172 +0,0 @@ ---- -title: '@nrwl/angular:scam generator' -description: 'Generate a component with an accompanying Single Component Angular Module (SCAM).' ---- - -# @nrwl/angular:scam - -Generate a component with an accompanying Single Component Angular Module (SCAM). - -## Usage - -```bash -nx generate scam ... -``` - -By default, Nx will search for `scam` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:scam ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g scam ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the component. - -### changeDetection - -Alias(es): c - -Default: `Default` - -Type: `string` - -Possible values: `Default`, `OnPush` - -The change detection strategy to use in the new component. - -### displayBlock - -Alias(es): b - -Default: `false` - -Type: `boolean` - -Specifies if the style will contain `:host { display: block; }`. - -### export - -Default: `false` - -Type: `boolean` - -Specifies if the SCAM should be exported from the project's entry point (normally `index.ts`). It only applies to libraries. - -### flat - -Default: `false` - -Type: `boolean` - -Create the new files at the top level of the current project. - -### inlineScam - -Default: `true` - -Type: `boolean` - -Create the NgModule in the same file as the Component. - -### inlineStyle - -Alias(es): s - -Default: `false` - -Type: `boolean` - -Include styles inline in the component.ts file. Only CSS styles can be included inline. By default, an external styles file is created and referenced in the component.ts file. - -### inlineTemplate - -Alias(es): t - -Default: `false` - -Type: `boolean` - -Include template inline in the component.ts file. By default, an external template file is created and referenced in the component.ts file. - -### path (**hidden**) - -Type: `string` - -The path at which to create the component file, relative to the current workspace. Default is a folder with the same name as the component in the project root. - -### prefix - -Alias(es): p - -Type: `string` - -The prefix to apply to the generated component selector. - -### project - -Type: `string` - -The name of the project. - -### selector - -Type: `string` - -The HTML selector to use for this component. - -### skipSelector - -Default: `false` - -Type: `boolean` - -Specifies if the component should have a selector or not. - -### skipTests - -Default: `false` - -Type: `boolean` - -Do not create "spec.ts" test files for the new component. - -### style - -Default: `css` - -Type: `string` - -Possible values: `css`, `scss`, `sass`, `less`, `none` - -The file extension or preprocessor to use for style files, or 'none' to skip generating the style file. - -### type - -Default: `component` - -Type: `string` - -Adds a developer-defined type to the filename, in the format "name.type.ts". - -### viewEncapsulation - -Alias(es): v - -Type: `string` - -Possible values: `Emulated`, `None`, `ShadowDom` - -The view encapsulation strategy to use in the new component. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/setup-mfe.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/setup-mfe.md deleted file mode 100644 index a21b69898b..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/setup-mfe.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: '@nrwl/angular:setup-mfe generator' -description: 'Generate a Module Federation configuration for a given Angular application.' ---- - -# @nrwl/angular:setup-mfe - -Generate a Module Federation configuration for a given Angular application. - -## Usage - -```bash -nx generate setup-mfe ... -``` - -By default, Nx will search for `setup-mfe` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:setup-mfe ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g setup-mfe ... --dry-run -``` - -## Options - -### appName (_**required**_) - -Type: `string` - -The name of the application to generate the Module Federation configuration for. - -### mfeType (_**required**_) - -Default: `remote` - -Type: `string` - -Possible values: `host`, `remote` - -Type of application to generate the Module Federation configuration for. - -### host - -Type: `string` - -The name of the host application that the remote application will be consumed by. - -### port - -Type: `number` - -The port at which the remote application should be served. - -### remotes - -Type: `array` - -A list of remote application names that the host application should consume. - -### routing - -Type: `boolean` - -Generate a routing setup to allow a host application to route to the remote application. - -### skipFormat - -Type: `boolean` - -Skip formatting the workspace after the generator completes. - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add dependencies to `package.json`. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/setup-tailwind.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/setup-tailwind.md deleted file mode 100644 index 9b4b97ce0e..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/setup-tailwind.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: '@nrwl/angular:setup-tailwind generator' -description: 'Configures TailwindCSS for an application or a buildable/publishable library.' ---- - -# @nrwl/angular:setup-tailwind - -Configures TailwindCSS for an application or a buildable/publishable library. - -## Usage - -```bash -nx generate setup-tailwind ... -``` - -By default, Nx will search for `setup-tailwind` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:setup-tailwind ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g setup-tailwind ... --dry-run -``` - -## Options - -### project (_**required**_) - -Type: `string` - -The name of the project to add the TailwindCSS setup for. - -### buildTarget - -Default: `build` - -Type: `string` - -The name of the target used to build the project. This option only applies to buildable/publishable libraries. - -### skipFormat - -Type: `boolean` - -Skips formatting the workspace after the generator completes. - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add dependencies to `package.json`. - -### stylesEntryPoint - -Type: `string` - -Path to the styles entry point relative to the workspace root. If not provided the generator will do its best to find it and it will error if it can't. This option only applies to applications. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/stories.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/stories.md deleted file mode 100644 index 399453eea7..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/stories.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: '@nrwl/angular:stories generator' -description: 'Creates stories/specs for all components declared in a project.' ---- - -# @nrwl/angular:stories - -Creates stories/specs for all components declared in a project. - -## Usage - -```bash -nx generate stories ... -``` - -By default, Nx will search for `stories` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:stories ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g stories ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the project. - -### cypressProject - -Type: `string` - -The Cypress project to generate the stories under. This is inferred from `name` by default. - -### generateCypressSpecs - -Type: `boolean` - -Specifies whether to automatically generate `*.spec.ts` files in the Cypress e2e app generated by the `cypress-configure` generator. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/storybook-configuration.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/storybook-configuration.md deleted file mode 100644 index c56c5bbe93..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/storybook-configuration.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: '@nrwl/angular:storybook-configuration generator' -description: 'Adds Storybook configuration to a project.' ---- - -# @nrwl/angular:storybook-configuration - -Adds Storybook configuration to a project. - -## Usage - -```bash -nx generate storybook-configuration ... -``` - -By default, Nx will search for `storybook-configuration` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:storybook-configuration ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g storybook-configuration ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the project. - -### configureCypress - -Default: `true` - -Type: `boolean` - -Specifies whether to configure Cypress or not. - -### cypressDirectory - -Type: `string` - -A directory where the Cypress project will be placed. Placed at the root by default. - -### generateCypressSpecs - -Default: `true` - -Type: `boolean` - -Specifies whether to automatically generate `*.spec.ts` files in the generated Cypress e2e app. - -### generateStories - -Default: `true` - -Type: `boolean` - -Specifies whether to automatically generate `*.stories.ts` files for components declared in this project or not. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `none` - -The tool to use for running lint checks. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/storybook-migrate-defaults-5-to-6.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/storybook-migrate-defaults-5-to-6.md deleted file mode 100644 index dd0010a3a5..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/storybook-migrate-defaults-5-to-6.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: '@nrwl/angular:storybook-migrate-defaults-5-to-6 generator' -description: 'Generates default Storybook configuration files using Storybook version >=6.x specs, for projects that already have Storybook instances and configurations of versions <6.x.' ---- - -# @nrwl/angular:storybook-migrate-defaults-5-to-6 - -Generates default Storybook configuration files using Storybook version >=6.x specs, for projects that already have Storybook instances and configurations of versions <6.x. - -## Usage - -```bash -nx generate storybook-migrate-defaults-5-to-6 ... -``` - -By default, Nx will search for `storybook-migrate-defaults-5-to-6` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:storybook-migrate-defaults-5-to-6 ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g storybook-migrate-defaults-5-to-6 ... --dry-run -``` - -## Options - -### all - -Default: `true` - -Type: `boolean` - -Generate new Storybook configurations for all Storybook instances across all applications and libraries. - -### keepOld - -Default: `true` - -Type: `boolean` - -Keep the old configuration files by placing them in a folder called `.old_storybook`. - -### name - -Type: `string` - -Library or application name for which you want to generate the new Storybook configuration. Leave empty to upgrade all Storybook instances. Only use this if you want to do a gradual migration. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/storybook-migrate-stories-to-6-2.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/storybook-migrate-stories-to-6-2.md deleted file mode 100644 index a81530a233..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/storybook-migrate-stories-to-6-2.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: '@nrwl/angular:storybook-migrate-stories-to-6-2 generator' -description: 'Migrates stories to match the new syntax in v6.2 where the component declaration should be in the default export.' ---- - -# @nrwl/angular:storybook-migrate-stories-to-6-2 - -Migrates stories to match the new syntax in v6.2 where the component declaration should be in the default export. - -## Usage - -```bash -nx generate storybook-migrate-stories-to-6-2 ... -``` - -By default, Nx will search for `storybook-migrate-stories-to-6-2` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:storybook-migrate-stories-to-6-2 ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g storybook-migrate-stories-to-6-2 ... --dry-run -``` diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/upgrade-module.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/upgrade-module.md deleted file mode 100644 index 7cbcd4152e..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/upgrade-module.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: '@nrwl/angular:upgrade-module generator' -description: 'Sets up an Upgrade Module.' ---- - -# @nrwl/angular:upgrade-module - -Sets up an Upgrade Module. - -## Usage - -```bash -nx generate upgrade-module ... -``` - -By default, Nx will search for `upgrade-module` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:upgrade-module ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g upgrade-module ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the main AngularJS module. - -### project (_**required**_) - -Type: `string` - -The name of the project. - -### angularJsCmpSelector - -Type: `string` - -The selector of an AngularJS component (e.g., `--angularJsCmpSelector=myComponent`). - -### angularJsImport - -Type: `string` - -Import expression of the AngularJS application (e.g., `--angularJsImport=some_node_module/my_app`). - -### router - -Default: `false` - -Type: `boolean` - -Sets up router synchronization (e.g., `--router`). - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add `@angular/upgrade` to `package.json` (e.g., `--skipPackageJson`). diff --git a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/web-worker.md b/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/web-worker.md deleted file mode 100644 index 293af264e7..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-angular/generators/web-worker.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: '@nrwl/angular:web-worker generator' -description: 'Creates a Web Worker.' ---- - -# @nrwl/angular:web-worker - -Creates a Web Worker. - -## Usage - -```bash -nx generate web-worker ... -``` - -By default, Nx will search for `web-worker` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/angular:web-worker ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g web-worker ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the worker. - -### project (_**required**_) - -Type: `string` - -The name of the project. - -### path - -Type: `string` - -The path at which to create the worker file, relative to the current workspace. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### snippet - -Default: `true` - -Type: `boolean` - -Add a worker creation snippet in a sibling file of the same name. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-cypress/executors/cypress.md b/nx-dev/nx-dev/public/documentation/generated/api-cypress/executors/cypress.md deleted file mode 100644 index de1d9547f2..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-cypress/executors/cypress.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: '@nrwl/cypress:cypress executor' -description: 'Run Cypress e2e tests' ---- - -# @nrwl/cypress:cypress - -Run Cypress e2e tests - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### cypressConfig (_**required**_) - -Type: `string` - -The path of the Cypress configuration json file. - -### baseUrl - -Type: `string` - -The address (with the port) which your application is running on - -### browser - -Type: `string` - -The browser to run tests in. - -### ciBuildId - -Type: `string | number ` - -A unique identifier for a run to enable grouping or parallelization. - -### ~~copyFiles~~ - -Type: `string` - -**Deprecated:** A regex string that is used to choose what additional integration files to copy to the dist folder - -### devServerTarget - -Type: `string` - -Dev server target to run tests against. - -### exit - -Default: `true` - -Type: `boolean` - -Whether or not the Cypress Test Runner will stay open after running tests in a spec file - -### group - -Type: `string` - -A named group for recorded runs in the Cypress dashboard. - -### headed - -Default: `false` - -Type: `boolean` - -Displays the browser instead of running headlessly. Set this to 'true' if your run depends on a Chrome extension being loaded. - -### ~~headless~~ - -Default: `false` - -Type: `boolean` - -**Deprecated:** Hide the browser instead of running headed (default for cypress run). - -### ignoreTestFiles - -Type: `string` - -A String or Array of glob patterns used to ignore test files that would otherwise be shown in your list of tests. Cypress uses minimatch with the options: {dot: true, matchBase: true}. We suggest using https://globster.xyz to test what files would match. - -### key - -Type: `string` - -The key cypress should use to run tests in parallel/record the run (CI only) - -### parallel - -Default: `false` - -Type: `boolean` - -Whether or not Cypress should run its tests in parallel (CI only) - -### record - -Default: `false` - -Type: `boolean` - -Whether or not Cypress should record the results of the tests - -### reporter - -Type: `string` - -The reporter used during cypress run - -### reporterOptions - -Type: `string` - -The reporter options used. Supported options depend on the reporter. - -### skipServe - -Default: `false` - -Type: `boolean` - -Skip dev-server build. - -### spec - -Type: `string` - -A comma delimited glob string that is provided to the Cypress runner to specify which spec files to run. i.e. '**examples/**,**actions.spec** - -### tag - -Alias(es): t - -Type: `string` - -A comma delimited list to identify a run with - -### testingType - -Default: `e2e` - -Type: `string` - -Possible values: `component`, `e2e` - -Specify the type of tests to execute - -### tsConfig - -Type: `string` - -The path of the Cypress tsconfig configuration json file. - -### watch - -Default: `false` - -Type: `boolean` - -Recompile and run tests when files change. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-cypress/generators/cypress-project.md b/nx-dev/nx-dev/public/documentation/generated/api-cypress/generators/cypress-project.md deleted file mode 100644 index 26afa88c10..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-cypress/generators/cypress-project.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: '@nrwl/cypress:cypress-project generator' -description: 'Add a Cypress E2E Project' ---- - -# @nrwl/cypress:cypress-project - -Add a Cypress E2E Project - -## Usage - -```bash -nx generate cypress-project ... -``` - -By default, Nx will search for `cypress-project` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/cypress:cypress-project ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g cypress-project ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Name of the E2E Project - -### baseUrl - -Type: `string` - -The address (with the port) which your application is running on - -### directory - -Type: `string` - -A directory where the project is placed - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint`, `none` - -The tool to use for running lint checks. - -### project - -Type: `string` - -The name of the frontend project to test. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add dependencies to `package.json`. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json diff --git a/nx-dev/nx-dev/public/documentation/generated/api-detox/executors/build.md b/nx-dev/nx-dev/public/documentation/generated/api-detox/executors/build.md deleted file mode 100644 index 7f768cd2aa..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-detox/executors/build.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: '@nrwl/detox:build executor' -description: 'Run the command defined in build property of the specified configuration.' ---- - -# @nrwl/detox:build - -Run the command defined in build property of the specified configuration. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### configPath - -Alias(es): cp - -Type: `string` - -Specify Detox config file path. If not supplied, detox searches for .detoxrc[.js] or "detox" section in package.json - -### detoxConfiguration - -Alias(es): C - -Type: `string` - -Select a device configuration from your defined configurations, if not supplied, and there's only one configuration, detox will default to it diff --git a/nx-dev/nx-dev/public/documentation/generated/api-detox/executors/test.md b/nx-dev/nx-dev/public/documentation/generated/api-detox/executors/test.md deleted file mode 100644 index ffd6f347f2..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-detox/executors/test.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -title: '@nrwl/detox:test executor' -description: 'Initiating your detox test suite.' ---- - -# @nrwl/detox:test - -Initiating your detox test suite. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### detoxConfiguration (_**required**_) - -Alias(es): C - -Type: `string` - -Select a device configuration from your defined configurations, if not supplied, and there's only one configuration, detox will default to it - -### appLaunchArgs - -Type: `number` - -Custom arguments to pass (through) onto the app every time it is launched. - -### artifactsLocation - -Alias(es): a - -Type: `string` - -Artifacts (logs, screenshots, etc) root directory. - -### buildTarget - -Type: `string` - -Target which builds the application - -### captureViewHierarchy - -Type: `string` - -[iOS Only] Capture \*.uihierarchy snapshots on view action errors and device.captureViewHierarchy() calls. - -### cleanup - -Type: `boolean` - -Shutdown simulator when test is over, useful for CI scripts, to make sure detox exists cleanly with no residue - -### configPath - -Alias(es): cp - -Type: `string` - -Specify Detox config file path. If not supplied, detox searches for .detoxrc[.js] or "detox" section in package.json - -### debugSynchronization - -Alias(es): d - -Type: `string` - -Customize how long an action/expectation can take to complete before Detox starts querying the app why it is busy. By default, the app status will be printed if the action takes more than 10s to complete. - -### deviceLaunchArgs - -Type: `string` - -A list of passthrough-arguments to use when (if) devices (Android emulator / iOS simulator) are launched by Detox. - -### deviceName - -Alias(es): n - -Type: `string` - -Override the device name specified in a configuration. Useful for running a single build configuration on multiple devices. - -### forceAdbInstall - -Type: `boolean` - -Due to problems with the adb install command on Android, Detox resorts to a different scheme for install APK's. Setting true will disable that and force usage of adb install, instead. - -### gpu - -Type: `boolean` - -[Android Only] Launch Emulator with the specific -gpu [gpu mode] parameter. - -### headless - -Type: `boolean` - -Android Only] Launch Emulator in headless mode. Useful when running on CI. - -### inspectBrk - -Type: `boolean` - -Uses node's --inspect-brk flag to let users debug the jest/mocha test runner - -### jestReportSpecs - -Type: `boolean` - -[Jest Only] Whether to output logs per each running spec, in real-time. By default, disabled with multiple workers. - -### loglevel - -Alias(es): l - -Type: `string` - -Log level: fatal, error, warn, info, verbose, trace - -### noColor - -Type: `boolean` - -Disable colors in log output - -### recordLogs - -Type: `string` - -Save logs during each test to artifacts directory. Pass "failing" to save logs of failing tests only. - -### recordPerformance - -Type: `string` - -[iOS Only] Save Detox Instruments performance recordings of each test to artifacts directory. - -### recordTimeline - -Type: `string` - -[Jest Only] Record tests and events timeline, for visual display on the chrome://tracing tool. - -### recordVideos - -Type: `string` - -Save screen recordings of each test to artifacts directory. Pass "failing" to save recordings of failing tests only. - -### retries - -Type: `number` - -[Jest Circus Only] Re-spawn the test runner for individual failing suite files until they pass, or times at least. - -### reuse - -Type: `boolean` - -Reuse existing installed app (do not delete + reinstall) for a faster run. - -### runnerConfig - -Alias(es): o - -Type: `string` - -Test runner config file, defaults to 'e2e/mocha.opts' for mocha and 'e2e/config.json' for jest. - -### takeScreenshots - -Type: `string` - -Save screenshots before and after each test to artifacts directory. Pass "failing" to save screenshots of failing tests only. - -### useCustomLogger - -Type: `boolean` - -Use Detox' custom console-logging implementation, for logging Detox (non-device) logs. Disabling will fallback to node.js / test-runner's implementation (e.g. Jest / Mocha). - -### workers - -Type: `number` - -Specifies number of workers the test runner should spawn, requires a test runner with parallel execution support (Detox CLI currently supports Jest). diff --git a/nx-dev/nx-dev/public/documentation/generated/api-detox/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-detox/generators/application.md deleted file mode 100644 index 36b863db4a..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-detox/generators/application.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/detox:application generator' -description: 'Create a detox application' ---- - -# @nrwl/detox:application - -Create a detox application - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/detox:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Name of the E2E Project - -### project (_**required**_) - -Type: `string` - -The name of the frontend project to test. - -### directory - -Type: `string` - -A directory where the project is placed - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint`, `none` - -The tool to use for running lint checks. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files diff --git a/nx-dev/nx-dev/public/documentation/generated/api-express/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-express/generators/application.md deleted file mode 100644 index 9adb724215..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-express/generators/application.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: '@nrwl/express:application generator' -description: 'Create an express application' ---- - -# @nrwl/express:application - -Create an express application - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/express:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -## Options - -### babelJest - -Default: `false` - -Type: `boolean` - -Use babel instead ts-jest - -### directory - -Type: `string` - -The directory of the new application. - -### frontendProject - -Type: `string` - -Frontend project that needs to access this application. This sets up proxy configuration. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### name - -Type: `string` - -The name of the application. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case file names. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add dependencies to package.json. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### tags - -Type: `string` - -Add tags to the application (used for linting) - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-jest/executors/jest.md b/nx-dev/nx-dev/public/documentation/generated/api-jest/executors/jest.md deleted file mode 100644 index 488927c417..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-jest/executors/jest.md +++ /dev/null @@ -1,244 +0,0 @@ ---- -title: '@nrwl/jest:jest executor' -description: 'Run Jest unit tests' ---- - -# @nrwl/jest:jest - -Run Jest unit tests - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### jestConfig (_**required**_) - -Type: `string` - -The path of the Jest configuration. (https://jestjs.io/docs/en/configuration) - -### bail - -Alias(es): b - -Type: `number | boolean ` - -Exit the test suite immediately after `n` number of failing tests. (https://jestjs.io/docs/cli#--bail) - -### changedSince - -Type: `string` - -Runs tests related to the changes since the provided branch or commit hash. If the current branch has diverged from the given branch, then only changes made locally will be tested. (https://jestjs.io/docs/cli#--changedsince) - -### ci - -Type: `boolean` - -Whether to run Jest in continuous integration (CI) mode. This option is on by default in most popular CI environments. It will prevent snapshots from being written unless explicitly requested. (https://jestjs.io/docs/cli#--ci) - -### clearCache - -Type: `boolean` - -Deletes the Jest cache directory and then exits without running tests. Will delete Jest's default cache directory. _Note: clearing the cache will reduce performance_. - -### codeCoverage - -Alias(es): coverage - -Type: `boolean` - -Indicates that test coverage information should be collected and reported in the output. (https://jestjs.io/docs/cli#--coverageboolean) - -### color - -Alias(es): colors - -Type: `boolean` - -Forces test results output color highlighting (even if stdout is not a TTY). Set to false if you would like to have no colors. (https://jestjs.io/docs/cli#--colors) - -### colors - -Type: `boolean` - -Forces test results output highlighting even if stdout is not a TTY. (https://jestjs.io/docs/cli#--colors) - -### config - -Type: `string` - -The path to a Jest config file specifying how to find and execute tests. If no rootDir is set in the config, the directory containing the config file is assumed to be the rootDir for the project. This can also be a JSON-encoded value which Jest will use as configuration - -### coverageDirectory - -Type: `string` - -The directory where Jest should output its coverage files. - -### coverageReporters - -Type: `array` - -A list of reporter names that Jest uses when writing coverage reports. Any istanbul reporter - -### detectOpenHandles - -Type: `boolean` - -Attempt to collect and print open handles preventing Jest from exiting cleanly (https://jestjs.io/docs/cli#--detectopenhandles) - -### findRelatedTests - -Type: `string` - -Find and run the tests that cover a comma separated list of source files that were passed in as arguments. (https://jestjs.io/docs/cli#--findrelatedtests-spaceseparatedlistofsourcefiles) - -### json - -Type: `boolean` - -Prints the test results in JSON. This mode will send all other test output and user messages to stderr. (https://jestjs.io/docs/cli#--json) - -### maxWorkers - -Alias(es): w - -Type: `number | string ` - -Specifies the maximum number of workers the worker-pool will spawn for running tests. This defaults to the number of the cores available on your machine. Useful for CI. (its usually best not to override this default) (https://jestjs.io/docs/cli#--maxworkersnumstring) - -### onlyChanged - -Alias(es): o - -Type: `boolean` - -Attempts to identify which tests to run based on which files have changed in the current repository. Only works if you're running tests in a git or hg repository at the moment. (https://jestjs.io/docs/cli#--onlychanged) - -### outputFile - -Type: `string` - -Write test results to a file when the --json option is also specified. (https://jestjs.io/docs/cli#--outputfilefilename) - -### passWithNoTests - -Type: `boolean` - -Will not fail if no tests are found (for example while using `--testPathPattern`.) (https://jestjs.io/docs/cli#--passwithnotests) - -### reporters - -Type: `array` - -Run tests with specified reporters. Reporter options are not available via CLI. Example with multiple reporters: jest --reporters="default" --reporters="jest-junit" (https://jestjs.io/docs/cli#--reporters) - -### runInBand - -Alias(es): i - -Type: `boolean` - -Run all tests serially in the current process (rather than creating a worker pool of child processes that run tests). This is sometimes useful for debugging, but such use cases are pretty rare. Useful for CI. (https://jestjs.io/docs/cli#--runinband) - -### ~~setupFile~~ - -Type: `string` - -**Deprecated:** The name of a setup file used by Jest. (use Jest config file https://jestjs.io/docs/en/configuration#setupfilesafterenv-array) - -### showConfig - -Type: `boolean` - -Print your Jest config and then exits. (https://jestjs.io/docs/en/cli#--showconfig) - -### silent - -Type: `boolean` - -Prevent tests from printing messages through the console. (https://jestjs.io/docs/cli#--silent) - -### testFile - -Type: `string` - -The name of the file to test. - -### testLocationInResults - -Type: `boolean` - -Adds a location field to test results. Used to report location of a test in a reporter. { "column": 4, "line": 5 } (https://jestjs.io/docs/cli#--testlocationinresults) - -### testNamePattern - -Alias(es): t - -Type: `string` - -Run only tests with a name that matches the regex pattern. (https://jestjs.io/docs/cli#--testnamepatternregex) - -### testPathIgnorePatterns - -Type: `array` - -An array of regexp pattern strings that is matched against all tests paths before executing the test. Only run those tests with a path that does not match with the provided regexp expressions. (https://jestjs.io/docs/cli#--testpathignorepatternsregexarray) - -### testPathPattern - -Type: `array` - -An array of regexp pattern strings that is matched against all tests paths before executing the test. (https://jestjs.io/docs/cli#--testpathpatternregex) - -### testResultsProcessor - -Type: `string` - -Node module that implements a custom results processor. (https://jestjs.io/docs/en/configuration#testresultsprocessor-string) - -### testTimeout - -Type: `number` - -Default timeout of a test in milliseconds. Default value: 5000. (https://jestjs.io/docs/cli#--testtimeoutnumber) - -### ~~tsConfig~~ - -Type: `string` - -**Deprecated:** The name of the Typescript configuration file. Set the tsconfig option in the jest config file. - -### updateSnapshot - -Alias(es): u - -Type: `boolean` - -Use this flag to re-record snapshots. Can be used together with a test suite pattern or with `--testNamePattern` to re-record snapshot for test matching the pattern. (https://jestjs.io/docs/cli#--updatesnapshot) - -### useStderr - -Type: `boolean` - -Divert all output to stderr. - -### verbose - -Type: `boolean` - -Display individual test results with the test suite hierarchy. (https://jestjs.io/docs/cli#--verbose) - -### watch - -Type: `boolean` - -Watch files for changes and rerun tests related to changed files. If you want to re-run all tests when a file has changed, use the `--watchAll` option. (https://jestjs.io/docs/cli#--watch) - -### watchAll - -Type: `boolean` - -Watch files for changes and rerun all tests when something changes. If you want to re-run only the tests that depend on the changed files, use the `--watch` option. (https://jestjs.io/docs/cli#--watchall) diff --git a/nx-dev/nx-dev/public/documentation/generated/api-js/executors/node.md b/nx-dev/nx-dev/public/documentation/generated/api-js/executors/node.md deleted file mode 100644 index 3f8d56c1c6..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-js/executors/node.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: '@nrwl/js:node executor' -description: 'Build Node.js applications' ---- - -# @nrwl/js:node - -Build Node.js applications - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### buildTarget (_**required**_) - -Type: `string` - -The target to run to build you the app - -### args - -Type: `array` - -Extra args when starting the app - -### host - -Default: `localhost` - -Type: `string` - -The host to inspect the process on - -### inspect - -Default: `inspect` - -Type: `string | boolean ` - -Ensures the app is starting with debugging - -### port - -Default: `9229` - -Type: `number` - -The port to inspect the process on. Setting port to 0 will assign random free ports to all forked processes. - -### runtimeArgs - -Type: `array` - -Extra args passed to the node process - -### waitUntilTargets - -Type: `array` - -The targets to run to before starting the node app - -### watch - -Default: `true` - -Type: `boolean` - -Enable re-building when files change. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-js/executors/swc.md b/nx-dev/nx-dev/public/documentation/generated/api-js/executors/swc.md deleted file mode 100644 index 55d7434787..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-js/executors/swc.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: '@nrwl/js:swc executor' -description: 'Build a project using SWC' ---- - -# @nrwl/js:swc - -Build a project using SWC - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### main (_**required**_) - -Type: `string` - -The name of the main entry-point file. - -### outputPath (_**required**_) - -Type: `string` - -The output path of the generated files. - -### tsConfig (_**required**_) - -Type: `string` - -The path to the Typescript configuration file. - -### assets - -Type: `array` - -List of static assets. - -### skipTypeCheck - -Default: `false` - -Type: `boolean` - -Whether to skip TypeScript type checking. - -### swcExclude - -Type: `array` - -List of SWC Glob/Regex to be excluded from compilation (https://swc.rs/docs/configuration/compilation#exclude) - -### watch - -Default: `false` - -Type: `boolean` - -Enable re-building when files change. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-js/executors/tsc.md b/nx-dev/nx-dev/public/documentation/generated/api-js/executors/tsc.md deleted file mode 100644 index 88cf454429..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-js/executors/tsc.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: '@nrwl/js:tsc executor' -description: 'Build a project using TypeScript.' ---- - -# @nrwl/js:tsc - -Build a project using TypeScript. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### main (_**required**_) - -Type: `string` - -The name of the main entry-point file. - -### outputPath (_**required**_) - -Type: `string` - -The output path of the generated files. - -### tsConfig (_**required**_) - -Type: `string` - -The path to the Typescript configuration file. - -### assets - -Type: `array` - -List of static assets. - -### transformers - -Type: `array` - -List of TypeScript Transformer Plugins. - -### watch - -Default: `false` - -Type: `boolean` - -Enable re-building when files change. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-js/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-js/generators/application.md deleted file mode 100644 index c9799dd780..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-js/generators/application.md +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: '@nrwl/js:application generator' -description: 'Create a application' ---- - -# @nrwl/js:application - -Create a application - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/js:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -### Examples - -Generate libs/myapp/mylib: - -```bash -nx g lib mylib --directory=myapp -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Library name - -### compiler - -Default: `tsc` - -Type: `string` - -Possible values: `tsc`, `swc` - -The compiler used by the build and test targets - -### config - -Default: `project` - -Type: `string` - -Possible values: `workspace`, `project`, `npm-scripts` - -Determines how whether the project's executors should be configured in workspace.json, project.json or as npm scripts - -### directory - -Type: `string` - -A directory where the lib is placed - -### importPath - -Type: `string` - -The library name used to import it, like @myorg/my-awesome-lib - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `none` - -The tool to use for running lint checks. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case file names. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### skipTsConfig - -Default: `false` - -Type: `boolean` - -Do not update tsconfig.json for development experience. - -### strict - -Default: `true` - -Type: `boolean` - -Whether to enable tsconfig strict mode or not. - -### tags - -Type: `string` - -Add tags to the library (used for linting) - -### testEnvironment - -Default: `jsdom` - -Type: `string` - -Possible values: `jsdom`, `node` - -The test environment to use if unitTestRunner is set to jest - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-js/generators/convert-to-swc.md b/nx-dev/nx-dev/public/documentation/generated/api-js/generators/convert-to-swc.md deleted file mode 100644 index f8fc46c4fb..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-js/generators/convert-to-swc.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: '@nrwl/js:convert-to-swc generator' -description: 'Convert a tsc library to swc' ---- - -# @nrwl/js:convert-to-swc - -Convert a tsc library to swc - -## Usage - -```bash -nx generate convert-to-swc ... -``` - -```bash -nx g swc ... # same -``` - -By default, Nx will search for `convert-to-swc` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/js:convert-to-swc ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g convert-to-swc ... --dry-run -``` - -### Examples - -Convert libs/myapp/mylib to swc: - -```bash -nx g swc mylib -``` - -## Options - -### project (_**required**_) - -Type: `string` - -Library name - -### targets - -Type: `array` - -List of targets to convert diff --git a/nx-dev/nx-dev/public/documentation/generated/api-js/generators/library.md b/nx-dev/nx-dev/public/documentation/generated/api-js/generators/library.md deleted file mode 100644 index 2f8109b129..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-js/generators/library.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: '@nrwl/js:library generator' -description: 'Create a library' ---- - -# @nrwl/js:library - -Create a library - -## Usage - -```bash -nx generate library ... -``` - -```bash -nx g lib ... # same -``` - -By default, Nx will search for `library` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/js:library ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g library ... --dry-run -``` - -### Examples - -Generate libs/myapp/mylib: - -```bash -nx g lib mylib --directory=myapp -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Library name - -### buildable - -Default: `true` - -Type: `boolean` - -Generate a buildable library. - -### compiler - -Default: `tsc` - -Type: `string` - -Possible values: `tsc`, `swc` - -The compiler used by the build and test targets - -### config - -Default: `project` - -Type: `string` - -Possible values: `workspace`, `project`, `npm-scripts` - -Determines how whether the project's executors should be configured in workspace.json, project.json or as npm scripts - -### directory - -Type: `string` - -A directory where the lib is placed - -### importPath - -Type: `string` - -The library name used to import it, like @myorg/my-awesome-lib - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `none` - -The tool to use for running lint checks. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case file names. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### skipTsConfig - -Default: `false` - -Type: `boolean` - -Do not update tsconfig.json for development experience. - -### skipTypeCheck - -Default: `false` - -Type: `boolean` - -Whether to skip TypeScript type checking for SWC compiler. - -### strict - -Default: `true` - -Type: `boolean` - -Whether to enable tsconfig strict mode or not. - -### tags - -Type: `string` - -Add tags to the library (used for linting) - -### testEnvironment - -Default: `jsdom` - -Type: `string` - -Possible values: `jsdom`, `node` - -The test environment to use if unitTestRunner is set to jest - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-linter/executors/eslint.md b/nx-dev/nx-dev/public/documentation/generated/api-linter/executors/eslint.md deleted file mode 100644 index 54bc67e6f2..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-linter/executors/eslint.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: '@nrwl/linter:eslint executor' -description: 'Run ESLint on a project' ---- - -# @nrwl/linter:eslint - -Run ESLint on a project - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### lintFilePatterns (_**required**_) - -Type: `array` - -One or more files/dirs/globs to pass directly to ESLint's lintFiles() method. - -### cache - -Default: `false` - -Type: `boolean` - -Only check changed files. - -### cacheLocation - -Type: `string` - -Path to the cache file or directory. - -### eslintConfig - -Type: `string` - -The name of the ESLint configuration file. - -### fix - -Default: `false` - -Type: `boolean` - -Fixes linting errors (may overwrite linted files). - -### force - -Default: `false` - -Type: `boolean` - -Succeeds even if there was linting errors. - -### format - -Default: `stylish` - -Type: `string` - -ESLint Output formatter (https://eslint.org/docs/user-guide/formatters). - -### hasTypeAwareRules - -Type: `boolean` - -When set to true, the linter will invalidate its cache when any of its dependencies changes. - -### ignorePath - -Type: `string` - -The path of the .eslintignore file. - -### maxWarnings - -Default: `-1` - -Type: `number` - -Number of warnings to trigger nonzero exit code - default: -1 - -### noEslintrc - -Default: `false` - -Type: `boolean` - -The equivalent of the --no-eslintrc flag on the ESLint CLI, it is false by default - -### outputFile - -Type: `string` - -File to write report to. - -### quiet - -Default: `false` - -Type: `boolean` - -Report errors only - default: false - -### silent - -Default: `false` - -Type: `boolean` - -Hide output text. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-linter/executors/lint.md b/nx-dev/nx-dev/public/documentation/generated/api-linter/executors/lint.md deleted file mode 100644 index 4af3f20270..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-linter/executors/lint.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: '@nrwl/linter:lint executor' -description: '**[DEPRECATED]**: Please use the eslint builder instead, an automated migration was provided in v10.3.0' ---- - -# @nrwl/linter:lint - -**[DEPRECATED]**: Please use the eslint builder instead, an automated migration was provided in v10.3.0 - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### linter (_**required**_) - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### cache - -Default: `false` - -Type: `boolean` - -Only check changed files. - -### cacheLocation - -Type: `string` - -Path to the cache file or directory. - -### config - -Type: `string` - -The name of the configuration file. - -### exclude - -Type: `array` - -Files to exclude from linting. - -### files - -Type: `array` - -Files to include in linting. - -### fix - -Default: `false` - -Type: `boolean` - -Fixes linting errors (may overwrite linted files). - -### force - -Default: `false` - -Type: `boolean` - -Succeeds even if there was linting errors. - -### format - -Default: `stylish` - -Type: `string` - -ESLint Output formatter (https://eslint.org/docs/user-guide/formatters). - -### maxWarnings - -Default: `-1` - -Type: `number` - -Number of warnings to trigger nonzero exit code - default: -1 - -### outputFile - -Type: `string` - -File to write report to. - -### quiet - -Default: `false` - -Type: `boolean` - -Report errors only - default: false - -### silent - -Default: `false` - -Type: `boolean` - -Hide output text. - -### tsConfig - -Type: `string | string[] ` - -The name of the TypeScript configuration file. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-linter/generators/workspace-rule.md b/nx-dev/nx-dev/public/documentation/generated/api-linter/generators/workspace-rule.md deleted file mode 100644 index ac04b9e342..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-linter/generators/workspace-rule.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: '@nrwl/linter:workspace-rule generator' -description: 'Create a new workspace ESLint rule' ---- - -# @nrwl/linter:workspace-rule - -Create a new workspace ESLint rule - -## Usage - -```bash -nx generate workspace-rule ... -``` - -By default, Nx will search for `workspace-rule` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/linter:workspace-rule ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g workspace-rule ... --dry-run -``` - -### Examples - -Create a new workspace lint rule called my-custom-rule: - -```bash -nx g @nrwl/linter:workspace-rule my-custom-rule -``` - -Create a new workspace lint rule located at tools/eslint-rules/a/b/c/my-custom-rule.ts: - -```bash -nx g @nrwl/linter:workspace-rule --name=my-custom-rule --directory=a/b/c -``` - -## Options - -### directory (_**required**_) - -Alias(es): dir - -Default: `rules` - -Type: `string` - -Create the rule under this directory within tools/eslint-rules/ (can be nested). - -### name (_**required**_) - -Type: `string` - -The name of the new rule diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/application.md deleted file mode 100644 index fde171a1ed..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/application.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: '@nrwl/nest:application generator' -description: 'Create a NestJS application.' ---- - -# @nrwl/nest:application - -Create a NestJS application. - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the application. - -### directory - -Type: `string` - -The directory of the new application. - -### frontendProject - -Type: `string` - -Frontend project that needs to access this application. This sets up proxy configuration. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `none` - -The tool to use for running lint checks. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add dependencies to package.json. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json. - -### tags - -Type: `string` - -Add tags to the application (used for linting). - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/class.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/class.md deleted file mode 100644 index a652e44eae..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/class.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:class generator' -description: 'Run the `class` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:class - -Run the `class` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate class ... -``` - -By default, Nx will search for `class` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:class ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g class ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the class. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest class language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/controller.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/controller.md deleted file mode 100644 index 2c68a99510..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/controller.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: '@nrwl/nest:controller generator' -description: 'Run the `controller` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:controller - -Run the `controller` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate controller ... -``` - -By default, Nx will search for `controller` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:controller ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g controller ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the controller. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `false` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest controller language. - -### module - -Type: `string` - -Allows specification of the declaring module. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipImport - -Default: `false` - -Type: `boolean` - -Flag to skip the module import. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/convert-tslint-to-eslint.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/convert-tslint-to-eslint.md deleted file mode 100644 index f13547958f..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/convert-tslint-to-eslint.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: '@nrwl/nest:convert-tslint-to-eslint generator' -description: 'Convert a project from TSLint to ESLint.' ---- - -# @nrwl/nest:convert-tslint-to-eslint - -Convert a project from TSLint to ESLint. - -## Usage - -```bash -nx generate convert-tslint-to-eslint ... -``` - -By default, Nx will search for `convert-tslint-to-eslint` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:convert-tslint-to-eslint ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g convert-tslint-to-eslint ... --dry-run -``` - -### Examples - -Convert the NestJS project `myapp` from TSLint to ESLint: - -```bash -nx g convert-tslint-to-eslint myapp -``` - -## Options - -### project (_**required**_) - -Type: `string` - -The name of the NestJS project to convert. - -### ignoreExistingTslintConfig - -Default: `false` - -Type: `boolean` - -If true we will not use existing TSLint config as a reference, we will just reset the project with the latest recommended ESLint config. - -### removeTSLintIfNoMoreTSLintTargets - -Default: `true` - -Type: `boolean` - -If this conversion leaves no more TSLint usage in the workspace, it will remove TSLint and related dependencies and configuration. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/decorator.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/decorator.md deleted file mode 100644 index 30e98953db..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/decorator.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: '@nrwl/nest:decorator generator' -description: 'Run the `decorator` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:decorator - -Run the `decorator` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate decorator ... -``` - -By default, Nx will search for `decorator` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:decorator ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g decorator ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the decorator. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest decorator language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/filter.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/filter.md deleted file mode 100644 index ebd2cf9c75..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/filter.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:filter generator' -description: 'Run the `filter` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:filter - -Run the `filter` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate filter ... -``` - -By default, Nx will search for `filter` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:filter ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g filter ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the filter. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest filter language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/gateway.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/gateway.md deleted file mode 100644 index 4ae8d463da..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/gateway.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:gateway generator' -description: 'Run the `gateway` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:gateway - -Run the `gateway` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate gateway ... -``` - -By default, Nx will search for `gateway` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:gateway ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g gateway ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the gateway. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest gateway language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/guard.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/guard.md deleted file mode 100644 index e42e94cef4..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/guard.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:guard generator' -description: 'Run the `guard` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:guard - -Run the `guard` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate guard ... -``` - -By default, Nx will search for `guard` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:guard ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g guard ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the guard. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest guard language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/interceptor.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/interceptor.md deleted file mode 100644 index f48bf5cfd5..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/interceptor.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:interceptor generator' -description: 'Run the `interceptor` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:interceptor - -Run the `interceptor` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate interceptor ... -``` - -By default, Nx will search for `interceptor` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:interceptor ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g interceptor ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the interceptor. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest interceptor language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/interface.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/interface.md deleted file mode 100644 index c92aa0cb54..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/interface.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: '@nrwl/nest:interface generator' -description: 'Run the `interface` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:interface - -Run the `interface` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate interface ... -``` - -By default, Nx will search for `interface` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:interface ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g interface ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the interface. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/library.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/library.md deleted file mode 100644 index 4a886fcea6..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/library.md +++ /dev/null @@ -1,186 +0,0 @@ ---- -title: '@nrwl/nest:library generator' -description: 'Create a new NestJS library.' ---- - -# @nrwl/nest:library - -Create a new NestJS library. - -## Usage - -```bash -nx generate library ... -``` - -```bash -nx g lib ... # same -``` - -By default, Nx will search for `library` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:library ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g library ... --dry-run -``` - -### Examples - -Generate libs/myapp/mylib: - -```bash -nx g lib mylib --directory=myapp -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Library name. - -### buildable - -Default: `false` - -Type: `boolean` - -Generate a buildable library. - -### controller - -Default: `false` - -Type: `boolean` - -Include a controller with the library. - -### directory - -Alias(es): dir - -Type: `string` - -A directory where the library is placed. - -### global - -Default: `false` - -Type: `boolean` - -Add the Global decorator to the generated module. - -### importPath - -Type: `string` - -The library name used to import it, like @myorg/my-awesome-lib. Must be a valid npm name. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `none` - -The tool to use for running lint checks. - -### publishable - -Type: `boolean` - -Create a publishable library. - -### service - -Default: `false` - -Type: `boolean` - -Include a service with the library. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipTsConfig - -Default: `false` - -Type: `boolean` - -Do not update tsconfig.base.json for development experience. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### strict - -Default: `false` - -Type: `boolean` - -Whether to enable tsconfig strict mode or not. - -### tags - -Alias(es): t - -Type: `string` - -Add tags to the library (used for linting). - -### target - -Default: `es6` - -Type: `string` - -Possible values: `es5`, `es6`, `esnext`, `es2015`, `es2016`, `es2017`, `es2018`, `es2019`, `es2020` - -The ES target, Nest suggest using es6 or higher. - -### testEnvironment - -Default: `node` - -Type: `string` - -Possible values: `jsdom`, `node` - -The test environment for jest, for node applications this should stay as node unless doing DOM testing. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/middleware.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/middleware.md deleted file mode 100644 index 5e4b0c40a3..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/middleware.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:middleware generator' -description: 'Run the `middleware` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:middleware - -Run the `middleware` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate middleware ... -``` - -By default, Nx will search for `middleware` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:middleware ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g middleware ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the middleware. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest middleware language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/module.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/module.md deleted file mode 100644 index a98640fa8d..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/module.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: '@nrwl/nest:module generator' -description: 'Run the `module` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:module - -Run the `module` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate module ... -``` - -By default, Nx will search for `module` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:module ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g module ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the module. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `false` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest module language. - -### module - -Type: `string` - -The path to import the module. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipImport - -Default: `false` - -Type: `boolean` - -Flag to skip the module import. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/pipe.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/pipe.md deleted file mode 100644 index 2b19264077..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/pipe.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:pipe generator' -description: 'Run the `pipe` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:pipe - -Run the `pipe` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate pipe ... -``` - -By default, Nx will search for `pipe` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:pipe ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g pipe ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the pipe. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest pipe language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/provider.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/provider.md deleted file mode 100644 index 17e4166dd8..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/provider.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:provider generator' -description: 'Run the `provider` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:provider - -Run the `provider` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate provider ... -``` - -By default, Nx will search for `provider` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:provider ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g provider ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the provider. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `true` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest provider language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/resolver.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/resolver.md deleted file mode 100644 index afca3530fb..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/resolver.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:resolver generator' -description: 'Run the `resolver` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:resolver - -Run the `resolver` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate resolver ... -``` - -By default, Nx will search for `resolver` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:resolver ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g resolver ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the resolver. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `false` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest resolver language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/resource.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/resource.md deleted file mode 100644 index 35e19905aa..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/resource.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: '@nrwl/nest:resource generator' -description: 'Run the `resource` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:resource - -Run the `resource` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate resource ... -``` - -By default, Nx will search for `resource` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:resource ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g resource ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the resource. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### crud - -Default: `true` - -Type: `boolean` - -When true, CRUD entry points are generated. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `false` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest class language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipImport - -Default: `false` - -Type: `boolean` - -Flag to skip the module import. - -### type - -Default: `rest` - -Type: `string` - -Possible values: `rest`, `graphql-code-first`, `graphql-schema-first`, `microservice`, `ws` - -The transport layer. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/service.md b/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/service.md deleted file mode 100644 index 976473c4f8..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nest/generators/service.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/nest:service generator' -description: 'Run the `service` NestJS generator with Nx project support.' ---- - -# @nrwl/nest:service - -Run the `service` NestJS generator with Nx project support. - -## Usage - -```bash -nx generate service ... -``` - -By default, Nx will search for `service` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nest:service ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g service ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the service. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The Nest project to target. - -### directory - -Alias(es): dir,path - -Type: `string` - -Directory where the generated files are placed. - -### flat - -Default: `false` - -Type: `boolean` - -Flag to indicate if a directory is created. - -### language - -Type: `string` - -Possible values: `js`, `ts` - -Nest service language. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-next/executors/build.md b/nx-dev/nx-dev/public/documentation/generated/api-next/executors/build.md deleted file mode 100644 index a1af2f6040..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-next/executors/build.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: '@nrwl/next:build executor' -description: 'Build a Next.js app' ---- - -# @nrwl/next:build - -Build a Next.js app - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### outputPath (_**required**_) - -Type: `string` - -The output path of the generated files. - -### root (_**required**_) - -Type: `string` - -The source root - -### buildLibsFromSource - -Default: `true` - -Type: `boolean` - -Read buildable libraries from source instead of building them separately. - -### fileReplacements - -Type: `object[]` - -Replace files with other files in the build. - -#### replace - -Type: `string` - -The file to be replaced. - -#### with - -Type: `string` - -The file to replace with. - -### nextConfig - -Type: `string` - -Path (relative to workspace root) to a function which takes phase, config, and builder options, and returns the resulting config. This is an advanced option and should not be used with a normal Next.js config file (i.e. next.config.js). diff --git a/nx-dev/nx-dev/public/documentation/generated/api-next/executors/export.md b/nx-dev/nx-dev/public/documentation/generated/api-next/executors/export.md deleted file mode 100644 index 293a7872be..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-next/executors/export.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: '@nrwl/next:export executor' -description: 'Export a Next.js app. The exported application is located at dist/$outputPath/exported.' ---- - -# @nrwl/next:export - -Export a Next.js app. The exported application is located at dist/$outputPath/exported. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### buildLibsFromSource - -Default: `true` - -Type: `boolean` - -Read buildable libraries from source instead of building them separately. - -### buildTarget - -Type: `string` - -Target which builds the application - -### silent - -Default: `false` - -Type: `boolean` - -Hide progress or not (default is false) - -### threads - -Type: `number` - -Number of worker threads to utilize (defaults to the number of CPUs) diff --git a/nx-dev/nx-dev/public/documentation/generated/api-next/executors/server.md b/nx-dev/nx-dev/public/documentation/generated/api-next/executors/server.md deleted file mode 100644 index 7d3baf7f3e..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-next/executors/server.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: '@nrwl/next:server executor' -description: 'Serve a Next.js app' ---- - -# @nrwl/next:server - -Serve a Next.js app - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### buildTarget (_**required**_) - -Type: `string` - -Target which builds the application - -### buildLibsFromSource - -Default: `true` - -Type: `boolean` - -Read buildable libraries from source instead of building them separately. - -### customServerPath - -Type: `string` - -Use a custom server script - -### dev - -Default: `true` - -Type: `boolean` - -Serve the application in the dev mode - -### hostname - -Type: `string` - -Hostname on which the application is served. - -### port - -Default: `4200` - -Type: `number` - -Port to listen on. - -### proxyConfig - -Type: `string` - -Path to the proxy configuration file. - -### quiet - -Default: `false` - -Type: `boolean` - -Hide error messages containing server information. - -### staticMarkup - -Default: `false` - -Type: `boolean` - -Static markup. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-next/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-next/generators/application.md deleted file mode 100644 index 03d7b90102..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-next/generators/application.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: '@nrwl/next:application generator' -description: 'Create a Next.js application' ---- - -# @nrwl/next:application - -Create a Next.js application - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/next:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -### Examples - -Generate apps/myorg/myapp and apps/myorg/myapp-e2e: - -```bash -nx g app myapp --directory=myorg -``` - -## Options - -### directory - -Alias(es): d - -Type: `string` - -The directory of the new application. - -### e2eTestRunner - -Default: `cypress` - -Type: `string` - -Possible values: `cypress`, `none` - -Test runner to use for end to end (e2e) tests - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### name - -Type: `string` - -The name of the application. - -### server - -Type: `string` - -The server script path to be used with next. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### skipWorkspaceJson - -Default: `false` - -Type: `boolean` - -Skip updating workspace.json with default options based on values provided to this app (e.g. babel, style) - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### style - -Alias(es): s - -Default: `css` - -Type: `string` - -Possible values: `css`, `scss`, `styl`, `less`, `styled-components`, `@emotion/styled`, `styled-jsx` - -The file extension to be used for style files. - -### swc - -Default: `true` - -Type: `boolean` - -Enable the Rust-based compiler SWC to compile JS/TS files. - -### tags - -Alias(es): t - -Type: `string` - -Add tags to the application (used for linting) - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-next/generators/component.md b/nx-dev/nx-dev/public/documentation/generated/api-next/generators/component.md deleted file mode 100644 index b3528c8138..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-next/generators/component.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: '@nrwl/next:component generator' -description: 'Create a React component' ---- - -# @nrwl/next:component - -Create a React component - -## Usage - -```bash -nx generate component ... -``` - -By default, Nx will search for `component` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/next:component ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g component ... --dry-run -``` - -### Examples - -Generate a component in the mylib library: - -```bash -nx g component my-component --project=mylib -``` - -Generate a class component in the mylib library: - -```bash -nx g component my-component --project=mylib --classComponent -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the component. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The name of the project. - -### directory - -Alias(es): dir - -Type: `string` - -Create the component under this directory (can be nested). - -### export - -Alias(es): e - -Default: `false` - -Type: `boolean` - -When true, the component is exported from the project index.ts (if it exists). - -### flat - -Default: `false` - -Type: `boolean` - -Create component at the source root rather than its own directory. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### skipTests - -Default: `false` - -Type: `boolean` - -When true, does not create "spec.ts" test files for the new component. - -### style - -Alias(es): s - -Default: `css` - -Type: `string` - -Possible values: `css`, `scss`, `styl`, `less`, `styled-components`, `@emotion/styled`, `styled-jsx` - -The file extension to be used for style files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-next/generators/page.md b/nx-dev/nx-dev/public/documentation/generated/api-next/generators/page.md deleted file mode 100644 index df12dbd371..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-next/generators/page.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: '@nrwl/next:page generator' -description: 'Create a Next.js page component' ---- - -# @nrwl/next:page - -Create a Next.js page component - -## Usage - -```bash -nx generate page ... -``` - -By default, Nx will search for `page` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/next:page ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g page ... --dry-run -``` - -### Examples - -Generate a page in the my-app application: - -```bash -nx nx g page my-new-page --project=my-app -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the component. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The name of the project. - -### directory - -Alias(es): dir - -Type: `string` - -Create the page under this directory (can be nested). Will be created under 'pages/'. - -### export - -Alias(es): e - -Default: `false` - -Type: `boolean` - -When true, the component is exported from the project index.ts (if it exists). - -### flat - -Default: `false` - -Type: `boolean` - -Create component at the source root rather than its own directory. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### style - -Alias(es): s - -Default: `css` - -Type: `string` - -Possible values: `css`, `scss`, `styl`, `less`, `styled-components`, `@emotion/styled`, `styled-jsx`, `none` - -The file extension to be used for style files. - -### withTests - -Default: `false` - -Type: `boolean` - -When true, creates a "spec.ts" test file for the new page. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-node/executors/build.md b/nx-dev/nx-dev/public/documentation/generated/api-node/executors/build.md deleted file mode 100644 index e7334603f1..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-node/executors/build.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -title: '@nrwl/node:build executor' -description: 'Build a Node application' ---- - -# @nrwl/node:build - -Build a Node application - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### main (_**required**_) - -Type: `string` - -The name of the main entry-point file. - -### tsConfig (_**required**_) - -Type: `string` - -The name of the Typescript configuration file. - -### additionalEntryPoints - -Type: `object[]` - -#### entryName - -Type: `string` - -Name of the additional entry file - -#### entryPath - -Type: `string` - -Path to the additional entry file - -### assets - -Type: `array` - -List of static application assets. - -### buildLibsFromSource - -Default: `true` - -Type: `boolean` - -Read buildable libraries from source instead of building them separately. - -### externalDependencies - -Default: `all` - -Type: `string | string[] ` - -Dependencies to keep external to the bundle. ("all" (default), "none", or an array of module names) - -### extractLicenses - -Default: `false` - -Type: `boolean` - -Extract all licenses in a separate file, in the case of production builds only. - -### fileReplacements - -Type: `object[]` - -Replace files with other files in the build. - -#### replace - -Type: `string` - -The file to be replaced. - -#### with - -Type: `string` - -The file to replace with. - -### generatePackageJson - -Default: `false` - -Type: `boolean` - -Generates a package.json file with the project's node_module dependencies populated for installing in a container. If a package.json exists in the project's directory, it will be reused with dependencies populated. - -### maxWorkers - -Type: `number` - -Number of workers to use for type checking. (defaults to # of CPUS - 2) - -### memoryLimit - -Type: `number` - -Memory limit for type checking service process in MB. (defaults to 2048) - -### optimization - -Default: `false` - -Type: `boolean` - -Defines the optimization level of the build. - -### outputFileName - -Default: `main.js` - -Type: `string` - -Name of the main output file. (defaults to 'main.js') - -### outputPath - -Type: `string` - -The output path of the generated files. - -### poll - -Type: `number` - -Frequency of file watcher in ms. - -### progress - -Default: `false` - -Type: `boolean` - -Log progress to the console while building. - -### sourceMap - -Default: `true` - -Type: `boolean` - -Produce source maps. - -### statsJson - -Default: `false` - -Type: `boolean` - -Generates a 'stats.json' file which can be analyzed using tools such as: 'webpack-bundle-analyzer' or . - -### tsPlugins - -Type: `array` - -List of TypeScript Compiler Plugins. - -### verbose - -Default: `false` - -Type: `boolean` - -Emits verbose output - -### watch - -Default: `false` - -Type: `boolean` - -Run build when files change. - -### webpackConfig - -Type: `array[] | string ` - -Path to a function which takes a webpack config, context and returns the resulting webpack config diff --git a/nx-dev/nx-dev/public/documentation/generated/api-node/executors/execute.md b/nx-dev/nx-dev/public/documentation/generated/api-node/executors/execute.md deleted file mode 100644 index b90e8bedd7..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-node/executors/execute.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: '@nrwl/node:execute executor' -description: 'Execute a Node application' ---- - -# @nrwl/node:execute - -Execute a Node application - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### buildTarget (_**required**_) - -Type: `string` - -The target to run to build you the app - -### args - -Type: `array` - -Extra args when starting the app - -### host - -Default: `localhost` - -Type: `string` - -The host to inspect the process on - -### inspect - -Default: `inspect` - -Type: `string | boolean ` - -Ensures the app is starting with debugging - -### port - -Default: `9229` - -Type: `number` - -The port to inspect the process on. Setting port to 0 will assign random free ports to all forked processes. - -### runtimeArgs - -Type: `array` - -Extra args passed to the node process - -### waitUntilTargets - -Type: `array` - -The targets to run to before starting the node app - -### watch - -Default: `true` - -Type: `boolean` - -Run build when files change diff --git a/nx-dev/nx-dev/public/documentation/generated/api-node/executors/package.md b/nx-dev/nx-dev/public/documentation/generated/api-node/executors/package.md deleted file mode 100644 index 8791c8fb39..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-node/executors/package.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: '@nrwl/node:package executor' -description: 'Package a Node library' ---- - -# @nrwl/node:package - -Package a Node library - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### main (_**required**_) - -Type: `string` - -The name of the main entry-point file. - -### tsConfig (_**required**_) - -Type: `string` - -The name of the Typescript configuration file. - -### assets - -Type: `array` - -List of static library assets. - -### buildableProjectDepsInPackageJsonType - -Default: `dependencies` - -Type: `string` - -Possible values: `dependencies`, `peerDependencies` - -When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` - -### cli - -Type: `boolean` - -Adds a CLI wrapper to main entry-point file. - -### deleteOutputPath - -Default: `true` - -Type: `boolean` - -Delete the output path before building. - -### outputPath - -Type: `string` - -The output path of the generated files. - -### packageJson - -Type: `string` - -The name of the package.json file - -### sourceMap - -Default: `true` - -Type: `boolean` - -Output sourcemaps. - -### srcRootForCompilationRoot - -Type: `string` - -Sets the rootDir for TypeScript compilation. When not defined, it uses the project's root property - -### tsPlugins - -Type: `array` - -List of TypeScript Compiler Plugins. - -### updateBuildableProjectDepsInPackageJson - -Default: `true` - -Type: `boolean` - -Update buildable project dependencies in package.json - -### watch - -Default: `false` - -Type: `boolean` - -Enable re-building when files change. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-node/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-node/generators/application.md deleted file mode 100644 index 3144b0ab63..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-node/generators/application.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: '@nrwl/node:application generator' -description: 'Create a node application' ---- - -# @nrwl/node:application - -Create a node application - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/node:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -## Options - -### babelJest - -Default: `false` - -Type: `boolean` - -Use babel instead ts-jest - -### directory - -Type: `string` - -The directory of the new application. - -### frontendProject - -Type: `string` - -Frontend project that needs to access this application. This sets up proxy configuration. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### name - -Type: `string` - -The name of the application. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case file names. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### skipPackageJson - -Default: `false` - -Type: `boolean` - -Do not add dependencies to package.json. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### tags - -Type: `string` - -Add tags to the application (used for linting) - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-node/generators/library.md b/nx-dev/nx-dev/public/documentation/generated/api-node/generators/library.md deleted file mode 100644 index 7125261ae5..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-node/generators/library.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -title: '@nrwl/node:library generator' -description: 'Create a library' ---- - -# @nrwl/node:library - -Create a library - -## Usage - -```bash -nx generate library ... -``` - -```bash -nx g lib ... # same -``` - -By default, Nx will search for `library` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/node:library ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g library ... --dry-run -``` - -### Examples - -Generate libs/myapp/mylib: - -```bash -nx g lib mylib --directory=myapp -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Library name - -### babelJest - -Default: `false` - -Type: `boolean` - -Use babel instead ts-jest - -### buildable - -Default: `false` - -Type: `boolean` - -Generate a buildable library. - -### directory - -Alias(es): dir - -Type: `string` - -A directory where the lib is placed - -### importPath - -Type: `string` - -The library name used to import it, like @myorg/my-awesome-lib. Must be a valid npm name. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case file names. - -### publishable - -Type: `boolean` - -Create a publishable library. - -### rootDir - -Alias(es): srcRootForCompilationRoot - -Type: `string` - -Sets the rootDir for TypeScript compilation. When not defined, it uses the project's root property, or srcRootForCompilationRoot if it is defined. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### simpleModuleName - -Default: `false` - -Type: `boolean` - -Keep the module name simple (when using --directory) - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### skipTsConfig - -Default: `false` - -Type: `boolean` - -Do not update tsconfig.base.json for development experience. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### strict - -Default: `false` - -Type: `boolean` - -Whether to enable tsconfig strict mode or not. - -### tags - -Alias(es): t - -Type: `string` - -Add tags to the library (used for linting) - -### testEnvironment - -Default: `jsdom` - -Type: `string` - -Possible values: `jsdom`, `node` - -The test environment to use if unitTestRunner is set to jest - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nx-devkit/index.md b/nx-dev/nx-dev/public/documentation/generated/api-nx-devkit/index.md deleted file mode 100644 index c2abb4f5b4..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nx-devkit/index.md +++ /dev/null @@ -1,1646 +0,0 @@ -# Module: index - -The Nx Devkit is the underlying technology used to customize Nx to support -different technologies and custom use-cases. It contains many utility -functions for reading and writing files, updating configuration, -working with Abstract Syntax Trees(ASTs), and more. - -As with most things in Nx, the core of Nx Devkit is very simple. -It only uses language primitives and immutable objects -(the tree being the only exception). - -## Table of contents - -### Project Graph Enumerations - -- [DependencyType](../../nx-devkit/index#dependencytype) - -### Utils Enumerations - -- [ChangeType](../../nx-devkit/index#changetype) - -### Project Graph Classes - -- [ProjectGraphBuilder](../../nx-devkit/index#projectgraphbuilder) - -### Commands Interfaces - -- [Target](../../nx-devkit/index#target) - -### Other Interfaces - -- [NxPlugin](../../nx-devkit/index#nxplugin) - -### Project Graph Interfaces - -- [FileData](../../nx-devkit/index#filedata) -- [ProjectFileMap](../../nx-devkit/index#projectfilemap) -- [ProjectGraph](../../nx-devkit/index#projectgraph) -- [ProjectGraphDependency](../../nx-devkit/index#projectgraphdependency) -- [ProjectGraphExternalNode](../../nx-devkit/index#projectgraphexternalnode) -- [ProjectGraphProcessorContext](../../nx-devkit/index#projectgraphprocessorcontext) -- [ProjectGraphProjectNode](../../nx-devkit/index#projectgraphprojectnode) - -### Tree Interfaces - -- [FileChange](../../nx-devkit/index#filechange) -- [Tree](../../nx-devkit/index#tree) - -### Utils Interfaces - -- [JsonParseOptions](../../nx-devkit/index#jsonparseoptions) -- [JsonSerializeOptions](../../nx-devkit/index#jsonserializeoptions) -- [StringDeletion](../../nx-devkit/index#stringdeletion) -- [StringInsertion](../../nx-devkit/index#stringinsertion) - -### Workspace Interfaces - -- [ExecutorContext](../../nx-devkit/index#executorcontext) -- [ImplicitJsonSubsetDependency](../../nx-devkit/index#implicitjsonsubsetdependency) -- [NxAffectedConfig](../../nx-devkit/index#nxaffectedconfig) -- [NxJsonConfiguration](../../nx-devkit/index#nxjsonconfiguration) -- [NxJsonProjectConfiguration](../../nx-devkit/index#nxjsonprojectconfiguration) -- [ProjectConfiguration](../../nx-devkit/index#projectconfiguration) -- [TargetConfiguration](../../nx-devkit/index#targetconfiguration) -- [TargetDependencyConfig](../../nx-devkit/index#targetdependencyconfig) -- [Task](../../nx-devkit/index#task) -- [TaskGraph](../../nx-devkit/index#taskgraph) -- [Workspace](../../nx-devkit/index#workspace) -- [WorkspaceJsonConfiguration](../../nx-devkit/index#workspacejsonconfiguration) - -### Generators Type aliases - -- [WorkspaceConfiguration](../../nx-devkit/index#workspaceconfiguration) - -### Other Type aliases - -- [ProjectTargetConfigurator](../../nx-devkit/index#projecttargetconfigurator) - -### Package Manager Type aliases - -- [PackageManager](../../nx-devkit/index#packagemanager) - -### Project Graph Type aliases - -- [ProjectGraphNode](../../nx-devkit/index#projectgraphnode) - -### Utils Type aliases - -- [StringChange](../../nx-devkit/index#stringchange) - -### Workspace Type aliases - -- [Executor](../../nx-devkit/index#executor) -- [Generator](../../nx-devkit/index#generator) -- [GeneratorCallback](../../nx-devkit/index#generatorcallback) -- [ImplicitDependencyEntry](../../nx-devkit/index#implicitdependencyentry) -- [ProjectType](../../nx-devkit/index#projecttype) -- [TaskGraphExecutor](../../nx-devkit/index#taskgraphexecutor) - -### Logger Variables - -- [logger](../../nx-devkit/index#logger) - -### Functions - -- [addDependenciesToPackageJson](../../nx-devkit/index#adddependenciestopackagejson) -- [addProjectConfiguration](../../nx-devkit/index#addprojectconfiguration) -- [applyChangesToString](../../nx-devkit/index#applychangestostring) -- [convertNxExecutor](../../nx-devkit/index#convertnxexecutor) -- [convertNxGenerator](../../nx-devkit/index#convertnxgenerator) -- [detectPackageManager](../../nx-devkit/index#detectpackagemanager) -- [formatFiles](../../nx-devkit/index#formatfiles) -- [generateFiles](../../nx-devkit/index#generatefiles) -- [getPackageManagerCommand](../../nx-devkit/index#getpackagemanagercommand) -- [getPackageManagerVersion](../../nx-devkit/index#getpackagemanagerversion) -- [getProjects](../../nx-devkit/index#getprojects) -- [getWorkspaceLayout](../../nx-devkit/index#getworkspacelayout) -- [getWorkspacePath](../../nx-devkit/index#getworkspacepath) -- [installPackagesTask](../../nx-devkit/index#installpackagestask) -- [isStandaloneProject](../../nx-devkit/index#isstandaloneproject) -- [joinPathFragments](../../nx-devkit/index#joinpathfragments) -- [moveFilesToNewDirectory](../../nx-devkit/index#movefilestonewdirectory) -- [names](../../nx-devkit/index#names) -- [normalizePath](../../nx-devkit/index#normalizepath) -- [offsetFromRoot](../../nx-devkit/index#offsetfromroot) -- [parseJson](../../nx-devkit/index#parsejson) -- [parseTargetString](../../nx-devkit/index#parsetargetstring) -- [readJson](../../nx-devkit/index#readjson) -- [readJsonFile](../../nx-devkit/index#readjsonfile) -- [readProjectConfiguration](../../nx-devkit/index#readprojectconfiguration) -- [readTargetOptions](../../nx-devkit/index#readtargetoptions) -- [readWorkspaceConfiguration](../../nx-devkit/index#readworkspaceconfiguration) -- [removeDependenciesFromPackageJson](../../nx-devkit/index#removedependenciesfrompackagejson) -- [removeProjectConfiguration](../../nx-devkit/index#removeprojectconfiguration) -- [runExecutor](../../nx-devkit/index#runexecutor) -- [serializeJson](../../nx-devkit/index#serializejson) -- [stripIndents](../../nx-devkit/index#stripindents) -- [stripJsonComments](../../nx-devkit/index#stripjsoncomments) -- [targetToTargetString](../../nx-devkit/index#targettotargetstring) -- [toJS](../../nx-devkit/index#tojs) -- [updateJson](../../nx-devkit/index#updatejson) -- [updateProjectConfiguration](../../nx-devkit/index#updateprojectconfiguration) -- [updateTsConfigsToJs](../../nx-devkit/index#updatetsconfigstojs) -- [updateWorkspaceConfiguration](../../nx-devkit/index#updateworkspaceconfiguration) -- [visitNotIgnoredFiles](../../nx-devkit/index#visitnotignoredfiles) -- [writeJson](../../nx-devkit/index#writejson) -- [writeJsonFile](../../nx-devkit/index#writejsonfile) - -## Project Graph Enumerations - -### DependencyType - -• **DependencyType**: `Object` - ---- - -## Utils Enumerations - -### ChangeType - -• **ChangeType**: `Object` - -## Project Graph Classes - -### ProjectGraphBuilder - -• **ProjectGraphBuilder**: `Object` - -## Commands Interfaces - -### Target - -• **Target**: `Object` - ---- - -## Other Interfaces - -### NxPlugin - -• **NxPlugin**: `Object` - -A plugin for Nx - ---- - -## Project Graph Interfaces - -### FileData - -• **FileData**: `Object` - ---- - -### ProjectFileMap - -• **ProjectFileMap**: `Object` - ---- - -### ProjectGraph - -• **ProjectGraph**<`T`\>: `Object` - -#### Type parameters - -| Name | Type | -| :--- | :---- | -| `T` | `any` | - ---- - -### ProjectGraphDependency - -• **ProjectGraphDependency**: `Object` - ---- - -### ProjectGraphExternalNode - -• **ProjectGraphExternalNode**: `Object` - ---- - -### ProjectGraphProcessorContext - -• **ProjectGraphProcessorContext**: `Object` - ---- - -### ProjectGraphProjectNode - -• **ProjectGraphProjectNode**<`T`\>: `Object` - -#### Type parameters - -| Name | Type | -| :--- | :---- | -| `T` | `any` | - ---- - -## Tree Interfaces - -### FileChange - -• **FileChange**: `Object` - ---- - -### Tree - -• **Tree**: `Object` - ---- - -## Utils Interfaces - -### JsonParseOptions - -• **JsonParseOptions**: `Object` - ---- - -### JsonSerializeOptions - -• **JsonSerializeOptions**: `Object` - ---- - -### StringDeletion - -• **StringDeletion**: `Object` - ---- - -### StringInsertion - -• **StringInsertion**: `Object` - ---- - -## Workspace Interfaces - -### ExecutorContext - -• **ExecutorContext**: `Object` - ---- - -### ImplicitJsonSubsetDependency - -• **ImplicitJsonSubsetDependency**<`T`\>: `Object` - -#### Type parameters - -| Name | Type | -| :--- | :------------------ | -| `T` | `"*"` \| `string`[] | - ---- - -### NxAffectedConfig - -• **NxAffectedConfig**: `Object` - ---- - -### NxJsonConfiguration - -• **NxJsonConfiguration**<`T`\>: `Object` - -#### Type parameters - -| Name | Type | -| :--- | :------------------ | -| `T` | `"*"` \| `string`[] | - ---- - -### NxJsonProjectConfiguration - -• **NxJsonProjectConfiguration**: `Object` - ---- - -### ProjectConfiguration - -• **ProjectConfiguration**: `Object` - ---- - -### TargetConfiguration - -• **TargetConfiguration**: `Object` - ---- - -### TargetDependencyConfig - -• **TargetDependencyConfig**: `Object` - ---- - -### Task - -• **Task**: `Object` - ---- - -### TaskGraph - -• **TaskGraph**: `Object` - ---- - -### Workspace - -• **Workspace**: `Object` - ---- - -### WorkspaceJsonConfiguration - -• **WorkspaceJsonConfiguration**: `Object` - -## Generators Type aliases - -### WorkspaceConfiguration - -Ƭ **WorkspaceConfiguration**: `Omit`<[`WorkspaceJsonConfiguration`](../../nx-devkit/index#workspacejsonconfiguration), `"projects"`\> & `Partial`<[`NxJsonConfiguration`](../../nx-devkit/index#nxjsonconfiguration)\> - ---- - -## Other Type aliases - -### ProjectTargetConfigurator - -Ƭ **ProjectTargetConfigurator**: (`file`: `string`) => `Record`<`string`, [`TargetConfiguration`](../../nx-devkit/index#targetconfiguration)\> - -#### Type declaration - -▸ (`file`): `Record`<`string`, [`TargetConfiguration`](../../nx-devkit/index#targetconfiguration)\> - -##### Parameters - -| Name | Type | -| :----- | :------- | -| `file` | `string` | - -##### Returns - -`Record`<`string`, [`TargetConfiguration`](../../nx-devkit/index#targetconfiguration)\> - ---- - -## Package Manager Type aliases - -### PackageManager - -Ƭ **PackageManager**: `"yarn"` \| `"pnpm"` \| `"npm"` - ---- - -## Project Graph Type aliases - -### ProjectGraphNode - -Ƭ **ProjectGraphNode**<`T`\>: [`ProjectGraphProjectNode`](../../nx-devkit/index#projectgraphprojectnode)<`T`\> \| [`ProjectGraphExternalNode`](../../nx-devkit/index#projectgraphexternalnode) - -#### Type parameters - -| Name | Type | -| :--- | :---- | -| `T` | `any` | - ---- - -## Utils Type aliases - -### StringChange - -Ƭ **StringChange**: [`StringInsertion`](../../nx-devkit/index#stringinsertion) \| [`StringDeletion`](../../nx-devkit/index#stringdeletion) - ---- - -## Workspace Type aliases - -### Executor - -Ƭ **Executor**<`T`\>: (`options`: `T`, `context`: [`ExecutorContext`](../../nx-devkit/index#executorcontext)) => `Promise`<`Object`\> \| `AsyncIterableIterator`<`Object`\> - -#### Type parameters - -| Name | Type | -| :--- | :---- | -| `T` | `any` | - -#### Type declaration - -▸ (`options`, `context`): `Promise`<`Object`\> \| `AsyncIterableIterator`<`Object`\> - -Implementation of a target of a project - -##### Parameters - -| Name | Type | -| :-------- | :--------------------------------------------------------- | -| `options` | `T` | -| `context` | [`ExecutorContext`](../../nx-devkit/index#executorcontext) | - -##### Returns - -`Promise`<`Object`\> \| `AsyncIterableIterator`<`Object`\> - ---- - -### Generator - -Ƭ **Generator**<`T`\>: (`tree`: `any`, `schema`: `T`) => `void` \| [`GeneratorCallback`](../../nx-devkit/index#generatorcallback) \| `Promise`<`void` \| [`GeneratorCallback`](../../nx-devkit/index#generatorcallback)\> - -#### Type parameters - -| Name | Type | -| :--- | :-------- | -| `T` | `unknown` | - -#### Type declaration - -▸ (`tree`, `schema`): `void` \| [`GeneratorCallback`](../../nx-devkit/index#generatorcallback) \| `Promise`<`void` \| [`GeneratorCallback`](../../nx-devkit/index#generatorcallback)\> - -A function that schedules updates to the filesystem to be done atomically - -##### Parameters - -| Name | Type | -| :------- | :---- | -| `tree` | `any` | -| `schema` | `T` | - -##### Returns - -`void` \| [`GeneratorCallback`](../../nx-devkit/index#generatorcallback) \| `Promise`<`void` \| [`GeneratorCallback`](../../nx-devkit/index#generatorcallback)\> - ---- - -### GeneratorCallback - -Ƭ **GeneratorCallback**: () => `void` \| `Promise`<`void`\> - -#### Type declaration - -▸ (): `void` \| `Promise`<`void`\> - -A callback function that is executed after changes are made to the file system - -##### Returns - -`void` \| `Promise`<`void`\> - ---- - -### ImplicitDependencyEntry - -Ƭ **ImplicitDependencyEntry**<`T`\>: `Object` - -#### Type parameters - -| Name | Type | -| :--- | :------------------ | -| `T` | `"*"` \| `string`[] | - -#### Index signature - -▪ [key: `string`]: `T` \| [`ImplicitJsonSubsetDependency`](../../nx-devkit/index#implicitjsonsubsetdependency)<`T`\> - ---- - -### ProjectType - -Ƭ **ProjectType**: `"library"` \| `"application"` - ---- - -### TaskGraphExecutor - -Ƭ **TaskGraphExecutor**<`T`\>: (`taskGraph`: [`TaskGraph`](../../nx-devkit/index#taskgraph), `options`: `Record`<`string`, `T`\>, `overrides`: `T`, `context`: [`ExecutorContext`](../../nx-devkit/index#executorcontext)) => `Promise`<`Record`<`string`, `Object`\>\> - -#### Type parameters - -| Name | Type | -| :--- | :---- | -| `T` | `any` | - -#### Type declaration - -▸ (`taskGraph`, `options`, `overrides`, `context`): `Promise`<`Record`<`string`, `Object`\>\> - -Implementation of a target of a project that handles multiple projects to be batched - -##### Parameters - -| Name | Type | -| :---------- | :--------------------------------------------------------- | -| `taskGraph` | [`TaskGraph`](../../nx-devkit/index#taskgraph) | -| `options` | `Record`<`string`, `T`\> | -| `overrides` | `T` | -| `context` | [`ExecutorContext`](../../nx-devkit/index#executorcontext) | - -##### Returns - -`Promise`<`Record`<`string`, `Object`\>\> - -## Logger Variables - -### logger - -• **logger**: `Object` - -#### Type declaration - -| Name | Type | -| :------ | :-------------------------- | -| `debug` | (...`s`: `any`[]) => `void` | -| `error` | (`s`: `any`) => `void` | -| `fatal` | (...`s`: `any`[]) => `void` | -| `info` | (`s`: `any`) => `void` | -| `log` | (...`s`: `any`[]) => `void` | -| `warn` | (`s`: `any`) => `void` | - -## Functions - -### addDependenciesToPackageJson - -▸ **addDependenciesToPackageJson**(`tree`, `dependencies`, `devDependencies`, `packageJsonPath?`): [`GeneratorCallback`](../../nx-devkit/index#generatorcallback) - -Add Dependencies and Dev Dependencies to package.json - -For example: - -```typescript -addDependenciesToPackageJson(tree, { react: 'latest' }, { jest: 'latest' }); -``` - -This will **add** `react` and `jest` to the dependencies and devDependencies sections of package.json respectively. - -#### Parameters - -| Name | Type | Default value | Description | -| :---------------- | :----------------------------------- | :--------------- | :---------------------------------------------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | `undefined` | Tree representing file system to modify | -| `dependencies` | `Record`<`string`, `string`\> | `undefined` | Dependencies to be added to the dependencies section of package.json | -| `devDependencies` | `Record`<`string`, `string`\> | `undefined` | Dependencies to be added to the devDependencies section of package.json | -| `packageJsonPath` | `string` | `'package.json'` | Path to package.json | - -#### Returns - -[`GeneratorCallback`](../../nx-devkit/index#generatorcallback) - -Callback to install dependencies only if necessary. undefined is returned if changes are not necessary. - ---- - -### addProjectConfiguration - -▸ **addProjectConfiguration**(`tree`, `projectName`, `projectConfiguration`, `standalone?`): `void` - -Adds project configuration to the Nx workspace. - -The project configuration is stored in workspace.json or the associated project.json file. -The utility will update either files. - -#### Parameters - -| Name | Type | Description | -| :--------------------- | :------------------------------------------------------------------- | :----------------------------------------------------------------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | the file system tree | -| `projectName` | `string` | unique name. Often directories are part of the name (e.g., mydir-mylib) | -| `projectConfiguration` | [`ProjectConfiguration`](../../nx-devkit/index#projectconfiguration) | project configuration | -| `standalone?` | `boolean` | should the project use package.json? If false, the project config is inside workspace.json | - -#### Returns - -`void` - ---- - -### applyChangesToString - -▸ **applyChangesToString**(`text`, `changes`): `string` - -Applies a list of changes to a string's original value. - -This is useful when working with ASTs. - -For Example, to rename a property in a method's options: - -```typescript -const code = `bootstrap({ - target: document.querySelector('#app') -})`; - -const indexOfPropertyName = 13; // Usually determined by analyzing an AST. -const updatedCode = applyChangesToString(code, [ - { - type: ChangeType.Insert, - index: indexOfPropertyName, - text: 'element', - }, - { - type: ChangeType.Delete, - start: indexOfPropertyName, - length: 6, - }, -]); - -bootstrap({ - element: document.querySelector('#app'), -}); -``` - -#### Parameters - -| Name | Type | -| :-------- | :----------------------------------------------------- | -| `text` | `string` | -| `changes` | [`StringChange`](../../nx-devkit/index#stringchange)[] | - -#### Returns - -`string` - ---- - -### convertNxExecutor - -▸ **convertNxExecutor**(`executor`): `any` - -Convert an Nx Executor into an Angular Devkit Builder - -Use this to expose a compatible Angular Builder - -#### Parameters - -| Name | Type | -| :--------- | :--------------------------------------------------- | -| `executor` | [`Executor`](../../nx-devkit/index#executor)<`any`\> | - -#### Returns - -`any` - ---- - -### convertNxGenerator - -▸ **convertNxGenerator**<`T`\>(`generator`): (`options`: `T`) => (`tree`: `any`, `context`: `any`) => `Promise`<`any`\> - -Convert an Nx Generator into an Angular Devkit Schematic - -#### Type parameters - -| Name | Type | -| :--- | :---- | -| `T` | `any` | - -#### Parameters - -| Name | Type | -| :---------- | :--------------------------------------------------- | -| `generator` | [`Generator`](../../nx-devkit/index#generator)<`T`\> | - -#### Returns - -`fn` - -▸ (`options`): (`tree`: `any`, `context`: `any`) => `Promise`<`any`\> - -##### Parameters - -| Name | Type | -| :-------- | :--- | -| `options` | `T` | - -##### Returns - -`fn` - -▸ (`tree`, `context`): `Promise`<`any`\> - -##### Parameters - -| Name | Type | -| :-------- | :---- | -| `tree` | `any` | -| `context` | `any` | - -##### Returns - -`Promise`<`any`\> - ---- - -### detectPackageManager - -▸ **detectPackageManager**(`dir?`): [`PackageManager`](../../nx-devkit/index#packagemanager) - -Detects which package manager is used in the workspace based on the lock file. - -#### Parameters - -| Name | Type | Default value | -| :---- | :------- | :------------ | -| `dir` | `string` | `''` | - -#### Returns - -[`PackageManager`](../../nx-devkit/index#packagemanager) - ---- - -### formatFiles - -▸ **formatFiles**(`tree`): `Promise`<`void`\> - -Formats all the created or updated files using Prettier - -#### Parameters - -| Name | Type | Description | -| :----- | :----------------------------------- | :------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | the file system tree | - -#### Returns - -`Promise`<`void`\> - ---- - -### generateFiles - -▸ **generateFiles**(`tree`, `srcFolder`, `target`, `substitutions`): `void` - -Generates a folder of files based on provided templates. - -While doing so it performs two substitutions: - -- Substitutes segments of file names surrounded by \_\_ -- Uses ejs to substitute values in templates - -Examples: - -```typescript -generateFiles(tree, path.join(__dirname, 'files'), './tools/scripts', { - tmpl: '', - name: 'myscript', -}); -``` - -This command will take all the files from the `files` directory next to the place where the command is invoked from. -It will replace all `__tmpl__` with '' and all `__name__` with 'myscript' in the file names, and will replace all -`<%= name %>` with `myscript` in the files themselves. -`tmpl: ''` is a common pattern. With it you can name files like this: `index.ts__tmpl__`, so your editor -doesn't get confused about incorrect TypeScript files. - -#### Parameters - -| Name | Type | Description | -| :-------------- | :----------------------------------- | :-------------------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | the file system tree | -| `srcFolder` | `string` | the source folder of files (absolute path) | -| `target` | `string` | the target folder (relative to the tree root) | -| `substitutions` | `Object` | an object of key-value pairs | - -#### Returns - -`void` - ---- - -### getPackageManagerCommand - -▸ **getPackageManagerCommand**(`packageManager?`): `PackageManagerCommands` - -Returns commands for the package manager used in the workspace. -By default, the package manager is derived based on the lock file, -but it can also be passed in explicitly. - -Example: - -```javascript -execSync(`${getPackageManagerCommand().addDev} my-dev-package`); -``` - -#### Parameters - -| Name | Type | -| :--------------- | :------------------------------------------------------- | -| `packageManager` | [`PackageManager`](../../nx-devkit/index#packagemanager) | - -#### Returns - -`PackageManagerCommands` - ---- - -### getPackageManagerVersion - -▸ **getPackageManagerVersion**(`packageManager?`): `string` - -Returns the version of the package manager used in the workspace. -By default, the package manager is derived based on the lock file, -but it can also be passed in explicitly. - -#### Parameters - -| Name | Type | -| :--------------- | :------------------------------------------------------- | -| `packageManager` | [`PackageManager`](../../nx-devkit/index#packagemanager) | - -#### Returns - -`string` - ---- - -### getProjects - -▸ **getProjects**(`tree`): `Map`<`string`, [`ProjectConfiguration`](../../nx-devkit/index#projectconfiguration)\> - -Get a map of all projects in a workspace. - -Use [readProjectConfiguration](../../nx-devkit/index#readprojectconfiguration) if only one project is needed. - -#### Parameters - -| Name | Type | -| :----- | :----------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | - -#### Returns - -`Map`<`string`, [`ProjectConfiguration`](../../nx-devkit/index#projectconfiguration)\> - ---- - -### getWorkspaceLayout - -▸ **getWorkspaceLayout**(`tree`): `Object` - -Returns workspace defaults. It includes defaults folders for apps and libs, -and the default scope. - -Example: - -```typescript -{ appsDir: 'apps', libsDir: 'libs', npmScope: 'myorg' } -``` - -#### Parameters - -| Name | Type | Description | -| :----- | :----------------------------------- | :--------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | file system tree | - -#### Returns - -`Object` - -| Name | Type | -| :-------------------- | :-------- | -| `appsDir` | `string` | -| `libsDir` | `string` | -| `npmScope` | `string` | -| `standaloneAsDefault` | `boolean` | - ---- - -### getWorkspacePath - -▸ **getWorkspacePath**(`tree`): `"/angular.json"` \| `"/workspace.json"` \| `null` - -#### Parameters - -| Name | Type | -| :----- | :----------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | - -#### Returns - -`"/angular.json"` \| `"/workspace.json"` \| `null` - ---- - -### installPackagesTask - -▸ **installPackagesTask**(`tree`, `alwaysRun?`, `cwd?`, `packageManager?`): `void` - -Runs `npm install` or `yarn install`. It will skip running the install if -`package.json` hasn't changed at all or it hasn't changed since the last invocation. - -#### Parameters - -| Name | Type | Default value | Description | -| :--------------- | :------------------------------------------------------- | :------------ | :------------------------------------------------------------ | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | `undefined` | the file system tree | -| `alwaysRun` | `boolean` | `false` | always run the command even if `package.json` hasn't changed. | -| `cwd` | `string` | `''` | - | -| `packageManager` | [`PackageManager`](../../nx-devkit/index#packagemanager) | `undefined` | - | - -#### Returns - -`void` - ---- - -### isStandaloneProject - -▸ **isStandaloneProject**(`tree`, `project`): `boolean` - -Returns if a project has a standalone configuration (project.json). - -#### Parameters - -| Name | Type | Description | -| :-------- | :----------------------------------- | :------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | the file system tree | -| `project` | `string` | the project name | - -#### Returns - -`boolean` - ---- - -### joinPathFragments - -▸ **joinPathFragments**(...`fragments`): `string` - -Normalized path fragments and joins them - -#### Parameters - -| Name | Type | -| :------------- | :--------- | -| `...fragments` | `string`[] | - -#### Returns - -`string` - ---- - -### moveFilesToNewDirectory - -▸ **moveFilesToNewDirectory**(`tree`, `oldDir`, `newDir`): `void` - -#### Parameters - -| Name | Type | -| :------- | :----------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | -| `oldDir` | `string` | -| `newDir` | `string` | - -#### Returns - -`void` - ---- - -### names - -▸ **names**(`name`): `Object` - -Util function to generate different strings based off the provided name. - -Examples: - -```typescript -names('my-name'); // {name: 'my-name', className: 'MyName', propertyName: 'myName', constantName: 'MY_NAME', fileName: 'my-name'} -names('myName'); // {name: 'my-name', className: 'MyName', propertyName: 'myName', constantName: 'MY_NAME', fileName: 'my-name'} -``` - -#### Parameters - -| Name | Type | -| :----- | :------- | -| `name` | `string` | - -#### Returns - -`Object` - -| Name | Type | -| :------------- | :------- | -| `className` | `string` | -| `constantName` | `string` | -| `fileName` | `string` | -| `name` | `string` | -| `propertyName` | `string` | - ---- - -### normalizePath - -▸ **normalizePath**(`osSpecificPath`): `string` - -Coverts an os specific path to a unix style path - -#### Parameters - -| Name | Type | -| :--------------- | :------- | -| `osSpecificPath` | `string` | - -#### Returns - -`string` - ---- - -### offsetFromRoot - -▸ **offsetFromRoot**(`fullPathToDir`): `string` - -Calculates an offset from the root of the workspace, which is useful for -constructing relative URLs. - -Examples: - -```typescript -offsetFromRoot('apps/mydir/myapp/'); // returns "../../../" -``` - -#### Parameters - -| Name | Type | Description | -| :-------------- | :------- | :------------- | -| `fullPathToDir` | `string` | directory path | - -#### Returns - -`string` - ---- - -### parseJson - -▸ **parseJson**<`T`\>(`input`, `options?`): `T` - -Parses the given JSON string and returns the object the JSON content represents. -By default javascript-style comments are allowed. - -#### Type parameters - -| Name | Type | -| :--- | :----------------------- | -| `T` | extends `object` = `any` | - -#### Parameters - -| Name | Type | Description | -| :--------- | :----------------------------------------------------------- | :--------------------- | -| `input` | `string` | JSON content as string | -| `options?` | [`JsonParseOptions`](../../nx-devkit/index#jsonparseoptions) | JSON parse options | - -#### Returns - -`T` - -Object the JSON content represents - ---- - -### parseTargetString - -▸ **parseTargetString**(`targetString`): [`Target`](../../nx-devkit/index#target) - -Parses a target string into {project, target, configuration} - -Examples: - -```typescript -parseTargetString('proj:test'); // returns { project: "proj", target: "test" } -parseTargetString('proj:test:production'); // returns { project: "proj", target: "test", configuration: "production" } -``` - -#### Parameters - -| Name | Type | Description | -| :------------- | :------- | :--------------- | -| `targetString` | `string` | target reference | - -#### Returns - -[`Target`](../../nx-devkit/index#target) - ---- - -### readJson - -▸ **readJson**<`T`\>(`tree`, `path`, `options?`): `T` - -Reads a json file, removes all comments and parses JSON. - -#### Type parameters - -| Name | Type | -| :--- | :----------------------- | -| `T` | extends `object` = `any` | - -#### Parameters - -| Name | Type | Description | -| :--------- | :----------------------------------------------------------- | :-------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | file system tree | -| `path` | `string` | file path | -| `options?` | [`JsonParseOptions`](../../nx-devkit/index#jsonparseoptions) | Optional JSON Parse Options | - -#### Returns - -`T` - ---- - -### readJsonFile - -▸ **readJsonFile**<`T`\>(`path`, `options?`): `T` - -Reads a JSON file and returns the object the JSON content represents. - -#### Type parameters - -| Name | Type | -| :--- | :----------------------- | -| `T` | extends `object` = `any` | - -#### Parameters - -| Name | Type | Description | -| :--------- | :---------------- | :----------------- | -| `path` | `string` | A path to a file. | -| `options?` | `JsonReadOptions` | JSON parse options | - -#### Returns - -`T` - -Object the JSON content of the file represents - ---- - -### readProjectConfiguration - -▸ **readProjectConfiguration**(`tree`, `projectName`): [`ProjectConfiguration`](../../nx-devkit/index#projectconfiguration) - -Reads a project configuration. - -The project configuration is stored in workspace.json or the associated project.json file. -The utility will read from either file. - -**`throws`** If supplied projectName cannot be found - -#### Parameters - -| Name | Type | Description | -| :------------ | :----------------------------------- | :---------------------------------------------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | the file system tree | -| `projectName` | `string` | unique name. Often directories are part of the name (e.g., mydir-mylib) | - -#### Returns - -[`ProjectConfiguration`](../../nx-devkit/index#projectconfiguration) - ---- - -### readTargetOptions - -▸ **readTargetOptions**<`T`\>(`__namedParameters`, `context`): `T` - -Reads and combines options for a given target. - -Works as if you invoked the target yourself without passing any command lint overrides. - -#### Type parameters - -| Name | Type | -| :--- | :---- | -| `T` | `any` | - -#### Parameters - -| Name | Type | -| :------------------ | :--------------------------------------------------------- | -| `__namedParameters` | [`Target`](../../nx-devkit/index#target) | -| `context` | [`ExecutorContext`](../../nx-devkit/index#executorcontext) | - -#### Returns - -`T` - ---- - -### readWorkspaceConfiguration - -▸ **readWorkspaceConfiguration**(`tree`): [`WorkspaceConfiguration`](../../nx-devkit/index#workspaceconfiguration) - -Read general workspace configuration such as the default project or cli settings - -This does _not_ provide projects configuration, use [readProjectConfiguration](../../nx-devkit/index#readprojectconfiguration) instead. - -#### Parameters - -| Name | Type | -| :----- | :----------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | - -#### Returns - -[`WorkspaceConfiguration`](../../nx-devkit/index#workspaceconfiguration) - ---- - -### removeDependenciesFromPackageJson - -▸ **removeDependenciesFromPackageJson**(`tree`, `dependencies`, `devDependencies`, `packageJsonPath?`): [`GeneratorCallback`](../../nx-devkit/index#generatorcallback) - -Remove Dependencies and Dev Dependencies from package.json - -For example: - -```typescript -removeDependenciesFromPackageJson(tree, ['react'], ['jest']); -``` - -This will **remove** `react` and `jest` from the dependencies and devDependencies sections of package.json respectively. - -#### Parameters - -| Name | Type | Default value | Description | -| :---------------- | :----------------------------------- | :--------------- | :-------------------------------------------------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | `undefined` | - | -| `dependencies` | `string`[] | `undefined` | Dependencies to be removed from the dependencies section of package.json | -| `devDependencies` | `string`[] | `undefined` | Dependencies to be removed from the devDependencies section of package.json | -| `packageJsonPath` | `string` | `'package.json'` | - | - -#### Returns - -[`GeneratorCallback`](../../nx-devkit/index#generatorcallback) - -Callback to uninstall dependencies only if necessary. undefined is returned if changes are not necessary. - ---- - -### removeProjectConfiguration - -▸ **removeProjectConfiguration**(`tree`, `projectName`): `void` - -Removes the configuration of an existing project. - -The project configuration is stored in workspace.json or the associated project.json file. -The utility will update either file. - -#### Parameters - -| Name | Type | -| :------------ | :----------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | -| `projectName` | `string` | - -#### Returns - -`void` - ---- - -### runExecutor - -▸ **runExecutor**<`T`\>(`targetDescription`, `options`, `context`): `Promise`<`AsyncIterableIterator`<`T`\>\> - -Loads and invokes executor. - -This is analogous to invoking executor from the terminal, with the exception -that the params aren't parsed from the string, but instead provided parsed already. - -Apart from that, it works the same way: - -- it will load the workspace configuration -- it will resolve the target -- it will load the executor and the schema -- it will load the options for the appropriate configuration -- it will run the validations and will set the default -- and, of course, it will invoke the executor - -Example: - -```typescript -for await (const s of await runExecutor( - { project: 'myproj', target: 'serve' }, - { watch: true }, - context -)) { - // s.success -} -``` - -Note that the return value is a promise of an iterator, so you need to await before iterating over it. - -#### Type parameters - -| Name | Type | -| :--- | :--------------- | -| `T` | extends `Object` | - -#### Parameters - -| Name | Type | -| :--------------------------------- | :--------------------------------------------------------- | -| `targetDescription` | `Object` | -| `targetDescription.configuration?` | `string` | -| `targetDescription.project` | `string` | -| `targetDescription.target` | `string` | -| `options` | `Object` | -| `context` | [`ExecutorContext`](../../nx-devkit/index#executorcontext) | - -#### Returns - -`Promise`<`AsyncIterableIterator`<`T`\>\> - ---- - -### serializeJson - -▸ **serializeJson**<`T`\>(`input`, `options?`): `string` - -Serializes the given data to a JSON string. -By default the JSON string is formatted with a 2 space intendation to be easy readable. - -#### Type parameters - -| Name | Type | -| :--- | :-------------------------- | -| `T` | extends `object` = `object` | - -#### Parameters - -| Name | Type | Description | -| :--------- | :------------------------------------------------------------------- | :---------------------------------------- | -| `input` | `T` | Object which should be serialized to JSON | -| `options?` | [`JsonSerializeOptions`](../../nx-devkit/index#jsonserializeoptions) | JSON serialize options | - -#### Returns - -`string` - -the formatted JSON representation of the object - ---- - -### stripIndents - -▸ **stripIndents**(`strings`, ...`values`): `string` - -Removes indents, which is useful for printing warning and messages. - -Example: - -```typescript -stripIndents` - Options: - - option1 - - option2 -`; -``` - -#### Parameters - -| Name | Type | -| :---------- | :--------------------- | -| `strings` | `TemplateStringsArray` | -| `...values` | `any`[] | - -#### Returns - -`string` - ---- - -### stripJsonComments - -▸ `Const` **stripJsonComments**(`text`, `replaceCh?`): `string` - -Takes JSON with JavaScript-style comments and remove -them. Optionally replaces every none-newline character -of comments with a replaceCharacter - -#### Parameters - -| Name | Type | -| :----------- | :------- | -| `text` | `string` | -| `replaceCh?` | `string` | - -#### Returns - -`string` - ---- - -### targetToTargetString - -▸ **targetToTargetString**(`target`): `string` - -Returns a string in the format "project:target[:configuration]" for the target - -#### Parameters - -| Name | Type | Description | -| :------- | :--------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `target` | [`Target`](../../nx-devkit/index#target) | target object Examples: `typescript targetToTargetString({ project: "proj", target: "test" }) // returns "proj:test" targetToTargetString({ project: "proj", target: "test", configuration: "production" }) // returns "proj:test:production" ` | - -#### Returns - -`string` - ---- - -### toJS - -▸ **toJS**(`tree`): `void` - -Rename and transpile any new typescript files created to javascript files - -#### Parameters - -| Name | Type | -| :----- | :----------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | - -#### Returns - -`void` - ---- - -### updateJson - -▸ **updateJson**<`T`, `U`\>(`tree`, `path`, `updater`, `options?`): `void` - -Updates a JSON value to the file system tree - -#### Type parameters - -| Name | Type | -| :--- | :----------------------- | -| `T` | extends `object` = `any` | -| `U` | extends `object` = `T` | - -#### Parameters - -| Name | Type | Description | -| :--------- | :---------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | File system tree | -| `path` | `string` | Path of JSON file in the Tree | -| `updater` | (`value`: `T`) => `U` | Function that maps the current value of a JSON document to a new value to be written to the document | -| `options?` | [`JsonParseOptions`](../../nx-devkit/index#jsonparseoptions) & [`JsonSerializeOptions`](../../nx-devkit/index#jsonserializeoptions) | Optional JSON Parse and Serialize Options | - -#### Returns - -`void` - ---- - -### updateProjectConfiguration - -▸ **updateProjectConfiguration**(`tree`, `projectName`, `projectConfiguration`): `void` - -Updates the configuration of an existing project. - -The project configuration is stored in workspace.json or the associated project.json file. -The utility will update either files. - -#### Parameters - -| Name | Type | Description | -| :--------------------- | :------------------------------------------------------------------- | :---------------------------------------------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | the file system tree | -| `projectName` | `string` | unique name. Often directories are part of the name (e.g., mydir-mylib) | -| `projectConfiguration` | [`ProjectConfiguration`](../../nx-devkit/index#projectconfiguration) | project configuration | - -#### Returns - -`void` - ---- - -### updateTsConfigsToJs - -▸ **updateTsConfigsToJs**(`tree`, `options`): `void` - -#### Parameters - -| Name | Type | -| :-------------------- | :----------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | -| `options` | `Object` | -| `options.projectRoot` | `string` | - -#### Returns - -`void` - ---- - -### updateWorkspaceConfiguration - -▸ **updateWorkspaceConfiguration**(`tree`, `workspaceConfig`): `void` - -Update general workspace configuration such as the default project or cli settings. - -This does _not_ update projects configuration, use [updateProjectConfiguration](../../nx-devkit/index#updateprojectconfiguration) or [addProjectConfiguration](../../nx-devkit/index#addprojectconfiguration) instead. - -#### Parameters - -| Name | Type | -| :---------------- | :----------------------------------------------------------------------- | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | -| `workspaceConfig` | [`WorkspaceConfiguration`](../../nx-devkit/index#workspaceconfiguration) | - -#### Returns - -`void` - ---- - -### visitNotIgnoredFiles - -▸ **visitNotIgnoredFiles**(`tree`, `dirPath?`, `visitor`): `void` - -Utility to act on all files in a tree that are not ignored by git. - -#### Parameters - -| Name | Type | Default value | -| :-------- | :----------------------------------- | :------------ | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | `undefined` | -| `dirPath` | `string` | `tree.root` | -| `visitor` | (`path`: `string`) => `void` | `undefined` | - -#### Returns - -`void` - ---- - -### writeJson - -▸ **writeJson**<`T`\>(`tree`, `path`, `value`, `options?`): `void` - -Writes a JSON value to the file system tree - -#### Type parameters - -| Name | Type | -| :--- | :-------------------------- | -| `T` | extends `object` = `object` | - -#### Parameters - -| Name | Type | Description | -| :--------- | :------------------------------------------------------------------- | :------------------------------ | -| `tree` | [`Tree`](../../nx-devkit/index#tree) | File system tree | -| `path` | `string` | Path of JSON file in the Tree | -| `value` | `T` | Serializable value to write | -| `options?` | [`JsonSerializeOptions`](../../nx-devkit/index#jsonserializeoptions) | Optional JSON Serialize Options | - -#### Returns - -`void` - ---- - -### writeJsonFile - -▸ **writeJsonFile**<`T`\>(`path`, `data`, `options?`): `void` - -Serializes the given data to JSON and writes it to a file. - -#### Type parameters - -| Name | Type | -| :--- | :-------------------------- | -| `T` | extends `object` = `object` | - -#### Parameters - -| Name | Type | Description | -| :--------- | :----------------- | :-------------------------------------------------------------- | -| `path` | `string` | A path to a file. | -| `data` | `T` | data which should be serialized to JSON and written to the file | -| `options?` | `JsonWriteOptions` | JSON serialize options | - -#### Returns - -`void` diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nx-devkit/ngcli_adapter.md b/nx-dev/nx-dev/public/documentation/generated/api-nx-devkit/ngcli_adapter.md deleted file mode 100644 index 4daeafdca4..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nx-devkit/ngcli_adapter.md +++ /dev/null @@ -1,118 +0,0 @@ -# Module: ngcli-adapter - -## Table of contents - -### Ng CLI Adapter Classes - -- [NxScopedHost](../../nx-devkit/ngcli_adapter#nxscopedhost) - -### Functions - -- [mockSchematicsForTesting](../../nx-devkit/ngcli_adapter#mockschematicsfortesting) -- [overrideCollectionResolutionForTesting](../../nx-devkit/ngcli_adapter#overridecollectionresolutionfortesting) -- [wrapAngularDevkitSchematic](../../nx-devkit/ngcli_adapter#wrapangulardevkitschematic) - -## Ng CLI Adapter Classes - -### NxScopedHost - -• **NxScopedHost**: `Object` - -## Functions - -### mockSchematicsForTesting - -▸ **mockSchematicsForTesting**(`schematics`): `void` - -If you have an Nx Devkit generator invoking the wrapped Angular Devkit schematic, -and you don't want the Angular Devkit schematic to run, you can mock it up using this function. - -Unfortunately, there are some edge cases in the Nx-Angular devkit integration that -can be seen in the unit tests context. This function is useful for handling that as well. - -In this case, you can mock it up. - -Example: - -```typescript -mockSchematicsForTesting({ - 'mycollection:myschematic': (tree, params) => { - tree.write('README.md'); - }, -}); -``` - -#### Parameters - -| Name | Type | -| :----------- | :------- | -| `schematics` | `Object` | - -#### Returns - -`void` - ---- - -### overrideCollectionResolutionForTesting - -▸ **overrideCollectionResolutionForTesting**(`collections`): `void` - -By default, Angular Devkit schematic collections will be resolved using the Node resolution. -This doesn't work if you are testing schematics that refer to other schematics in the -same repo. - -This function can can be used to override the resolution behaviour. - -Example: - -```typescript -overrideCollectionResolutionForTesting({ - '@nrwl/workspace': path.join( - __dirname, - '../../../../workspace/generators.json' - ), - '@nrwl/angular': path.join(__dirname, '../../../../angular/generators.json'), - '@nrwl/linter': path.join(__dirname, '../../../../linter/generators.json'), -}); -``` - -#### Parameters - -| Name | Type | -| :------------ | :------- | -| `collections` | `Object` | - -#### Returns - -`void` - ---- - -### wrapAngularDevkitSchematic - -▸ **wrapAngularDevkitSchematic**(`collectionName`, `generatorName`): (`host`: [`Tree`](../../nx-devkit/index#tree), `generatorOptions`: { [k: string]: `any`; }) => `Promise`<`any`\> - -#### Parameters - -| Name | Type | -| :--------------- | :------- | -| `collectionName` | `string` | -| `generatorName` | `string` | - -#### Returns - -`fn` - -▸ (`host`, `generatorOptions`): `Promise`<`any`\> - -##### Parameters - -| Name | Type | -| :----------------- | :----------------------------------- | -| `host` | [`Tree`](../../nx-devkit/index#tree) | -| `generatorOptions` | `Object` | - -##### Returns - -`Promise`<`any`\> diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/executors/e2e.md b/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/executors/e2e.md deleted file mode 100644 index ef73868681..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/executors/e2e.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: '@nrwl/nx-plugin:e2e executor' -description: 'Creates and runs the e2e tests for an Nx Plugin.' ---- - -# @nrwl/nx-plugin:e2e - -Creates and runs the e2e tests for an Nx Plugin. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### jestConfig (_**required**_) - -Type: `string` - -Jest config file. - -### target (_**required**_) - -Type: `string` - -The build target for the Nx Plugin project. - -### ~~tsSpecConfig~~ - -Type: `string` - -**Deprecated:** Use the `tsconfig` property for `ts-jest` in the e2e project `jest.config.js` file. It will be removed in the next major release. - -The tsconfig file for specs. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/executor.md b/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/executor.md deleted file mode 100644 index 9ba010200f..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/executor.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: '@nrwl/nx-plugin:executor generator' -description: 'Create a executor for an Nx Plugin' ---- - -# @nrwl/nx-plugin:executor - -Create a executor for an Nx Plugin - -## Usage - -```bash -nx generate executor ... -``` - -By default, Nx will search for `executor` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nx-plugin:executor ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g executor ... --dry-run -``` - -### Examples - -Generate libs/my-plugin/src/executors/my-executor: - -```bash -nx g executor my-executor --project=my-plugin -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Executor name - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The name of the project. - -### description - -Alias(es): d - -Type: `string` - -Executor description - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/generator.md b/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/generator.md deleted file mode 100644 index 9e93ca51e0..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/generator.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: '@nrwl/nx-plugin:generator generator' -description: 'Create a generator for an Nx Plugin' ---- - -# @nrwl/nx-plugin:generator - -Create a generator for an Nx Plugin - -## Usage - -```bash -nx generate generator ... -``` - -By default, Nx will search for `generator` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nx-plugin:generator ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g generator ... --dry-run -``` - -### Examples - -Generate libs/my-plugin/src/generators/my-generator: - -```bash -nx g generator my-generator --project=my-plugin -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Generator name - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The name of the project. - -### description - -Alias(es): d - -Type: `string` - -Generator description - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/migration.md b/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/migration.md deleted file mode 100644 index 0a89776490..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/migration.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: '@nrwl/nx-plugin:migration generator' -description: 'Create a migration for an Nx Plugin' ---- - -# @nrwl/nx-plugin:migration - -Create a migration for an Nx Plugin - -## Usage - -```bash -nx generate migration ... -``` - -By default, Nx will search for `migration` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nx-plugin:migration ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g migration ... --dry-run -``` - -### Examples - -Generate libs/my-plugin/src/migrations/my-migration: - -```bash -nx g migration my-migration --project=my-plugin --version=1.0.0 -``` - -## Options - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The name of the project. - -### version (_**required**_) - -Alias(es): v - -Type: `string` - -Version to use for the migration - -### description - -Alias(es): d - -Type: `string` - -Migration description - -### name - -Type: `string` - -Migration name - -### packageJsonUpdates - -Alias(es): p - -Default: `false` - -Type: `boolean` - -Whether or not to include package.json updates diff --git a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/plugin.md b/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/plugin.md deleted file mode 100644 index 7e55a8d674..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-nx-plugin/generators/plugin.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: '@nrwl/nx-plugin:plugin generator' -description: 'Create a Nx Plugin' ---- - -# @nrwl/nx-plugin:plugin - -Create a Nx Plugin - -## Usage - -```bash -nx generate plugin ... -``` - -By default, Nx will search for `plugin` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/nx-plugin:plugin ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g plugin ... --dry-run -``` - -### Examples - -Generate libs/plugins/my-plugin: - -```bash -nx g plugin my-plugin --directory=plugins --importPath=@myorg/my-plugin -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Plugin name - -### directory - -Alias(es): d - -Type: `string` - -A directory where the plugin is placed - -### importPath - -Type: `string` - -How the plugin will be published, like @myorg/my-awesome-plugin. Note this must be a valid npm name - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### skipTsConfig - -Default: `false` - -Type: `boolean` - -Do not update tsconfig.json for development experience. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### tags - -Alias(es): t - -Type: `string` - -Add tags to the library (used for linting) - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/build-android.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/build-android.md deleted file mode 100644 index 311fc01671..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/build-android.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: '@nrwl/react-native:build-android executor' -description: 'Release Build for Android.' ---- - -# @nrwl/react-native:build-android - -Release Build for Android. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### apk - -Type: `boolean` - -Generate apk file(s) rather than a bundle (.aab). diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/bundle.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/bundle.md deleted file mode 100644 index 0d34ebe0f0..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/bundle.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: '@nrwl/react-native:bundle executor' -description: 'Builds the JavaScript bundle for offline use.' ---- - -# @nrwl/react-native:bundle - -Builds the JavaScript bundle for offline use. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### bundleOutput (_**required**_) - -Type: `string` - -The output path of the generated files. - -### entryFile (_**required**_) - -Type: `string` - -The entry file relative to project root. - -### platform (_**required**_) - -Type: `string` - -Platform to build for (ios, android). - -### dev - -Default: `true` - -Type: `boolean` - -Generate a development build. - -### maxWorkers - -Type: `number` - -The number of workers we should parallelize the transformer on. - -### sourceMap - -Type: `boolean` - -Whether source maps should be generated or not. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/ensure-symlink.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/ensure-symlink.md deleted file mode 100644 index db2e65b434..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/ensure-symlink.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: '@nrwl/react-native:ensure-symlink executor' -description: "Ensure workspace node_modules is symlink under app's node_modules folder." ---- - -# @nrwl/react-native:ensure-symlink - -Ensure workspace node_modules is symlink under app's node_modules folder. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/run-android.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/run-android.md deleted file mode 100644 index 4ca387ab83..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/run-android.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: '@nrwl/react-native:run-android executor' -description: 'Runs Android application.' ---- - -# @nrwl/react-native:run-android - -Runs Android application. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### appId - -Type: `string` - -Specify an applicationId to launch after build. If not specified, 'package' from AndroidManifest.xml will be used. - -### appIdSuffix - -Type: `string` - -Specify an applicationIdSuffix to launch after build. - -### deviceId - -Type: `string` - -Builds your app and starts it on a specific device/simulator with the given device id (listed by running "adb devices" on the command line). - -### jetifier - -Default: `true` - -Type: `boolean` - -Run jetifier – the AndroidX transition tool. By default it runs before Gradle to ease working with libraries that don't support AndroidX yet. - -### mainActivity - -Default: `MainActivity` - -Type: `string` - -Name of the activity to start. - -### packager - -Default: `true` - -Type: `boolean` - -Starts the packager server - -### port - -Default: `8081` - -Type: `number` - -The port where the packager server is listening on. - -### resetCache - -Default: `false` - -Type: `boolean` - -Resets metro cache - -### sync - -Default: `true` - -Type: `boolean` - -Syncs npm dependencies to package.json (for React Native autolink). - -### tasks - -Type: `string` - -Run custom gradle tasks. If this argument is provided, then --variant option is ignored. Example: yarn react-native run-android --tasks clean,installDebug. - -### terminal - -Type: `string` - -Launches the Metro Bundler in a new window using the specified terminal path. - -### variant - -Default: `debug` - -Type: `string` - -Specify your app's build variant (e.g. debug, release). diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/run-ios.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/run-ios.md deleted file mode 100644 index b96753151d..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/run-ios.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: '@nrwl/react-native:run-ios executor' -description: 'Runs iOS application.' ---- - -# @nrwl/react-native:run-ios - -Runs iOS application. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### device - -Type: `string` - -Explicitly set device to use by name. The value is not required if you have a single device connected. - -### install - -Default: `true` - -Type: `boolean` - -Runs 'pod install' for native modules before building iOS app. - -### packager - -Default: `true` - -Type: `boolean` - -Starts the packager server - -### port - -Default: `8081` - -Type: `number` - -The port where the packager server is listening on. - -### resetCache - -Default: `false` - -Type: `boolean` - -Resets metro cache - -### scheme - -Type: `string` - -Explicitly set the Xcode scheme to use - -### simulator - -Default: `iPhone X` - -Type: `string` - -Explicitly set simulator to use. Optionally include iOS version between parenthesis at the end to match an exact version: "iPhone X (12.1)" - -### sync - -Default: `true` - -Type: `boolean` - -Syncs npm dependencies to package.json (for React Native autolink). Always true when --install is used. - -### terminal - -Type: `string` - -Launches the Metro Bundler in a new window using the specified terminal path. - -### xcodeConfiguration - -Default: `Debug` - -Type: `string` - -Explicitly set the Xcode configuration to use diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/start.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/start.md deleted file mode 100644 index 9ebfdcbd6a..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/start.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: '@nrwl/react-native:start executor' -description: 'Starts the Javascript server that communicates with connected devices.' ---- - -# @nrwl/react-native:start - -Starts the Javascript server that communicates with connected devices. - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### port - -Default: `8081` - -Type: `number` - -The port to listen on. - -### resetCache - -Default: `false` - -Type: `boolean` - -Resets metro cache. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/sync-deps.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/sync-deps.md deleted file mode 100644 index 2d3c2649da..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/executors/sync-deps.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: '@nrwl/react-native:sync-deps executor' -description: 'Syncs dependencies to package.json (required for autolinking).' ---- - -# @nrwl/react-native:sync-deps - -Syncs dependencies to package.json (required for autolinking). - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### include - -Type: `string` - -A comma-separated list of additional npm packages to include. e.g. 'nx sync-deps --include=react-native-gesture-handler,react-native-safe-area-context' diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/generators/application.md deleted file mode 100644 index c240edeab8..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/generators/application.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -title: '@nrwl/react-native:application generator' -description: 'Create a React Native application' ---- - -# @nrwl/react-native:application - -Create a React Native application - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react-native:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -### Examples - -Generate apps/nested/myapp: - -```bash -nx g app myapp --directory=nested -``` - -Use class components instead of functional components: - -```bash -nx g app myapp --classComponent -``` - -## Options - -### directory - -Alias(es): d - -Type: `string` - -The directory of the new application. - -### displayName - -Type: `string` - -The display name to show in the application. Defaults to name. - -### e2eTestRunner - -Default: `detox` - -Type: `string` - -Possible values: `detox`, `none` - -Adds the specified e2e test runner - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### name - -Type: `string` - -The name of the application. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### tags - -Alias(es): t - -Type: `string` - -Add tags to the application (used for linting) - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/generators/component.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/generators/component.md deleted file mode 100644 index dcece36b30..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/generators/component.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: '@nrwl/react-native:component generator' -description: 'Create a React Native component' ---- - -# @nrwl/react-native:component - -Create a React Native component - -## Usage - -```bash -nx generate component ... -``` - -```bash -nx g c ... # same -``` - -By default, Nx will search for `component` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react-native:component ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g component ... --dry-run -``` - -### Examples - -Generate a component in the mylib library: - -```bash -nx g component my-component --project=mylib -``` - -Generate a class component in the mylib library: - -```bash -nx g component my-component --project=mylib --classComponent -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the component. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The name of the project. - -### classComponent - -Alias(es): C - -Default: `false` - -Type: `boolean` - -Use class components instead of functional component. - -### directory - -Alias(es): d - -Type: `string` - -Create the component under this directory (can be nested). - -### export - -Alias(es): e - -Default: `false` - -Type: `boolean` - -When true, the component is exported from the project index.ts (if it exists). - -### flat - -Default: `false` - -Type: `boolean` - -Create component at the source root rather than its own directory. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case component file name (e.g. App.tsx). - -### skipTests - -Default: `false` - -Type: `boolean` - -When true, does not create "spec.ts" test files for the new component. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react-native/generators/library.md b/nx-dev/nx-dev/public/documentation/generated/api-react-native/generators/library.md deleted file mode 100644 index bed3e5b66f..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react-native/generators/library.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: '@nrwl/react-native:library generator' -description: 'Create a React Native library' ---- - -# @nrwl/react-native:library - -Create a React Native library - -## Usage - -```bash -nx generate library ... -``` - -```bash -nx g lib ... # same -``` - -By default, Nx will search for `library` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react-native:library ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g library ... --dry-run -``` - -### Examples - -Generate libs/myapp/mylib: - -```bash -nx g lib mylib --directory=myapp -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Library name - -### buildable - -Default: `false` - -Type: `boolean` - -Generate a buildable library. - -### directory - -Alias(es): d - -Type: `string` - -A directory where the lib is placed. - -### globalCss - -Default: `false` - -Type: `boolean` - -When true, the stylesheet is generated using global CSS instead of CSS modules (e.g. file is '_.css' rather than '_.module.css'). - -### importPath - -Type: `string` - -The library name used to import it, like @myorg/my-awesome-lib - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case component file name (e.g. App.tsx). - -### publishable - -Type: `boolean` - -Create a publishable library. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipTsConfig - -Default: `false` - -Type: `boolean` - -Do not update tsconfig.json for development experience. - -### strict - -Default: `true` - -Type: `boolean` - -Whether to enable tsconfig strict mode or not. - -### tags - -Alias(es): t - -Type: `string` - -Add tags to the library (used for linting). - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/application.md deleted file mode 100644 index f0e527cf8f..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/application.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -title: '@nrwl/react:application generator' -description: 'Create a React application' ---- - -# @nrwl/react:application - -Create a React application - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -### Examples - -Generate apps/myorg/myapp and apps/myorg/myapp-e2e: - -```bash -nx g app myapp --directory=myorg -``` - -Use class components instead of functional components: - -```bash -nx g app myapp --classComponent -``` - -Set up React Router: - -```bash -nx g app myapp --routing -``` - -## Options - -### classComponent - -Alias(es): C - -Default: `false` - -Type: `boolean` - -Use class components instead of functional component. - -### compiler - -Default: `babel` - -Type: `string` - -Possible values: `babel`, `swc` - -The compiler to use - -### directory - -Alias(es): dir - -Type: `string` - -The directory of the new application. - -### e2eTestRunner - -Default: `cypress` - -Type: `string` - -Possible values: `cypress`, `none` - -Test runner to use for end to end (e2e) tests. - -### globalCss - -Default: `false` - -Type: `boolean` - -Default is false. When true, the component is generated with _.css/_.scss instead of _.module.css/_.module.scss - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### name - -Type: `string` - -The name of the application. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case component file name (e.g. App.tsx). - -### routing - -Default: `false` - -Type: `boolean` - -Generate application with routes. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipWorkspaceJson - -Default: `false` - -Type: `boolean` - -Skip updating workspace.json with default options based on values provided to this app (e.g. babel, style). - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### strict - -Default: `true` - -Type: `boolean` - -Creates an application with strict mode and strict type checking - -### style - -Alias(es): s - -Default: `css` - -Type: `string` - -Possible values: `css`, `scss`, `styl`, `less`, `styled-components`, `@emotion/styled`, `styled-jsx`, `none` - -The file extension to be used for style files. - -### tags - -Alias(es): t - -Type: `string` - -Add tags to the application (used for linting). - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/component-cypress-spec.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/component-cypress-spec.md deleted file mode 100644 index f69d0785a5..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/component-cypress-spec.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: '@nrwl/react:component-cypress-spec generator' -description: 'Create a cypress spec for a ui component that has a story' ---- - -# @nrwl/react:component-cypress-spec - -Create a cypress spec for a ui component that has a story - -## Usage - -```bash -nx generate component-cypress-spec ... -``` - -By default, Nx will search for `component-cypress-spec` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:component-cypress-spec ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g component-cypress-spec ... --dry-run -``` - -## Options - -### componentPath (_**required**_) - -Type: `string` - -Relative path to the component file from the library root? - -### project (_**required**_) - -Type: `string` - -The project name for which to generate tests. - -### cypressProject - -Type: `string` - -The Cypress project to generate the stories under. By default, inferred from 'project' - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/component-story.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/component-story.md deleted file mode 100644 index 5812759ece..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/component-story.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: '@nrwl/react:component-story generator' -description: 'Generate storybook story for a react component' ---- - -# @nrwl/react:component-story - -Generate storybook story for a react component - -## Usage - -```bash -nx generate component-story ... -``` - -By default, Nx will search for `component-story` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:component-story ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g component-story ... --dry-run -``` - -## Options - -### componentPath (_**required**_) - -Type: `string` - -Relative path to the component file from the library root - -### project (_**required**_) - -Type: `string` - -The project name where to add the components. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/component.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/component.md deleted file mode 100644 index d6a5e5dfe7..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/component.md +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: '@nrwl/react:component generator' -description: 'Create a React component' ---- - -# @nrwl/react:component - -Create a React component - -## Usage - -```bash -nx generate component ... -``` - -```bash -nx g c ... # same -``` - -By default, Nx will search for `component` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:component ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g component ... --dry-run -``` - -### Examples - -Generate a component in the mylib library: - -```bash -nx g component my-component --project=mylib -``` - -Generate a class component in the mylib library: - -```bash -nx g component my-component --project=mylib --classComponent -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the component. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The name of the project. - -### classComponent - -Alias(es): C - -Default: `false` - -Type: `boolean` - -Use class components instead of functional component. - -### directory - -Alias(es): dir - -Type: `string` - -Create the component under this directory (can be nested). - -### export - -Alias(es): e - -Default: `false` - -Type: `boolean` - -When true, the component is exported from the project index.ts (if it exists). - -### fileName - -Type: `string` - -Create a component with this file name. - -### flat - -Default: `false` - -Type: `boolean` - -Create component at the source root rather than its own directory. - -### globalCss - -Default: `false` - -Type: `boolean` - -Default is false. When true, the component is generated with _.css/_.scss instead of _.module.css/_.module.scss - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### pascalCaseDirectory - -Alias(es): R - -Default: `false` - -Type: `boolean` - -Use pascal case directory name (e.g. App/App.tsx). - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case component file name (e.g. App.tsx). - -### routing - -Type: `boolean` - -Generate a library with routes. - -### skipTests - -Default: `false` - -Type: `boolean` - -When true, does not create "spec.ts" test files for the new component. - -### style - -Alias(es): s - -Default: `css` - -Type: `string` - -Possible values: `css`, `scss`, `styl`, `less`, `styled-components`, `@emotion/styled`, `styled-jsx`, `none` - -The file extension to be used for style files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/hook.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/hook.md deleted file mode 100644 index 93c6f2c85c..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/hook.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: '@nrwl/react:hook generator' -description: 'Create a hook' ---- - -# @nrwl/react:hook - -Create a hook - -## Usage - -```bash -nx generate hook ... -``` - -```bash -nx g h ... # same -``` - -By default, Nx will search for `hook` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:hook ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g hook ... --dry-run -``` - -### Examples - -Generate a hook in the mylib library: - -```bash -nx g hook my-hook --project=mylib -``` - -## Options - -### name (_**required**_) - -Type: `string` - -The name of the hook. - -### project (_**required**_) - -Alias(es): p - -Type: `string` - -The name of the project. - -### directory - -Alias(es): d - -Type: `string` - -Create the hook under this directory (can be nested). - -### export - -Alias(es): e - -Default: `false` - -Type: `boolean` - -When true, the hook is exported from the project index.ts (if it exists). - -### flat - -Default: `false` - -Type: `boolean` - -Create hook at the source root rather than its own directory. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### pascalCaseDirectory - -Alias(es): R - -Default: `false` - -Type: `boolean` - -Use pascal case directory name (e.g. useHook/useHook.ts). - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case hook file name (e.g. useHook.ts). - -### skipTests - -Default: `false` - -Type: `boolean` - -When true, does not create "spec.ts" test files for the new hook. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/library.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/library.md deleted file mode 100644 index b79ccd1a33..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/library.md +++ /dev/null @@ -1,218 +0,0 @@ ---- -title: '@nrwl/react:library generator' -description: 'Create a React library' ---- - -# @nrwl/react:library - -Create a React library - -## Usage - -```bash -nx generate library ... -``` - -```bash -nx g lib ... # same -``` - -By default, Nx will search for `library` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:library ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g library ... --dry-run -``` - -### Examples - -Generate libs/myapp/mylib: - -```bash -nx g lib mylib --directory=myapp -``` - -Generate a library with routes and add them to myapp: - -```bash -nx g lib mylib --appProject=myapp -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Library name - -### appProject - -Alias(es): a - -Type: `string` - -The application project to add the library route to. - -### buildable - -Default: `false` - -Type: `boolean` - -Generate a buildable library. - -### compiler - -Default: `babel` - -Type: `string` - -Possible values: `babel`, `swc` - -Which compiler to use. - -### component - -Default: `true` - -Type: `boolean` - -Generate a default component. - -### directory - -Alias(es): dir - -Type: `string` - -A directory where the lib is placed. - -### globalCss - -Default: `false` - -Type: `boolean` - -When true, the stylesheet is generated using global CSS instead of CSS modules (e.g. file is '_.css' rather than '_.module.css'). - -### importPath - -Type: `string` - -The library name used to import it, like @myorg/my-awesome-lib - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case component file name (e.g. App.tsx). - -### publishable - -Type: `boolean` - -Create a publishable library. - -### routing - -Type: `boolean` - -Generate library with routes. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### skipTsConfig - -Default: `false` - -Type: `boolean` - -Do not update tsconfig.json for development experience. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### strict - -Default: `true` - -Type: `boolean` - -Whether to enable tsconfig strict mode or not. - -### style - -Alias(es): s - -Default: `css` - -Type: `string` - -Possible values: `css`, `scss`, `styl`, `less`, `styled-components`, `@emotion/styled`, `styled-jsx`, `none` - -The file extension to be used for style files. - -### tags - -Alias(es): t - -Type: `string` - -Add tags to the library (used for linting). - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/redux.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/redux.md deleted file mode 100644 index 95929652f2..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/redux.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: '@nrwl/react:redux generator' -description: 'Create a redux slice for a project' ---- - -# @nrwl/react:redux - -Create a redux slice for a project - -## Usage - -```bash -nx generate redux ... -``` - -```bash -nx g slice ... # same -``` - -By default, Nx will search for `redux` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:redux ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g redux ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Redux slice name. - -### appProject - -Alias(es): a - -Type: `string` - -The application project to add the slice to. - -### directory - -Alias(es): dir - -Type: `string` - -The name of the folder used to contain/group the generated Redux files. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### project - -Alias(es): p - -Type: `string` - -The name of the project to add the slice to. If it is an application, then the store configuration will be updated too. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/stories.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/stories.md deleted file mode 100644 index 65ff592c37..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/stories.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: '@nrwl/react:stories generator' -description: 'Create stories/specs for all components declared in a library' ---- - -# @nrwl/react:stories - -Create stories/specs for all components declared in a library - -## Usage - -```bash -nx generate stories ... -``` - -By default, Nx will search for `stories` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:stories ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g stories ... --dry-run -``` - -## Options - -### project (_**required**_) - -Type: `string` - -Library or application name - -### cypressProject - -Type: `string` - -The Cypress project to generate the stories under. This is inferred from 'project' by default - -### generateCypressSpecs - -Type: `boolean` - -Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/storybook-configuration.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/storybook-configuration.md deleted file mode 100644 index dfe1a2e6df..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/storybook-configuration.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: '@nrwl/react:storybook-configuration generator' -description: 'Set up storybook for a react library' ---- - -# @nrwl/react:storybook-configuration - -Set up storybook for a react library - -## Usage - -```bash -nx generate storybook-configuration ... -``` - -By default, Nx will search for `storybook-configuration` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:storybook-configuration ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g storybook-configuration ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Project name - -### configureCypress - -Default: `true` - -Type: `boolean` - -Run the cypress-configure generator. - -### cypressDirectory - -Type: `string` - -A directory where the Cypress project will be placed. Placed at the root by default. - -### generateCypressSpecs - -Default: `true` - -Type: `boolean` - -Automatically generate \*.spec.ts files in the cypress e2e app generated by the cypress-configure generator - -### generateStories - -Default: `true` - -Type: `boolean` - -Automatically generate \*.stories.ts files for components declared in this project? - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files. - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json diff --git a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/storybook-migrate-defaults-5-to-6.md b/nx-dev/nx-dev/public/documentation/generated/api-react/generators/storybook-migrate-defaults-5-to-6.md deleted file mode 100644 index c340edc3f0..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-react/generators/storybook-migrate-defaults-5-to-6.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: '@nrwl/react:storybook-migrate-defaults-5-to-6 generator' -description: 'Generate default Storybook configuration files using Storybook version >=6.x specs, for projects that already have Storybook instances and configurations of versions <6.x.' ---- - -# @nrwl/react:storybook-migrate-defaults-5-to-6 - -Generate default Storybook configuration files using Storybook version >=6.x specs, for projects that already have Storybook instances and configurations of versions <6.x. - -## Usage - -```bash -nx generate storybook-migrate-defaults-5-to-6 ... -``` - -By default, Nx will search for `storybook-migrate-defaults-5-to-6` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/react:storybook-migrate-defaults-5-to-6 ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g storybook-migrate-defaults-5-to-6 ... --dry-run -``` - -## Options - -### all - -Default: `true` - -Type: `boolean` - -Generate new Storybook configurations for all Storybook instances across all apps and libs. - -### keepOld - -Default: `true` - -Type: `boolean` - -Keep the old configuration files - put them in a folder called .old_storybook. - -### name - -Type: `string` - -Leave empty to upgrade all Storybook instances. Only use this if you want to do a gradual migration. Library or application name for which you want to generate the new Storybook configuration. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-storybook/executors/build.md b/nx-dev/nx-dev/public/documentation/generated/api-storybook/executors/build.md deleted file mode 100644 index 138ffdcfe9..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-storybook/executors/build.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: '@nrwl/storybook:build executor' -description: 'Build Storybook' ---- - -# @nrwl/storybook:build - -Build Storybook - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### uiFramework (_**required**_) (**hidden**) - -Default: `@storybook/angular` - -Type: `string` - -Storybook framework npm package - -### docsMode - -Default: `false` - -Type: `boolean` - -Build a documentation-only site using addon-docs. - -### outputPath - -Type: `string` - -The output path of the generated files. - -### projectBuildConfig - -Type: `string` - -Workspace project where Storybook reads the Webpack config from - -### quiet - -Default: `true` - -Type: `boolean` - -Suppress verbose build output. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-storybook/executors/storybook.md b/nx-dev/nx-dev/public/documentation/generated/api-storybook/executors/storybook.md deleted file mode 100644 index 3b42edcca3..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-storybook/executors/storybook.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: '@nrwl/storybook:storybook executor' -description: 'Serve Storybook' ---- - -# @nrwl/storybook:storybook - -Serve Storybook - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### uiFramework (_**required**_) (**hidden**) - -Default: `@storybook/angular` - -Type: `string` - -Possible values: `@storybook/angular`, `@storybook/react`, `@storybook/html`, `@storybook/web-components`, `@storybook/vue`, `@storybook/vue3`, `@storybook/svelte` - -Storybook framework npm package - -### docsMode - -Default: `false` - -Type: `boolean` - -Build a documentation-only site using addon-docs. - -### host - -Default: `localhost` - -Type: `string` - -Host to listen on. - -### https - -Default: `false` - -Type: `boolean` - -Serve using HTTPS. - -### port - -Default: `9009` - -Type: `number` - -Port to listen on. - -### projectBuildConfig - -Type: `string` - -Workspace project where Storybook reads the Webpack config from - -### quiet - -Default: `true` - -Type: `boolean` - -Suppress verbose build output. - -### sslCert - -Type: `string` - -SSL certificate to use for serving HTTPS. - -### sslKey - -Type: `string` - -SSL key to use for serving HTTPS. - -### staticDir - -Type: `array` - -Directory where to load static files from, array of strings - -### watch - -Default: `true` - -Type: `boolean` - -Watches for changes and rebuilds application diff --git a/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/configuration.md b/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/configuration.md deleted file mode 100644 index 0fde868742..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/configuration.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: '@nrwl/storybook:configuration generator' -description: 'Add storybook configuration to a ui library or an application' ---- - -# @nrwl/storybook:configuration - -Add storybook configuration to a ui library or an application - -## Usage - -```bash -nx generate configuration ... -``` - -By default, Nx will search for `configuration` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/storybook:configuration ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g configuration ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Library or application name - -### configureCypress - -Type: `boolean` - -Run the cypress-configure generator - -### cypressDirectory - -Type: `string` - -A directory where the Cypress project will be placed. Added at root by default. - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint`, `none` - -The tool to use for running lint checks. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### uiFramework - -Type: `string` - -Possible values: `@storybook/angular`, `@storybook/react` - -Storybook UI Framework to use diff --git a/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/cypress-project.md b/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/cypress-project.md deleted file mode 100644 index 6d7e27b712..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/cypress-project.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: '@nrwl/storybook:cypress-project generator' -description: 'Add cypress e2e app to test a ui library that is set up for storybook' ---- - -# @nrwl/storybook:cypress-project - -Add cypress e2e app to test a ui library that is set up for storybook - -## Usage - -```bash -nx generate cypress-project ... -``` - -By default, Nx will search for `cypress-project` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/storybook:cypress-project ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g cypress-project ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Library or application name - -### directory - -Type: `string` - -A directory where the project is placed - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint`, `none` - -The tool to use for running lint checks. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json diff --git a/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/migrate-defaults-5-to-6.md b/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/migrate-defaults-5-to-6.md deleted file mode 100644 index 2d89444bb8..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/migrate-defaults-5-to-6.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: '@nrwl/storybook:migrate-defaults-5-to-6 generator' -description: 'Generate default Storybook configuration files using Storybook version >=6.x specs, for projects that already have Storybook instances and configurations of versions <6.x.' ---- - -# @nrwl/storybook:migrate-defaults-5-to-6 - -Generate default Storybook configuration files using Storybook version >=6.x specs, for projects that already have Storybook instances and configurations of versions <6.x. - -## Usage - -```bash -nx generate migrate-defaults-5-to-6 ... -``` - -By default, Nx will search for `migrate-defaults-5-to-6` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/storybook:migrate-defaults-5-to-6 ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g migrate-defaults-5-to-6 ... --dry-run -``` - -## Options - -### all - -Default: `true` - -Type: `boolean` - -Generate new Storybook configurations for all Storybook instances across all apps and libs. - -### keepOld - -Default: `true` - -Type: `boolean` - -Keep the old configuration files - put them in a folder called .old_storybook. - -### name - -Type: `string` - -Leave empty to upgrade all Storybook instances. Only use this if you want to do a gradual migration. Library or application name for which you want to generate the new Storybook configuration. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/migrate-stories-to-6-2.md b/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/migrate-stories-to-6-2.md deleted file mode 100644 index a980e2e390..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-storybook/generators/migrate-stories-to-6-2.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: '@nrwl/storybook:migrate-stories-to-6-2 generator' -description: 'Migrate stories syntax to 6.2' ---- - -# @nrwl/storybook:migrate-stories-to-6-2 - -Migrate stories syntax to 6.2 - -## Usage - -```bash -nx generate migrate-stories-to-6-2 ... -``` - -By default, Nx will search for `migrate-stories-to-6-2` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/storybook:migrate-stories-to-6-2 ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g migrate-stories-to-6-2 ... --dry-run -``` diff --git a/nx-dev/nx-dev/public/documentation/generated/api-web/executors/dev-server.md b/nx-dev/nx-dev/public/documentation/generated/api-web/executors/dev-server.md deleted file mode 100644 index 03b2d41927..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-web/executors/dev-server.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: '@nrwl/web:dev-server executor' -description: 'Serve a web application' ---- - -# @nrwl/web:dev-server - -Serve a web application - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### allowedHosts - -Type: `string` - -This option allows you to whitelist services that are allowed to access the dev server. - -### baseHref - -Type: `string` - -Base url for the application being built. - -### buildTarget - -Type: `string` - -Target which builds the application - -### hmr - -Default: `false` - -Type: `boolean` - -Enable hot module replacement. - -### host - -Default: `localhost` - -Type: `string` - -Host to listen on. - -### liveReload - -Default: `true` - -Type: `boolean` - -Whether to reload the page on change, using live-reload. - -### maxWorkers - -Type: `number` - -Number of workers to use for type checking. - -### memoryLimit - -Type: `number` - -Memory limit for type checking service process in MB. - -### open - -Default: `false` - -Type: `boolean` - -Open the application in the browser. - -### port - -Default: `4200` - -Type: `number` - -Port to listen on. - -### publicHost - -Type: `string` - -Public URL where the application will be served - -### ssl - -Default: `false` - -Type: `boolean` - -Serve using HTTPS. - -### sslCert - -Type: `string` - -SSL certificate to use for serving HTTPS. - -### sslKey - -Type: `string` - -SSL key to use for serving HTTPS. - -### watch - -Default: `true` - -Type: `boolean` - -Watches for changes and rebuilds application diff --git a/nx-dev/nx-dev/public/documentation/generated/api-web/executors/file-server.md b/nx-dev/nx-dev/public/documentation/generated/api-web/executors/file-server.md deleted file mode 100644 index 52568a1071..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-web/executors/file-server.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: '@nrwl/web:file-server executor' -description: 'Serve a web application from a folder' ---- - -# @nrwl/web:file-server - -Serve a web application from a folder - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### buildTarget (_**required**_) - -Type: `string` - -Target which builds the application - -### host - -Default: `localhost` - -Type: `string` - -Host to listen on. - -### maxParallel - -Type: `number` - -Max number of parallel jobs - -### parallel - -Default: `true` - -Type: `boolean` - -Build the target in parallel - -### port - -Default: `4200` - -Type: `number` - -Port to listen on. - -### proxyUrl - -Type: `string` - -URL to proxy unhandled requests to. - -### ssl - -Default: `false` - -Type: `boolean` - -Serve using HTTPS. - -### sslCert - -Type: `string` - -SSL certificate to use for serving HTTPS. - -### sslKey - -Type: `string` - -SSL key to use for serving HTTPS. - -### withDeps - -Default: `true` - -Type: `boolean` - -Build the target and all its deps diff --git a/nx-dev/nx-dev/public/documentation/generated/api-web/executors/rollup.md b/nx-dev/nx-dev/public/documentation/generated/api-web/executors/rollup.md deleted file mode 100644 index 538477c1a8..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-web/executors/rollup.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -title: '@nrwl/web:rollup executor' -description: 'Package a library using rollup' ---- - -# @nrwl/web:rollup - -Package a library using rollup - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### entryFile (_**required**_) - -Type: `string` - -The path to the entry file, relative to project. - -### outputPath (_**required**_) - -Type: `string` - -The output path of the generated files. - -### project (_**required**_) - -Type: `string` - -The path to package.json file. - -### tsConfig (_**required**_) - -Type: `string` - -The path to tsconfig file. - -### assets - -Type: `array` - -List of static assets. - -### buildableProjectDepsInPackageJsonType - -Default: `peerDependencies` - -Type: `string` - -Possible values: `dependencies`, `peerDependencies` - -When updateBuildableProjectDepsInPackageJson is true, this adds dependencies to either `peerDependencies` or `dependencies` - -### compiler - -Default: `babel` - -Type: `string` - -Possible values: `babel`, `swc` - -Which compiler to use. - -### deleteOutputPath - -Default: `true` - -Type: `boolean` - -Delete the output path before building. - -### external - -Type: `array` - -A list of external modules that will not be bundled (react, react-dom, etc.). - -### extractCss - -Default: `true` - -Type: `boolean` - -CSS files will be extracted to the output folder. - -### format - -Alias(es): f - -Type: `array` - -Only build the specified comma-separated formats (esm,umd,cjs) - -### globals - -Type: `object[]` - -A mapping of node modules to their UMD global names. Used by the UMD bundle - -#### moduleId - -Type: `string` - -The node module to map from (e.g. `react-dom`). - -#### global - -Type: `string` - -The global name to map to (e.g. `ReactDOM`). - -### rollupConfig - -Type: `array[] | string ` - -Path to a function which takes a rollup config and returns an updated rollup config - -### umdName - -Type: `string` - -The name of your module in UMD format. Defaulted to your project name. - -### updateBuildableProjectDepsInPackageJson - -Default: `true` - -Type: `boolean` - -Update buildable project dependencies in package.json - -### watch - -Default: `false` - -Type: `boolean` - -Enable re-building when files change. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-web/executors/webpack.md b/nx-dev/nx-dev/public/documentation/generated/api-web/executors/webpack.md deleted file mode 100644 index 243c29b9e7..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-web/executors/webpack.md +++ /dev/null @@ -1,272 +0,0 @@ ---- -title: '@nrwl/web:webpack executor' -description: 'Build an application using webpack' ---- - -# @nrwl/web:webpack - -Build an application using webpack - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Options - -### index (_**required**_) - -Type: `string` - -HTML File which will be contain the application - -### main (_**required**_) - -Type: `string` - -The name of the main entry-point file. - -### tsConfig (_**required**_) - -Type: `string` - -The name of the Typescript configuration file. - -### assets - -Type: `array` - -List of static application assets. - -### baseHref - -Type: `string` - -Base url for the application being built. - -### budgets - -Type: `array` - -Budget thresholds to ensure parts of your application stay within boundaries which you set. - -### buildLibsFromSource - -Default: `true` - -Type: `boolean` - -Read buildable libraries from source instead of building them separately. - -### commonChunk - -Default: `true` - -Type: `boolean` - -Use a separate bundle containing code used across multiple bundles. - -### compiler - -Default: `babel` - -Type: `string` - -Possible values: `babel`, `swc` - -The compiler to use - -### crossOrigin - -Type: `string` - -The crossorigin attribute to use for generated javascript script tags. One of 'none' | 'anonymous' | 'use-credentials' - -### deleteOutputPath - -Default: `true` - -Type: `boolean` - -Delete the output path before building. - -### deployUrl - -Type: `string` - -URL where the application will be deployed. - -### es2015Polyfills - -Type: `string` - -Conditional polyfills loaded in browsers which do not support ES2015. - -### extractCss - -Default: `false` - -Type: `boolean` - -Extract css into a .css file - -### extractLicenses - -Default: `false` - -Type: `boolean` - -Extract all licenses in a separate file, in the case of production builds only. - -### fileReplacements - -Type: `object[]` - -Replace files with other files in the build. - -#### replace - -Type: `string` - -The file to be replaced. - -#### with - -Type: `string` - -The file to replace with. - -### generateIndexHtml - -Default: `true` - -Type: `boolean` - -Generates `index.html` file to the output path. This can be turned off if using a webpack plugin to generate HTML such as `html-webpack-plugin` - -### maxWorkers - -Type: `number` - -Number of workers to use for type checking. (defaults to # of CPUS - 2) - -### memoryLimit - -Type: `number` - -Memory limit for type checking service process in MB. (defaults to 2048) - -### namedChunks - -Default: `true` - -Type: `boolean` - -Names the produced bundles according to their entry file - -### optimization - -Type: `boolean` - -Enables optimization of the build output. - -### outputHashing - -Default: `none` - -Type: `string` - -Possible values: `none`, `all`, `media`, `bundles` - -Define the output filename cache-busting hashing mode. - -### outputPath - -Type: `string` - -The output path of the generated files. - -### polyfills - -Type: `string` - -Polyfills to load before application - -### progress - -Default: `false` - -Type: `boolean` - -Log progress to the console while building. - -### runtimeChunk - -Default: `true` - -Type: `boolean` - -Use a separate bundle containing the runtime. - -### scripts - -Type: `array` - -External Scripts which will be included before the main application entry - -### sourceMap - -Default: `true` - -Type: `boolean | string ` - -Output sourcemaps. Use 'hidden' for use with error reporting tools without generating sourcemap comment. - -### statsJson - -Default: `false` - -Type: `boolean` - -Generates a 'stats.json' file which can be analyzed using tools such as: 'webpack-bundle-analyzer' or . - -### styles - -Type: `array` - -External Styles which will be included with the application - -### subresourceIntegrity - -Default: `false` - -Type: `boolean` - -Enables the use of subresource integrity validation. - -### vendorChunk - -Default: `true` - -Type: `boolean` - -Use a separate bundle containing only vendor libraries. - -### verbose - -Default: `false` - -Type: `boolean` - -Emits verbose output - -### watch - -Default: `false` - -Type: `boolean` - -Enable re-building when files change. - -### webpackConfig - -Type: `string` - -Path to a function which takes a webpack config, some context and returns the resulting webpack config diff --git a/nx-dev/nx-dev/public/documentation/generated/api-web/generators/application.md b/nx-dev/nx-dev/public/documentation/generated/api-web/generators/application.md deleted file mode 100644 index 3d5a1cf708..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-web/generators/application.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: '@nrwl/web:application generator' -description: 'Create an application' ---- - -# @nrwl/web:application - -Create an application - -## Usage - -```bash -nx generate application ... -``` - -```bash -nx g app ... # same -``` - -By default, Nx will search for `application` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/web:application ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g application ... --dry-run -``` - -## Options - -### compiler - -Default: `babel` - -Type: `string` - -Possible values: `babel`, `swc` - -The compiler to use - -### directory - -Type: `string` - -The directory of the new application. - -### e2eTestRunner - -Default: `cypress` - -Type: `string` - -Possible values: `cypress`, `none` - -Test runner to use for end to end (e2e) tests - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint`, `tslint` - -The tool to use for running lint checks. - -### name - -Type: `string` - -The name of the application. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### style - -Default: `css` - -Type: `string` - -Possible values: `css`, `scss`, `styl`, `less` - -The file extension to be used for style files. - -### tags - -Type: `string` - -Add tags to the application (used for linting) - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-workspace/executors/run-commands.md b/nx-dev/nx-dev/public/documentation/generated/api-workspace/executors/run-commands.md deleted file mode 100644 index e768aa54b4..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-workspace/executors/run-commands.md +++ /dev/null @@ -1,230 +0,0 @@ ---- -title: '@nrwl/workspace:run-commands executor' -description: 'Run any custom commands with Nx' ---- - -# @nrwl/workspace:run-commands - -Run any custom commands with Nx - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Examples - -`workspace.json`: - -```json -//... -"frontend": { - "targets": { - //... - "ls-project-root": { - "executor": "@nrwl/workspace:run-commands", - "options": { - "command": "ls apps/frontend/src" - } - } - } -} -``` - -```bash -nx run frontend:ls-project-root -``` - -##### Chaining commands, interpolating args and setting the cwd - -Let's say each of our workspace projects has some custom bash scripts in a `scripts` folder. -We want a simple way to create empty bash script files for a given project, that have the execute permissions already set. - -Given that Nx knows our workspace structure, we should be able to give it a project and the name of our script, and it should take care of the rest. - -The `commands` option accepts as many commands as you want. By default, they all run in parallel. -You can run them sequentially by setting `parallel: false`: - -```json -"create-script": { - "executor": "@nrwl/workspace:run-commands", - "options": { - "commands": [ - "mkdir -p scripts", - "touch scripts/{args.name}.sh", - "chmod +x scripts/{args.name}.sh" - ], - "cwd": "apps/frontend", - "parallel": false - } -} -``` - -By setting the `cwd` option, each command will run in the `apps/frontend` folder. - -We run the above with: - -```bash -nx run frontend:create-script --args="--name=example" -``` - -or simply with: - -```bash -nx run frontend:create-script --name=example -``` - -##### Arguments forwarding - -When interpolation is not present in the command, all arguments are forwarded to the command by default. - -This is useful when you need to pass raw argument strings to your command. - -For example, when you run: - -nx run frontend:webpack --args="--config=example.config.js" - -```json -"webpack": { - "executor": "@nrwl/workspace:run-commands", - "options": { - "command": "webpack" - } -} -``` - -The above command will execute: `webpack --config=example.config.js` - -This functionality can be disabled by using `commands` and expanding each `command` into an object -that sets the `forwardAllArgs` option to `false` as shown below: - -```json -"webpack": { - "executor": "@nrwl/workspace:run-commands", - "options": { - "commands": [ - { - "command": "webpack", - "forwardAllArgs": false - } - ] - } -} -``` - -##### Custom **done** conditions - -Normally, `run-commands` considers the commands done when all of them have finished running. If you don't need to wait until they're all done, you can set a special string that considers the commands finished the moment the string appears in `stdout` or `stderr`: - -```json -"finish-when-ready": { - "executor": "@nrwl/workspace:run-commands", - "options": { - "commands": [ - "sleep 5 && echo 'FINISHED'", - "echo 'READY'" - ], - "readyWhen": "READY", - "parallel": true - } -} -``` - -```bash -nx run frontend:finish-when-ready -``` - -The above commands will finish immediately, instead of waiting for 5 seconds. - -##### Nx Affected - -The true power of `run-commands` comes from the fact that it runs through `nx`, which knows about your project graph. So you can run **custom commands** only for the projects that have been affected by a change. - -We can create some configurations to generate docs, and if run using `nx affected`, it will only generate documentation for the projects that have been changed: - -```bash -nx affected --target=generate-docs -``` - -```json -//... -"frontend": { - "targets": { - //... - "generate-docs": { - "executor": "@nrwl/workspace:run-commands", - "options": { - "command": "npx compodoc -p apps/frontend/tsconfig.app.json" - } - } - } -}, -"api": { - "targets": { - //... - "generate-docs": { - "executor": "@nrwl/workspace:run-commands", - "options": { - "command": "npx compodoc -p apps/api/tsconfig.app.json" - } - } - } -} -``` - -## Options - -### args - -Type: `string` - -Extra arguments. You can pass them as follows: nx run project:target --args='--wait=100'. You can then use {args.wait} syntax to interpolate them in the workspace config file. See example [above](#chaining-commands-interpolating-args-and-setting-the-cwd) - -### color - -Default: `false` - -Type: `boolean` - -Use colors when showing output of command - -### command - -Type: `string` - -Command to run in child process - -### commands - -Type: `array` - -Commands to run in child process - -### cwd - -Type: `string` - -Current working directory of the commands. If it's not specified the commands will run in the workspace root, if a relative path is specified the commands will run in that path relative to the workspace root and if it's an absolute path the commands will run in that path. - -### envFile - -Type: `string` - -You may specify a custom .env file path - -### outputPath - -Type: `string | string[] ` - -Allows you to specify where the build artifacts are stored. This allows Nx Cloud to pick them up correctly, in the case that the build artifacts are placed somewhere other than the top level dist folder. - -### parallel - -Default: `true` - -Type: `boolean` - -Run commands in parallel - -### readyWhen - -Type: `string` - -String to appear in `stdout` or `stderr` that indicates that the task is done. When running multiple commands, this option can only be used when `parallel` is set to `true`. If not specified, the task is done when all the child processes complete. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-workspace/executors/run-script.md b/nx-dev/nx-dev/public/documentation/generated/api-workspace/executors/run-script.md deleted file mode 100644 index 344a4eda77..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-workspace/executors/run-script.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: '@nrwl/workspace:run-script executor' -description: 'Run an npm script using Nx' ---- - -# @nrwl/workspace:run-script - -Run an npm script using Nx - -Options can be configured in `workspace.json` when defining the executor, or when invoking it. Read more about how to configure targets and executors here: https://nx.dev/configuration/projectjson#targets. - -## Examples - -`workspace.json`: - -```json -"frontend": { - "root": "packages/frontend", - "targets": { - "build": { - "executor": "@nrwl/workspace:run-script", - "options": { - "script": "build-my-project" - } - } - } -} -``` - -```bash -nx run frontend:build -``` - -The `build` target is going to run `npm run build-my-project` (or `yarn build-my-project`) in the `packages/frontend` directory. - -#### Caching Artifacts - -By default, Nx is going to cache `dist/packages/frontend`, `packages/frontend/dist`, `packages/frontend/build`, `packages/frontend/public`. If your npm script writes files to other places, you can override the list of cached outputs as follows: - -```json -"frontend": { - "root": "packages/frontend", - "targets": { - "build": { - "executor": "@nrwl/workspace:run-script", - "outputs": ["packages/frontend/dist", "packaged/frontend/docs"], - "options": { - "script": "build-my-project" - } - } - } -} -``` - -## Options - -### script (_**required**_) - -Type: `string` - -An npm script name in the package.json file of the project (e.g., build) diff --git a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/convert-to-nx-project.md b/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/convert-to-nx-project.md deleted file mode 100644 index 3d768395c5..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/convert-to-nx-project.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: '@nrwl/workspace:convert-to-nx-project generator' -description: "Moves a project's configuration outside of workspace.json" ---- - -# @nrwl/workspace:convert-to-nx-project - -Moves a project's configuration outside of workspace.json - -## Usage - -```bash -nx generate convert-to-nx-project ... -``` - -By default, Nx will search for `convert-to-nx-project` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/workspace:convert-to-nx-project ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g convert-to-nx-project ... --dry-run -``` - -### Examples - -Convert the my-feature-lib project to use project.json file instead of workspace.json: - -```bash -nx g @nrwl/workspace:convert-to-nx-project --project my-feature-lib -``` - -Convert all projects in workspace.json to separate project.json files.: - -```bash -nx g @nrwl/workspace:convert-to-nx-project --all -``` - -## Options - -### all - -Type: `boolean` - -Should every project be converted? - -### project - -Type: `string` - -Project name - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/library.md b/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/library.md deleted file mode 100644 index 49245254c0..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/library.md +++ /dev/null @@ -1,176 +0,0 @@ ---- -title: '@nrwl/workspace:library generator' -description: 'Create a library' ---- - -# @nrwl/workspace:library - -Create a library - -## Usage - -```bash -nx generate library ... -``` - -```bash -nx g lib ... # same -``` - -By default, Nx will search for `library` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/workspace:library ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g library ... --dry-run -``` - -### Examples - -Generate libs/myapp/mylib: - -```bash -nx g lib mylib --directory=myapp -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Library name - -### babelJest - -Default: `false` - -Type: `boolean` - -Use babel instead ts-jest - -### buildable - -Default: `false` - -Type: `boolean` - -Generate a buildable library. - -### directory - -Type: `string` - -A directory where the lib is placed - -### importPath - -Type: `string` - -The library name used to import it, like @myorg/my-awesome-lib - -### js - -Default: `false` - -Type: `boolean` - -Generate JavaScript files rather than TypeScript files - -### linter - -Default: `eslint` - -Type: `string` - -Possible values: `eslint` - -The tool to use for running lint checks. - -### pascalCaseFiles - -Alias(es): P - -Default: `false` - -Type: `boolean` - -Use pascal case file names. - -### setParserOptionsProject - -Default: `false` - -Type: `boolean` - -Whether or not to configure the ESLint "parserOptions.project" option. We do not do this by default for lint performance reasons. - -### skipBabelrc - -Default: `false` - -Type: `boolean` - -Do not generate .babelrc file. Useful for Node libraries that are not compiled by Babel - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files - -### skipTsConfig - -Default: `false` - -Type: `boolean` - -Do not update tsconfig.json for development experience. - -### standaloneConfig - -Type: `boolean` - -Split the project configuration into /project.json rather than including it inside workspace.json - -### strict - -Default: `true` - -Type: `boolean` - -Whether to enable tsconfig strict mode or not. - -### tags - -Type: `string` - -Add tags to the library (used for linting) - -### testEnvironment - -Default: `jsdom` - -Type: `string` - -Possible values: `jsdom`, `node` - -The test environment to use if unitTestRunner is set to jest - -### unitTestRunner - -Default: `jest` - -Type: `string` - -Possible values: `jest`, `none` - -Test runner to use for unit tests diff --git a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/move.md b/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/move.md deleted file mode 100644 index cde24e0be6..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/move.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: '@nrwl/workspace:move generator' -description: 'Move an application or library to another folder' ---- - -# @nrwl/workspace:move - -Move an application or library to another folder - -## Usage - -```bash -nx generate move ... -``` - -```bash -nx g mv ... # same -``` - -By default, Nx will search for `move` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/workspace:move ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g move ... --dry-run -``` - -### Examples - -Move libs/my-feature-lib to libs/shared/my-feature-lib: - -```bash -nx g @nrwl/workspace:move --project my-feature-lib shared/my-feature-lib -``` - -## Options - -### destination (_**required**_) - -Type: `string` - -The folder to move the project into - -### projectName (_**required**_) - -Alias(es): project - -Type: `string` - -The name of the project to move - -### importPath - -Type: `string` - -The new import path to use in the tsconfig.base.json - -### skipFormat - -Alias(es): skip-format - -Default: `false` - -Type: `boolean` - -Skip formatting files. - -### updateImportPath - -Default: `true` - -Type: `boolean` - -Should the generator update the import path to reflect the new location? diff --git a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/npm-package.md b/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/npm-package.md deleted file mode 100644 index ca5ad7bdc5..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/npm-package.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: '@nrwl/workspace:npm-package generator' -description: 'Create a minimal npm package' ---- - -# @nrwl/workspace:npm-package - -Create a minimal npm package - -## Usage - -```bash -nx generate npm-package ... -``` - -By default, Nx will search for `npm-package` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/workspace:npm-package ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g npm-package ... --dry-run -``` - -## Options - -### name (_**required**_) - -Type: `string` - -Package name diff --git a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/remove.md b/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/remove.md deleted file mode 100644 index 494639ce26..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/remove.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: '@nrwl/workspace:remove generator' -description: 'Remove an application or library' ---- - -# @nrwl/workspace:remove - -Remove an application or library - -## Usage - -```bash -nx generate remove ... -``` - -```bash -nx g rm ... # same -``` - -By default, Nx will search for `remove` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/workspace:remove ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g remove ... --dry-run -``` - -### Examples - -Remove my-feature-lib from the workspace: - -```bash -nx g @nrwl/workspace:remove my-feature-lib -``` - -Force removal of my-feature-lib from the workspace: - -```bash -nx g @nrwl/workspace:remove my-feature-lib --forceRemove -``` - -## Options - -### projectName (_**required**_) - -Alias(es): project - -Type: `string` - -The name of the project to remove - -### forceRemove - -Alias(es): force-remove - -Default: `false` - -Type: `boolean` - -When true, forces removal even if the project is still in use. - -### skipFormat - -Alias(es): skip-format - -Default: `false` - -Type: `boolean` - -Skip formatting files. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/run-commands.md b/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/run-commands.md deleted file mode 100644 index 79cb2ee0ef..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/run-commands.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: '@nrwl/workspace:run-commands generator' -description: 'Generates a target to run any command in the terminal' ---- - -# @nrwl/workspace:run-commands - -Generates a target to run any command in the terminal - -## Usage - -```bash -nx generate run-commands ... -``` - -```bash -nx g run-command ... # same -``` - -By default, Nx will search for `run-commands` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/workspace:run-commands ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g run-commands ... --dry-run -``` - -### Examples - -Add the printhello target to my-feature-lib: - -```bash -nx g @nrwl/workspace:run-commands printhello --project my-feature-lib --command 'echo hello' -``` - -## Options - -### command (_**required**_) - -Type: `string` - -Command to run - -### name (_**required**_) - -Type: `string` - -Target name - -### project (_**required**_) - -Type: `string` - -Project name - -### cwd - -Type: `string` - -Current working directory of the command - -### envFile - -Type: `string` - -Env files to be loaded before executing the commands - -### outputs - -Type: `string` - -Allows you to specify where the build artifacts are stored. This allows Nx Cloud to pick them up correctly, in the case that the build artifacts are placed somewhere other than the top level dist folder. diff --git a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/workspace-generator.md b/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/workspace-generator.md deleted file mode 100644 index 99fdf2e494..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/api-workspace/generators/workspace-generator.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: '@nrwl/workspace:workspace-generator generator' -description: 'Generates a workspace generator' ---- - -# @nrwl/workspace:workspace-generator - -Generates a workspace generator - -## Usage - -```bash -nx generate workspace-generator ... -``` - -```bash -nx g workspace-schematic ... # same -``` - -By default, Nx will search for `workspace-generator` in the default collection provisioned in `workspace.json`. - -You can specify the collection explicitly as follows: - -```bash -nx g @nrwl/workspace:workspace-generator ... -``` - -Show what will be generated without writing to disk: - -```bash -nx g workspace-generator ... --dry-run -``` - -## Options - -### name - -Type: `string` - -Generator name - -### skipFormat - -Default: `false` - -Type: `boolean` - -Skip formatting files diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/affected-apps.md b/nx-dev/nx-dev/public/documentation/generated/cli/affected-apps.md deleted file mode 100644 index 2849cdc215..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/affected-apps.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: 'affected:apps - CLI command' -description: 'Print applications affected by changes' ---- - -# affected:apps - -Print applications affected by changes - -## Usage - -```bash -nx affected:apps -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Print the names of all the apps affected by changing the index.ts file: - -```bash -nx affected:apps --files=libs/mylib/src/index.ts -``` - -Print the names of all the apps affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected:apps --base=main --head=HEAD -``` - -Print the names of all the apps affected by the last commit on main: - -```bash -nx affected:apps --base=main~1 --head=main -``` - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### plain - -Produces a plain output for affected:apps and affected:libs - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/affected-build.md b/nx-dev/nx-dev/public/documentation/generated/cli/affected-build.md deleted file mode 100644 index 362c4b4977..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/affected-build.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: 'affected:build - CLI command' -description: 'Build applications and publishable libraries affected by changes' ---- - -# affected:build - -Build applications and publishable libraries affected by changes - -## Usage - -```bash -nx affected:build -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run build in parallel: - -```bash -nx affected:build --parallel=5 -``` - -Run the build target for all projects: - -```bash -nx affected:build --all -``` - -Run build for all the projects affected by changing the index.ts file: - -```bash -nx affected:build --files=libs/mylib/src/index.ts -``` - -Run build for all the projects affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected:build --base=main --head=HEAD -``` - -Run build for all the projects affected by the last commit on main: - -```bash -nx affected:build --base=main~1 --head=main -``` - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### parallel - -Max number of parallel processes [default is 3] - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/affected-e2e.md b/nx-dev/nx-dev/public/documentation/generated/cli/affected-e2e.md deleted file mode 100644 index e36525757e..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/affected-e2e.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: 'affected:e2e - CLI command' -description: 'Run e2e tests for the applications affected by changes' ---- - -# affected:e2e - -Run e2e tests for the applications affected by changes - -## Usage - -```bash -nx affected:e2e -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run tests in parallel: - -```bash -nx affected:e2e --parallel=5 -``` - -Run the test target for all projects: - -```bash -nx affected:e2e --all -``` - -Run tests for all the projects affected by changing the index.ts file: - -```bash -nx affected:e2e --files=libs/mylib/src/index.ts -``` - -Run tests for all the projects affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected:e2e --base=main --head=HEAD -``` - -Run tests for all the projects affected by the last commit on main: - -```bash -nx affected:e2e --base=main~1 --head=main -``` - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### parallel - -Max number of parallel processes [default is 3] - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/affected-graph.md b/nx-dev/nx-dev/public/documentation/generated/cli/affected-graph.md deleted file mode 100644 index ba409666b2..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/affected-graph.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -title: 'affected:graph - CLI command' -description: 'Graph dependencies affected by changes. Alias: affected:dep-graph' ---- - -# affected:graph - -Graph dependencies affected by changes. Alias: affected:dep-graph - -## Usage - -```bash -nx affected:graph -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Open the project graph of the workspace in the browser, and highlight the projects affected by changing the index.ts file: - -```bash -nx affected:graph --files=libs/mylib/src/index.ts -``` - -Open the project graph of the workspace in the browser, and highlight the projects affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected:graph --base=main --head=HEAD -``` - -Save the project graph of the workspace in a json file, and highlight the projects affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected:graph --base=main --head=HEAD --file=output.json -``` - -Generate a static website with project graph data in an html file, highlighting the projects affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected:graph --base=main --head=HEAD --file=output.html -``` - -Open the project graph of the workspace in the browser, and highlight the projects affected by the last commit on main: - -```bash -nx affected:graph --base=main~1 --head=main -``` - -Open the project graph of the workspace in the browser, highlight the projects affected, but exclude project-one and project-two: - -```bash -nx affected:graph --exclude=project-one,project-two -``` - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### file - -Output file (e.g. --file=output.json or --file=dep-graph.html) - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### focus - -Use to show the project graph for a particular project and every node that is either an ancestor or a descendant. - -### groupByFolder - -Group projects by folder in the project graph - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### host - -Bind the project graph server to a specific ip address. - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### open - -Default: `true` - -Open the project graph in the browser. - -### port - -Bind the project graph server to a specific port. - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number - -### watch - -Default: `false` - -Watch for changes to project graph and update in-browser diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/affected-libs.md b/nx-dev/nx-dev/public/documentation/generated/cli/affected-libs.md deleted file mode 100644 index 27bab31a50..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/affected-libs.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: 'affected:libs - CLI command' -description: 'Print libraries affected by changes' ---- - -# affected:libs - -Print libraries affected by changes - -## Usage - -```bash -nx affected:libs -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Print the names of all the libs affected by changing the index.ts file: - -```bash -nx affected:libs --files=libs/mylib/src/index.ts -``` - -Print the names of all the libs affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected:libs --base=main --head=HEAD -``` - -Print the names of all the libs affected by the last commit on main: - -```bash -nx affected:libs --base=main~1 --head=main -``` - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### plain - -Produces a plain output for affected:apps and affected:libs - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/affected-lint.md b/nx-dev/nx-dev/public/documentation/generated/cli/affected-lint.md deleted file mode 100644 index e188e0034d..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/affected-lint.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: 'affected:lint - CLI command' -description: 'Lint projects affected by changes' ---- - -# affected:lint - -Lint projects affected by changes - -## Usage - -```bash -nx affected:lint -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run lint in parallel: - -```bash -nx affected:lint --parallel=5 -``` - -Run the lint target for all projects: - -```bash -nx affected:lint --all -``` - -Run lint for all the projects affected by changing the index.ts file: - -```bash -nx affected:lint --files=libs/mylib/src/index.ts -``` - -Run lint for all the projects affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected:lint --base=main --head=HEAD -``` - -Run lint for all the projects affected by the last commit on main: - -```bash -nx affected:lint --base=main~1 --head=main -``` - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### parallel - -Max number of parallel processes [default is 3] - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/affected-test.md b/nx-dev/nx-dev/public/documentation/generated/cli/affected-test.md deleted file mode 100644 index da41a3d689..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/affected-test.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: 'affected:test - CLI command' -description: 'Test projects affected by changes' ---- - -# affected:test - -Test projects affected by changes - -## Usage - -```bash -nx affected:test -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run tests in parallel: - -```bash -nx affected:test --parallel=5 -``` - -Run the test target for all projects: - -```bash -nx affected:test --all -``` - -Run tests for all the projects affected by changing the index.ts file: - -```bash -nx affected:test --files=libs/mylib/src/index.ts -``` - -Run tests for all the projects affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected:test --base=main --head=HEAD -``` - -Run tests for all the projects affected by the last commit on main: - -```bash -nx affected:test --base=main~1 --head=main -``` - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### parallel - -Max number of parallel processes [default is 3] - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/affected.md b/nx-dev/nx-dev/public/documentation/generated/cli/affected.md deleted file mode 100644 index 31c8b5d951..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/affected.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -title: 'affected - CLI command' -description: 'Run target for affected projects' ---- - -# affected - -Run target for affected projects - -## Usage - -```bash -nx affected -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run custom target for all affected projects: - -```bash -nx affected --target=custom-target -``` - -Run tests in parallel: - -```bash -nx affected --target=test --parallel=5 -``` - -Run the test target for all projects: - -```bash -nx affected --target=test --all -``` - -Run tests for all the projects affected by changing the index.ts file: - -```bash -nx affected --target=test --files=libs/mylib/src/index.ts -``` - -Run tests for all the projects affected by the changes between main and HEAD (e.g., PR): - -```bash -nx affected --target=test --base=main --head=HEAD -``` - -Run tests for all the projects affected by the last commit on main: - -```bash -nx affected --target=test --base=main~1 --head=main -``` - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### parallel - -Max number of parallel processes [default is 3] - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### target - -Task to run for affected projects - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/build.md b/nx-dev/nx-dev/public/documentation/generated/cli/build.md deleted file mode 100644 index b35c5c1499..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/build.md +++ /dev/null @@ -1,298 +0,0 @@ ---- -title: 'build - CLI command' -description: 'Compiles an application into an output directory named dist/ at the given output path. Must be executed from within a workspace directory.' ---- - -# build - -Compiles an application into an output directory named dist/ at the given output path. Must be executed from within a workspace directory. - -## Usage - -The `build` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx build [options] -``` - -```bash -nx run :build [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Compile a `production` build of the `myapp` project: - -```bash -nx build myapp --prod -``` - -## Options - -The options below are common to the `build` command used within an Nx workspace. The Web and Angular-specific build options are listed after these options. - -### baseHref - -Default: `/` - -Base url for the application being built. - -### commonChunk - -Use a separate bundle containing code used across multiple bundles. - -Default: `true` - -### budgets - -Budget thresholds to ensure parts of your application stay within boundaries which you set. - -### namedChunks - -Default: `true` - -Names the produced bundles according to their entry file - -### deployUrl - -URL where the application will be deployed. - -### es2015Polyfills - -Conditional polyfills loaded in browsers which do not support ES2015. - -### extractCss - -Extract css into a .css file - -### extractLicenses - -Extract all licenses in a separate file, in the case of production builds only. - -### index - -HTML File which will be contain the application - -### main - -The name of the main entry-point file. - -### tsConfig - -The name of the Typescript configuration file. - -### outputPath - -The output path of the generated files. - -### progress - -Log progress to the console while building. - -### optimization - -Enables optimization of the build output. - -### outputHashing - -Default: `none` - -Define the output filename cache-busting hashing mode. - -### scripts - -External Scripts which will be included before the main application entry. - -### showCircularDependencies - -Default: `true` - -Show circular dependency warnings on builds. - -### sourceMap - -Default: `true` - -Output sourcemaps. - -### statsJson - -Generates a 'stats.json' file which can be analyzed using tools such as: 'webpack-bundle-analyzer' or . - -### styles - -External Styles which will be included with the application - -### subresourceIntegrity - -Enables the use of subresource integrity validation. - -### vendorChunk - -Default: `true` - -Use a separate bundle containing only vendor libraries. - -### verbose - -Emits verbose output - -### watch - -Enable re-building when files change. - -### help - -Show help information - -### version - -Show version number - -## Web-Build Options - -### assets - -List of static application assets. - -### fileReplacements - -Replace files with other files in the build. - -### maxWorkers - -Number of workers to use for type checking. - -Default: `# of CPUS - 2` - -### memoryLimit - -Memory limit for type checking service process in MB. - -Default: `2048` - -### polyfills - -Polyfills to load before application - -### stylePreprocessorOptions - -Options to pass to style preprocessors. - -### webpackConfig - -Path to a function which takes a webpack config, some context and returns the resulting webpack config - -## Angular Options - -### aot - -Build using Ahead of Time compilation. - -### buildEventLog - -**EXPERIMENTAL** Output file path for Build Event Protocol events - -### buildOptimizer - -Enables `@angular-devkit/build-optimizer` optimizations when using the `--aot` option. - -### configuration (-c) - -A named build target, as specified in the "configurations" section of angular.json. -Each named target is accompanied by a configuration of option defaults for that target. -Setting this explicitly overrides the "--prod" flag - -### crossOrigin - -Define the crossorigin attribute setting of elements that provide CORS support. - -### deleteOutputPath - -Delete the output path before building. - -### deployUrl - -URL where files will be deployed. - -### es5BrowserSupport - -Enables conditionally loaded ES2015 polyfills. - -### evalSourceMap - -Output in-file eval sourcemaps. - -### experimentalRollupPass - -Concatenate modules with Rollup before bundling them with Webpack. - -### forkTypeChecker - -Run the TypeScript type checker in a forked process. - -### i18nFile - -Localization file to use for i18n. - -### i18nFormat - -Format of the localization file specified with --i18n-file. - -### i18nLocale - -Locale to use for i18n. - -### i18nMissingTranslation - -How to handle missing translations for i18n. - -### localize - -### ngswConfigPath - -Path to ngsw-config.json. - -### poll - -Enable and define the file watching poll time period in milliseconds. - -### polyfills - -The full path for the polyfills file, relative to the current workspace. - -### preserveSymlinks - -Do not use the real path when resolving modules. - -### rebaseRootRelativeCssUrls - -Change root relative URLs in stylesheets to include base HREF and deploy URL. Use only for compatibility and transition. The behavior of this option is non-standard and will be removed in the next major release. - -### resourcesOutputPath - -The path where style resources will be placed, relative to outputPath. - -### serviceWorker - -Generates a service worker config for production builds. - -### skipAppShell - -Flag to prevent building an app shell. - -### vendorSourceMap - -Resolve vendor packages sourcemaps. - -### verbose - -Adds more details to output logging. - -### webWorkerTsConfig - -TypeScript configuration for Web Worker modules. diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/connect-to-nx-cloud.md b/nx-dev/nx-dev/public/documentation/generated/cli/connect-to-nx-cloud.md deleted file mode 100644 index bc65d4a7bb..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/connect-to-nx-cloud.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 'connect-to-nx-cloud - CLI command' -description: 'Makes sure the workspace is connected to Nx Cloud' ---- - -# connect-to-nx-cloud - -Makes sure the workspace is connected to Nx Cloud - -## Usage - -```bash -nx connect-to-nx-cloud -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -## Options - -### help - -Show help - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/daemon.md b/nx-dev/nx-dev/public/documentation/generated/cli/daemon.md deleted file mode 100644 index aa9d4a509c..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/daemon.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: 'daemon - CLI command' -description: "The Nx Daemon is a local server which runs in the background in order to intelligently cache information about the workspace's project graph." ---- - -# daemon - -The Nx Daemon is a local server which runs in the background in order to intelligently cache information about the workspace's project graph. - -## Usage - -```bash -nx daemon -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -## Options - -### background - -Default: `true` - -### help - -Show help - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/e2e.md b/nx-dev/nx-dev/public/documentation/generated/cli/e2e.md deleted file mode 100644 index 117d964a4b..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/e2e.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -title: 'e2e - CLI command' -description: 'Builds and serves an app, then runs end-to-end tests using the configured E2E test runner.' ---- - -# e2e - -Builds and serves an app, then runs end-to-end tests using the configured E2E test runner. - -## Usage - -The `e2e` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx e2e -``` - -```bash -nx run :e2e -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run E2E test with a custom base url: - -```bash -nx e2e myapp-e2e --base-url http://localhost:4201 -``` - -Run E2E test with a specific target: - -```bash -nx e2e myapp-e2e --configuration smoke -``` - -Run E2E test in watch mode: - -```bash -nx e2e myapp-e2e --watch -``` - -## Common Options - -The options below are common to the E2E commands used within an Nx workspace. Cypress and Protractor-specific options are listed below. - -### baseUrl - -Use this to pass directly the address of your distant server address with the port running your application. Setting this will ignore any local server targets. To skip running local targets, reset the `devServerTarget` to empty string. - -### configuration (-c) - -A named build target, as specified in the "configurations" section of angular.json. Each named target is accompanied by a configuration of option defaults for that target. Setting this explicitly overrides the `--prod` option. - -### devServerTarget - -Dev server target to run tests against. - -### prod - -Shorthand for `--configuration=production`. When true, sets the build configuration to the production target. By default, the production target is set up in the workspace configuration such that all builds make use of bundling, limited tree-shaking, and also limited dead code elimination. - -### version - -Show version number - -### watch - -Open the Cypress test runner & automatically run tests when files are updated - -## Cypress Options - -### browser - -The browser to run tests in. - -### ci-build-id - -A unique identifier for a run to enable grouping or parallelization. - -### ci-build-id - -A unique identifier for a run to enable grouping or parallelization. - -### cypress-config - -The path of the Cypress configuration json file. - -### exit - -Whether or not the Cypress Test Runner will stay open after running tests in a spec file - -### group - -A named group for recorded runs in the Cypress dashboard. - -### headless - -Whether or not to open the Cypress application to run the tests. If set to 'true', will run in headless mode. - -### help - -Shows a help message for this command in the console. - -### key - -The key cypress should use to run tests in parallel/record the run (CI only). - -### parallel - -Whether or not Cypress should run its tests in parallel (CI only). - -### record - -Whether or not Cypress should record the results of the tests - -### spec - -A comma delimited glob string that is provided to the Cypress runner to specify which spec files to run. For example: '**examples/**,**actions.spec** - -### ts-config - -The path of the Cypress tsconfig configuration json file. - -## Protractor Options - -### element-explorer - -Start Protractor's Element Explorer for debugging. - -### host - -Host to listen on. - -### port - -The port to use to serve the application. - -### protractor-config - -The name of the Protractor configuration file. - -### specs - -Override specs in the protractor config. - -### suite - -Override suite in the protractor config. - -### webdriver-update - -Try to update webdriver. diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/format-check.md b/nx-dev/nx-dev/public/documentation/generated/cli/format-check.md deleted file mode 100644 index cf036cf799..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/format-check.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: 'format:check - CLI command' -description: 'Check for un-formatted files' ---- - -# format:check - -Check for un-formatted files - -## Usage - -```bash -nx format:check -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### libs-and-apps - -Format only libraries and applications files. - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### projects - -Projects to format (comma delimited) - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/format-write.md b/nx-dev/nx-dev/public/documentation/generated/cli/format-write.md deleted file mode 100644 index 19bad53591..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/format-write.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: 'format:write - CLI command' -description: 'Overwrite un-formatted files' ---- - -# format:write - -Overwrite un-formatted files - -## Usage - -```bash -nx format:write -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### libs-and-apps - -Format only libraries and applications files. - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### projects - -Projects to format (comma delimited) - -### runner - -This is the name of the tasks runner configured in nx.json - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/generate.md b/nx-dev/nx-dev/public/documentation/generated/cli/generate.md deleted file mode 100644 index 785bd2c4a2..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/generate.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: 'generate - CLI command' -description: 'Runs a generator that creates and/or modifies files based on a generator from a collection.' ---- - -# generate - -Runs a generator that creates and/or modifies files based on a generator from a collection. - -## Usage - -```bash -nx generate -``` - -```bash -nx g -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Generate a new Angular application: - -```bash -nx generate @nrwl/angular:app myapp -``` - -Generate a new React application: - -```bash -nx generate @nrwl/react:app myapp -``` - -Generate a new web component application: - -```bash -nx generate @nrwl/web:app myapp -``` - -Generate a new Node application: - -```bash -nx generate @nrwl/node:app myapp -``` - -Generate a new Angular library application: - -```bash -nx generate @nrwl/angular:library mylibrary -``` - -Generate a new React library application: - -```bash -nx generate @nrwl/react:library mylibrary -``` - -Generate a new Node library application: - -```bash -nx generate @nrwl/node:library mylibrary -``` - -## Options - -### defaults - -Default: `false` - -When true, disables interactive input prompts for options with a default. - -### dryRun - -Default: `false` - -When true, disables interactive input prompts for options with a default. - -### force - -Default: `false` - -When true, forces overwriting of existing files. - -### interactive - -Default: `true` - -When false, disables interactive input prompts. - -### help - -Show help and display available generators in the default collection. - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/graph.md b/nx-dev/nx-dev/public/documentation/generated/cli/graph.md deleted file mode 100644 index 9c77a9a4a7..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/graph.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: 'graph - CLI command' -description: 'Graph dependencies within workspace. Alias: dep-graph' ---- - -# graph - -Graph dependencies within workspace. Alias: dep-graph - -## Usage - -```bash -nx graph -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Open the project graph of the workspace in the browser: - -```bash -nx graph -``` - -Save the project graph into a json file: - -```bash -nx graph --file=output.json -``` - -Generate a static website with project graph into an html file, accompanied by an asset folder called static: - -```bash -nx graph --file=output.html -``` - -Show the graph where every node is either an ancestor or a descendant of todos-feature-main: - -```bash -nx graph --focus=todos-feature-main -``` - -Include project-one and project-two in the project graph: - -```bash -nx graph --include=project-one,project-two -``` - -Exclude project-one and project-two from the project graph: - -```bash -nx graph --exclude=project-one,project-two -``` - -Show the graph where every node is either an ancestor or a descendant of todos-feature-main, but exclude project-one and project-two: - -```bash -nx graph --focus=todos-feature-main --exclude=project-one,project-two -``` - -Watch for changes to project graph and update in-browser: - -```bash -nx graph --watch -``` - -## Options - -### exclude - -List of projects delimited by commas to exclude from the project graph. - -### file - -Output file (e.g. --file=output.json or --file=dep-graph.html) - -### focus - -Use to show the project graph for a particular project and every node that is either an ancestor or a descendant. - -### groupByFolder - -Group projects by folder in the project graph - -### help - -Show help - -### host - -Bind the project graph server to a specific ip address. - -### open - -Default: `true` - -Open the project graph in the browser. - -### port - -Bind the project graph server to a specific port. - -### version - -Show version number - -### watch - -Default: `false` - -Watch for changes to project graph and update in-browser diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/lint.md b/nx-dev/nx-dev/public/documentation/generated/cli/lint.md deleted file mode 100644 index 1a6f588c43..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/lint.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: 'lint - CLI command' -description: 'Runs linting tools on application code in a given project folder using the configured linter.' ---- - -# lint - -Runs linting tools on application code in a given project folder using the configured linter. - -## Usage - -The `lint` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx lint [options] -``` - -```bash -nx run :lint [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run lint checks for the `myapp` project and fix linter errors: - -```bash -nx lint myapp --fix -``` - -## Common Options - -The options below are common to the `lint` command used within an Nx workspace. The ESLint and Angular-specific lint options are listed after these options. - -### exclude - -Files to exclude from linting. - -### files - -Files to include in linting. - -### fix - -Fixes linting errors (may overwrite linted files). - -### force - -Succeeds even if there was linting errors. - -### format - -ESLint Output formatter (https://eslint.org/docs/user-guide/formatters). (default: stylish) - -### silent - -Hide output text. - -### tsConfig - -The name of the TypeScript configuration file. - -### help - -Show help information - -### version - -Show version number - -## ESLint Options - -### cache - -Only check changed files. - -### cacheLocation - -Path to the cache file or directory. - -### config - -The name of the configuration file. - -### linter - -The tool to use for running lint checks. - -Default: `tslint` - -### outputFile - -File to write report to. - -## Angular-TSLint Options - -### configuration (-c) - -The linting configuration to use. - -### tslint-config - -The name of the TSLint configuration file. - -### type-check - -Controls the type check for linting. diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/list.md b/nx-dev/nx-dev/public/documentation/generated/cli/list.md deleted file mode 100644 index 79d632710a..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/list.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 'list - CLI command' -description: 'Lists installed plugins, capabilities of installed plugins and other available plugins.' ---- - -# list - -Lists installed plugins, capabilities of installed plugins and other available plugins. - -## Usage - -```bash -nx list -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -List the plugins installed in the current workspace: - -```bash -nx list -``` - -List the generators and executors available in the `@nrwl/web` plugin if it is installed (If the plugin is not installed `nx` will show advice on how to add it to your workspace): - -```bash -nx list @nrwl/web -``` - -## Options - -### help - -Show help - -### plugin - -The name of an installed plugin to query - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/migrate.md b/nx-dev/nx-dev/public/documentation/generated/cli/migrate.md deleted file mode 100644 index c50abbd5b9..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/migrate.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "migrate - CLI command" -description: "Creates a migrations file or runs migrations from the migrations file. -- Migrate packages and create migrations.json (e.g., nx migrate @nrwl/workspace@latest) -- Run migrations (e.g., nx migrate --run-migrations=migrations.json) -" ---- - -# migrate - -Creates a migrations file or runs migrations from the migrations file. - -- Migrate packages and create migrations.json (e.g., nx migrate @nrwl/workspace@latest) -- Run migrations (e.g., nx migrate --run-migrations=migrations.json) - -## Usage - -```bash -nx migrate -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Update @nrwl/workspace to "next". This will update other packages and will generate migrations.json: - -```bash -nx migrate next -``` - -Update @nrwl/workspace to "9.0.0". This will update other packages and will generate migrations.json: - -```bash -nx migrate 9.0.0 -``` - -Update @nrwl/workspace and generate the list of migrations starting with version 8.0.0 of @nrwl/workspace and @nrwl/node, regardless of what installed locally: - -```bash -nx migrate @nrwl/workspace@9.0.0 --from="@nrwl/workspace@8.0.0,@nrwl/node@8.0.0" -``` - -Update @nrwl/workspace to "9.0.0". If it tries to update @nrwl/react or @nrwl/angular, use version "9.0.1": - -```bash -nx migrate @nrwl/workspace@9.0.0 --to="@nrwl/react@9.0.1,@nrwl/angular@9.0.1" -``` - -Update another-package to "12.0.0". This will update other packages and will generate migrations.json file: - -```bash -nx migrate another-package@12.0.0 -``` - -Run migrations from the migrations.json file. You can modify migrations.json and run this command many times: - -```bash -nx migrate --run-migrations=migrations.json -``` - -## Options - -### help - -Show help - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/print-affected.md b/nx-dev/nx-dev/public/documentation/generated/cli/print-affected.md deleted file mode 100644 index cfe647da58..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/print-affected.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: 'print-affected - CLI command' -description: 'Prints information about the projects and targets affected by changes' ---- - -# print-affected - -Prints information about the projects and targets affected by changes - -## Usage - -```bash -nx print-affected -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Print information about affected projects and the project graph: - -```bash -nx print-affected -``` - -Print information about the projects affected by the changes between main and HEAD (e.g,. PR): - -```bash -nx print-affected --base=main --head=HEAD -``` - -Prints information about the affected projects and a list of tasks to test them: - -```bash -nx print-affected --target=test -``` - -Prints the projects property from the print-affected output: - -```bash -nx print-affected --target=build --select=projects -``` - -Prints the tasks.target.project property from the print-affected output: - -```bash -nx print-affected --target=build --select=tasks.target.project -``` - -## Options - -### all - -All projects - -### base - -Base of the current branch (usually main) - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### files - -Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas - -### head - -Latest commit of the current branch (usually HEAD) - -### help - -Show help - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Isolate projects which previously failed - -### runner - -This is the name of the tasks runner configured in nx.json - -### select - -Select the subset of the returned json document (e.g., --selected=projects) - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### uncommitted - -Uncommitted changes - -### untracked - -Untracked changes - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/report.md b/nx-dev/nx-dev/public/documentation/generated/cli/report.md deleted file mode 100644 index 0d78274e21..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/report.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 'report - CLI command' -description: 'Reports useful version numbers to copy into the Nx issue template' ---- - -# report - -Reports useful version numbers to copy into the Nx issue template - -## Usage - -```bash -nx report -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -## Options - -### help - -Show help - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/reset.md b/nx-dev/nx-dev/public/documentation/generated/cli/reset.md deleted file mode 100644 index 35700c9872..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/reset.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: 'reset - CLI command' -description: 'Clears all the cached Nx artifacts and metadata about the workspace and shuts down the Nx Daemon.' ---- - -# reset - -Clears all the cached Nx artifacts and metadata about the workspace and shuts down the Nx Daemon. - -## Usage - -```bash -nx reset -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/run-many.md b/nx-dev/nx-dev/public/documentation/generated/cli/run-many.md deleted file mode 100644 index 5c58a71ab1..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/run-many.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: 'run-many - CLI command' -description: 'Run target for multiple listed projects' ---- - -# run-many - -Run target for multiple listed projects - -## Usage - -```bash -nx run-many -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Test all projects: - -```bash -nx run-many --target=test --all -``` - -Test proj1 and proj2: - -```bash -nx run-many --target=test --projects=proj1,proj2 -``` - -Test proj1 and proj2 in parallel: - -```bash -nx run-many --target=test --projects=proj1,proj2 --parallel=2 -``` - -## Options - -### all - -Run the target on all projects in the workspace - -### configuration - -This is the configuration to use when performing tasks on projects - -### exclude - -Default: `` - -Exclude certain projects from being processed - -### help - -Show help - -### ~~only-failed~~ - -Default: `false` - -**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15. - -Only run the target on projects which previously failed - -### parallel - -Max number of parallel processes [default is 3] - -### projects - -Projects to run (comma delimited) - -### runner - -Override the tasks runner in `nx.json` - -### skip-nx-cache - -Default: `false` - -Rerun the tasks even when the results are available in the cache - -### target - -Task to run for affected projects - -### verbose - -Print additional error stack trace on failure - -### version - -Show version number - -### ~~with-deps~~ - -Default: `false` - -**Deprecated:** Configure target dependencies instead. It will be removed in v14. - -Include dependencies of specified projects when computing what to run diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/run.md b/nx-dev/nx-dev/public/documentation/generated/cli/run.md deleted file mode 100644 index 37f07a3de9..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/run.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 'run - CLI command' -description: 'Runs an Architect target with an optional custom builder configuration defined in your project.' ---- - -# run - -Runs an Architect target with an optional custom builder configuration defined in your project. - -## Usage - -```bash -nx run [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run the `build` target for the `myapp` : - -```bash -nx run myapp:build -``` - -Run the `build` target for the `myapp` project with a `production` configuration: - -```bash -nx run myapp:build:production -``` - -## Options - -### configuration (-c) - -A named builder configuration, defined in the "configurations" section of the workspace configuration file. The builder uses the named configuration to run the given target. - -### help - -Show help - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/serve.md b/nx-dev/nx-dev/public/documentation/generated/cli/serve.md deleted file mode 100644 index 519975a50b..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/serve.md +++ /dev/null @@ -1,204 +0,0 @@ ---- -title: 'serve - CLI command' -description: 'Builds and serves an application, rebuilding on file changes.' ---- - -# serve - -Builds and serves an application, rebuilding on file changes. - -## Usage - -The `serve` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx serve [options] -``` - -```bash -nx run :serve [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Serve the `myapp` project: - -```bash -nx serve myapp -``` - -## Common Options - -The options below are common to the `serve` command used within an Nx workspace. The Web and Angular-specific serve options are listed after these options. - -### allowedHosts - -This option allows you to whitelist services that are allowed to access the dev server. - -### hmr - -Enable hot module replacement. - -### host - -Host to listen on. - -Default: `localhost` - -### liveReload - -Whether to reload the page on change, using live-reload. - -Default: `true` - -### open (-o) - -Open the application in the browser. - -### port - -Port to listen on. - -Default: `4200` - -### publicHost - -Public URL where the application will be served - -### ssl - -Serve using HTTPS. - -### sslKey - -SSL key to use for serving HTTPS. - -### sslCert - -SSL certificate to use for serving HTTPS. - -### watch - -Watches for changes and rebuilds application - -Default: `true` - -### help - -Show help - -### version - -Show version number - -## Web-Serve Options - -### buildTarget - -Target which builds the application - -### memoryLimit - -Memory limit for type checking service process in MB. - -### maxWorkers - -Number of workers to use for type checking. - -## Angular-Serve Options - -### aot - -Build using Ahead of Time compilation. - -### base-href - -Base url for the application being built. - -### browser-target - -Target to serve. - -### build-event-log - -**EXPERIMENTAL** Output file path for Build Event Protocol events. - -### common-chunk - -Use a separate bundle containing code used across multiple bundles. - -### configuration (-c) - -A named build target, as specified in the "configurations" section of the workspace configuration. -Each named target is accompanied by a configuration of option defaults for that target. -Setting this explicitly overrides the `--prod` flag - -### deploy-url - -URL where files will be deployed. - -### disable-host-check - -Don't verify connected clients are part of allowed hosts. - -### eval-source-map - -Output in-file eval sourcemaps. - -### hmr-warning - -Show a warning when the `--hmr` option is enabled. - -### optimization - -Enables optimization of the build output. - -### poll - -Enable and define the file watching poll time period in milliseconds. - -### prod - -Shorthand for `--configuration=production`. -When true, sets the build configuration to the production target. -By default, the production target is set up in the workspace configuration such that all builds make use of bundling, limited tree-shaking, and also limited dead code elimination. - -### progress - -Log progress to the console while building. - -### proxy-config - -Proxy configuration file. - -### public-host - -The URL that the browser client (or live-reload client, if enabled) should use to connect to the development server. Use for a complex dev server setup, such as one with reverse proxies. - -### serve-path - -The pathname where the app will be served. - -### serve-path-default-warning - -Show a warning when deploy-url/base-href use unsupported serve path values. - -### source-map - -Output sourcemaps. - -### vendor-chunk - -Use a separate bundle containing only vendor libraries. - -### vendor-source-map - -Resolve vendor packages sourcemaps. - -### verbose - -Adds more details to output logging. diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/test.md b/nx-dev/nx-dev/public/documentation/generated/cli/test.md deleted file mode 100644 index c4eca9a970..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/test.md +++ /dev/null @@ -1,263 +0,0 @@ ---- -title: 'test - CLI command' -description: 'Runs unit tests in a project using the configured unit test runner.' ---- - -# test - -Runs unit tests in a project using the configured unit test runner. - -## Usage - -The `test` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx test [options] -``` - -```bash -nx run :test [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run unit tests: - -```bash -nx test myapp -``` - -## Common Options - -The options below are common to the `test` command used within an Nx workspace. The Jest and Karma-specific test options are listed after these options. - -### codeCoverage - -Indicates that test coverage information should be collected and reported in the output. (https://jestjs.io/docs/en/cli#coverage) - -### tsConfig - -The path to the Typescript configuration file. - -### watch - -Watch files for changes and rerun tests. - -### help - -Show help information. - -### version - -Show version number - -## Jest Options - -### bail - -Exit the test suite immediately after `n` number of failing tests. (https://jestjs.io/docs/en/cli#bail) - -### ci - -Whether to run Jest in continuous integration (CI) mode. This option is on by default in most popular CI environments. It will prevent snapshots from being written unless explicitly requested. (https://jestjs.io/docs/en/cli#ci) - -### color - -Forces test results output color highlighting (even if stdout is not a TTY). Set to false if you would like to have no colors. (https://jestjs.io/docs/en/cli#colors) - -### colors - -Forces test results output highlighting even if stdout is not a TTY. (https://jestjs.io/docs/en/cli#colors) - -### coverageReporters - -A list of reporter names that Jest uses when writing coverage reports. Any istanbul reporter - -### coverageDirectory - -An array of regexp pattern strings that are matched against all file paths before executing the test. If the file path matches any of the patterns, coverage information will be skipped. - -### config - -The path to a Jest config file specifying how to find and execute tests. If no rootDir is set in the config, the directory containing the config file is assumed to be the rootDir for the project. This can also be a JSON-encoded value which Jest will use as configuration - -### clearCache - -Deletes the Jest cache directory and then exits without running tests. Will delete Jest's default cache directory. _Note: clearing the cache will reduce performance_. - -### findRelatedTests - -Find and run the tests that cover a comma separated list of source files that were passed in as arguments. (https://jestjs.io/docs/en/cli#findrelatedtests-spaceseparatedlistofsourcefiles) - -### jestConfig - -The path of the Jest configuration. (https://jestjs.io/docs/en/configuration) - -### json - -Prints the test results in JSON. This mode will send all other test output and user messages to stderr. (https://jestjs.io/docs/en/cli#json) - -### maxWorkers - -Specifies the maximum number of workers the worker-pool will spawn for running tests. This defaults to the number of the cores available on your machine. Useful for CI. (its usually best not to override this default) (https://jestjs.io/docs/en/cli#maxworkers-num) - -### onlyChanged - -Attempts to identify which tests to run based on which files have changed in the current repository. Only works if you're running tests in a git or hg repository at the moment. (https://jestjs.io/docs/en/cli#onlychanged) - -### outputFile - -Write test results to a file when the --json option is also specified. (https://jestjs.io/docs/en/cli#outputfile-filename) - -### passWithNoTests - -Will not fail if no tests are found (for example while using `--testPathPattern`.) (https://jestjs.io/docs/en/cli#passwithnotests) - -### reporters - -Run tests with specified reporters. Reporter options are not available via CLI. Example with multiple reporters: jest --reporters="default" --reporters="jest-junit" (https://jestjs.io/docs/en/cli#reporters) - -### runInBand - -Run all tests serially in the current process (rather than creating a worker pool of child processes that run tests). This is sometimes useful for debugging, but such use cases are pretty rare. Useful for CI. (https://jestjs.io/docs/en/cli#runinband) - -### setupFile - -The name of a setup file used by Jest. (https://jestjs.io/docs/en/configuration#setupfilesafterenv-array) - -### silent - -Prevent tests from printing messages through the console. (https://jestjs.io/docs/en/cli#silent) - -### testFile - -The name of the file to test. - -### testNamePattern - -Run only tests with a name that matches the regex pattern. (https://jestjs.io/docs/en/cli#testnamepattern-regex) - -### testPathPattern - -An array of regexp pattern strings that is matched against all tests paths before executing the test. (https://jestjs.io/docs/en/cli#testpathpattern-regex) - -### testLocationInResults - -Adds a location field to test results. Used to report location of a test in a reporter. { "column": 4, "line": 5 } (https://jestjs.io/docs/en/cli#testlocationinresults) - -### testResultsProcessor - -Node module that implements a custom results processor. (https://jestjs.io/docs/en/configuration#testresultsprocessor-string) - -### updateSnapshot - -Use this flag to re-record snapshots. Can be used together with a test suite pattern or with `--testNamePattern` to re-record snapshot for test matching the pattern. (https://jestjs.io/docs/en/cli#updatesnapshot) - -### useStderr - -Divert all output to stderr. - -### verbose - -Display individual test results with the test suite hierarchy. (https://jestjs.io/docs/en/cli#verbose) - -### watchAll - -Watch files for changes and rerun all tests when something changes. If you want to re-run only the tests that depend on the changed files, use the `--watch` option. (https://jestjs.io/docs/en/cli#watchall) - -## Karma Options - -### browsers - -Override which browsers tests are run against. - -### codeCoverage - -Output a code coverage report. - -### codeCoverageExclude - -Globs to exclude from code coverage. - -### configuration (-c) - -A named build target, as specified in the "configurations" section of angular.json. -Each named target is accompanied by a configuration of option defaults for that target. -Setting this explicitly overrides the `--prod` flag. - -### environment - -Defines the build environment. - -### evalSourceMap - -Output in-file eval sourcemaps. - -### help - -Shows a help message for this command in the console. - -### include - -Globs of files to include, relative to workspace or project root. - -There are 2 special cases: - -- when a path to directory is provided, all spec files ending ".spec.@(ts|tsx)" will be included -- when a path to a file is provided, and a matching spec file exists it will be included instead - -### karmaConfig - -The name of the Karma configuration file. - -### main - -The name of the main entry-point file. - -### poll - -Enable and define the file watching poll time period in milliseconds. - -### polyfills - -The name of the polyfills file. - -### preserveSymlinks - -Do not use the real path when resolving modules. - -### prod - -Shorthand for "--configuration=production". When true, sets the build configuration to the production target. By default, the production target is set up in the workspace configuration such that all builds make use of bundling, limited tree-shaking, and also limited dead code elimination. - -### progress - -Log progress to the console while building. - -### reporters - -Karma reporters to use. Directly passed to the karma runner. - -### sourceMap - -Output sourcemaps. - -### tsConfig - -The name of the TypeScript configuration file. - -### vendorSourceMap - -Resolve vendor packages sourcemaps. - -### watch - -Run build when files change. - -### webWorkerTsConfig - -TypeScript configuration for Web Worker modules. diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/workspace-generator.md b/nx-dev/nx-dev/public/documentation/generated/cli/workspace-generator.md deleted file mode 100644 index fb0368410b..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/workspace-generator.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: 'workspace-generator - CLI command' -description: 'Runs a workspace generator from the tools/generators directory' ---- - -# workspace-generator - -Runs a workspace generator from the tools/generators directory - -## Usage - -```bash -nx workspace-generator -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -## Options - -### help - -Show help - -### list-generators - -List the available workspace-generators - -### name - -The name of your generator` - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/cli/workspace-lint.md b/nx-dev/nx-dev/public/documentation/generated/cli/workspace-lint.md deleted file mode 100644 index 385120671e..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/cli/workspace-lint.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: 'workspace-lint - CLI command' -description: 'Lint nx specific workspace files (nx.json, workspace.json), checks if your configuration and your source code are in sync. This command identifies projects with no files in the configured project root folder, as well as files that are not part of any projects in the workspace. Note: To exclude files from this lint rule, you can add them to the `.nxignore` file.' ---- - -# workspace-lint - -Lint nx specific workspace files (nx.json, workspace.json), checks if your configuration and your source code are in sync. This command identifies projects with no files in the configured project root folder, as well as files that are not part of any projects in the workspace. Note: To exclude files from this lint rule, you can add them to the `.nxignore` file. - -## Usage - -```bash -nx workspace-lint -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -## Options - -### help - -Show help - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/generated/executors.json b/nx-dev/nx-dev/public/documentation/generated/executors.json deleted file mode 100644 index d935d32a41..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/executors.json +++ /dev/null @@ -1,15 +0,0 @@ -[ - "angular", - "cypress", - "detox", - "jest", - "js", - "linter", - "next", - "node", - "nx-plugin", - "react-native", - "storybook", - "web", - "workspace" -] diff --git a/nx-dev/nx-dev/public/documentation/generated/generators.json b/nx-dev/nx-dev/public/documentation/generated/generators.json deleted file mode 100644 index 0605d7e687..0000000000 --- a/nx-dev/nx-dev/public/documentation/generated/generators.json +++ /dev/null @@ -1,18 +0,0 @@ -[ - "angular", - "cypress", - "detox", - "express", - "jest", - "js", - "linter", - "nest", - "next", - "node", - "nx-plugin", - "react", - "react-native", - "storybook", - "web", - "workspace" -] diff --git a/nx-dev/nx-dev/public/documentation/map.json b/nx-dev/nx-dev/public/documentation/map.json deleted file mode 100644 index 874378e68f..0000000000 --- a/nx-dev/nx-dev/public/documentation/map.json +++ /dev/null @@ -1,1581 +0,0 @@ -[ - { - "name": "default", - "id": "default", - "itemList": [ - { - "name": "Getting Started", - "id": "getting-started", - "itemList": [ - { - "name": "Intro to Nx", - "id": "intro", - "file": "shared/getting-started/intro" - }, - { - "name": "Nx Setup", - "id": "nx-setup", - "file": "shared/getting-started/nx-setup" - }, - { - "name": "Nx Without Plugins", - "id": "nx-core", - "file": "shared/nx-core" - }, - { - "name": "Nx and TypeScript", - "id": "nx-and-typescript", - "file": "shared/guides/nx-and-ts" - }, - { - "name": "Nx and React", - "id": "nx-and-react", - "file": "shared/getting-started/nx-and-react" - }, - { - "name": "Nx and Angular", - "id": "nx-and-angular", - "file": "shared/getting-started/nx-and-angular" - } - ] - }, - { - "name": "Configuration Choices", - "id": "configuration", - "itemList": [ - { - "name": "package.json and nx.json", - "id": "packagejson", - "file": "shared/configuration/packagejson" - }, - { - "name": "project.json and nx.json", - "id": "projectjson", - "file": "shared/configuration/projectjson" - } - ] - }, - { - "name": "Using Nx", - "id": "using-nx", - "itemList": [ - { - "name": "Nx CLI", - "id": "nx-cli", - "file": "shared/using-nx/nx-cli" - }, - { - "name": "Nx Editor Plugins", - "id": "console", - "file": "shared/console" - }, - { - "name": "Mental Model", - "id": "mental-model", - "file": "shared/mental-model" - }, - { - "name": "Computation Caching", - "id": "caching", - "file": "shared/using-nx/caching" - }, - { - "name": "Distributed Task Execution", - "id": "dte", - "file": "shared/using-nx/dte" - }, - { - "name": "Affected", - "id": "affected", - "file": "shared/using-nx/affected" - }, - { - "name": "Nx Plugins and Devkit", - "id": "nx-devkit", - "file": "shared/devkit-and-nx-plugins" - }, - { - "name": "CI Setup", - "id": "ci-overview", - "file": "shared/ci-overview" - }, - { - "name": "Updating Nx", - "id": "updating-nx", - "file": "shared/update" - } - ] - }, - { - "name": "Migration", - "id": "migration", - "itemList": [ - { - "name": "From CRA", - "id": "migration-cra", - "file": "shared/migration/migration-cra" - }, - { - "name": "Lerna/Yarn/PNPM", - "id": "adding-to-monorepo", - "file": "shared/migration/adding-to-monorepo" - }, - { - "name": "From Angular CLI", - "id": "migration-angular", - "file": "shared/migration/migration-angular" - }, - { - "name": "From AngularJS", - "id": "migration-angularjs", - "file": "shared/migration/migration-angularjs" - }, - { - "name": "Preserving Git Histories", - "id": "preserving-git-histories", - "file": "shared/migration/preserving-git-histories" - }, - { - "name": "Manual migration", - "id": "manual", - "file": "shared/migration/manual" - } - ] - }, - { - "name": "React Tutorial", - "id": "react-tutorial", - "itemList": [ - { - "name": "1 - Create Application", - "id": "01-create-application", - "file": "shared/react-tutorial/01-create-application" - }, - { - "name": "2 - Add E2E Test", - "id": "02-add-e2e-test", - "file": "shared/react-tutorial/02-add-e2e-test" - }, - { - "name": "3 - Display Todos", - "id": "03-display-todos", - "file": "shared/react-tutorial/03-display-todos" - }, - { - "name": "4 - Connect to API", - "id": "04-connect-to-api", - "file": "shared/react-tutorial/04-connect-to-api" - }, - { - "name": "5 - Add Node Application", - "id": "05-add-node-app", - "file": "shared/react-tutorial/05-add-node-app" - }, - { - "name": "6 - Proxy Configuration", - "id": "06-proxy", - "file": "shared/react-tutorial/06-proxy" - }, - { - "name": "7 - Share Code", - "id": "07-share-code", - "file": "shared/react-tutorial/07-share-code" - }, - { - "name": "8 - Create Libraries", - "id": "08-create-libs", - "file": "shared/react-tutorial/08-create-libs" - }, - { - "name": "9 - Project Graph", - "id": "09-dep-graph", - "file": "shared/react-tutorial/09-dep-graph" - }, - { - "name": "10 - Use Computation Caching", - "id": "10-computation-caching", - "file": "shared/react-tutorial/10-computation-caching" - }, - { - "name": "11 - Test Affected Projects", - "id": "11-test-affected-projects", - "file": "shared/react-tutorial/11-test-affected-projects" - }, - { - "name": "12 - Summary", - "id": "12-summary", - "file": "shared/react-tutorial/12-summary" - } - ] - }, - { - "name": "Angular Tutorial", - "id": "angular-tutorial", - "itemList": [ - { - "name": "1 - Create Application", - "id": "01-create-application", - "file": "shared/angular-tutorial/01-create-application" - }, - { - "name": "2 - Add E2E Test", - "id": "02-add-e2e-test", - "file": "shared/angular-tutorial/02-add-e2e-test" - }, - { - "name": "3 - Display Todos", - "id": "03-display-todos", - "file": "shared/angular-tutorial/03-display-todos" - }, - { - "name": "4 - Connect to API", - "id": "04-connect-to-api", - "file": "shared/angular-tutorial/04-connect-to-api" - }, - { - "name": "5 - Add Node Application", - "id": "05-add-node-app", - "file": "shared/angular-tutorial/05-add-node-app" - }, - { - "name": "6 - Proxy Configuration", - "id": "06-proxy", - "file": "shared/angular-tutorial/06-proxy" - }, - { - "name": "7 - Share Code", - "id": "07-share-code", - "file": "shared/angular-tutorial/07-share-code" - }, - { - "name": "8 - Create Libraries", - "id": "08-create-libs", - "file": "shared/angular-tutorial/08-create-libs" - }, - { - "name": "9 - Project Graph", - "id": "09-dep-graph", - "file": "shared/angular-tutorial/09-dep-graph" - }, - { - "name": "10 - Use Computation Caching", - "id": "10-computation-caching", - "file": "shared/angular-tutorial/10-computation-caching" - }, - { - "name": "11 - Test Affected Projects", - "id": "11-test-affected-projects", - "file": "shared/angular-tutorial/11-test-affected-projects" - }, - { - "name": "12 - Summary", - "id": "12-summary", - "file": "shared/angular-tutorial/12-summary" - } - ] - }, - { - "name": "Node Tutorial", - "id": "node-tutorial", - "itemList": [ - { - "name": "1 - Create Application", - "id": "01-create-application", - "file": "shared/node-tutorial/01-create-application" - }, - { - "name": "2 - Display Todos", - "id": "02-display-todos", - "file": "shared/node-tutorial/02-display-todos" - }, - { - "name": "3 - Share Code", - "id": "03-share-code", - "file": "shared/node-tutorial/03-share-code" - }, - { - "name": "4 - Create Libraries", - "id": "04-create-libs", - "file": "shared/node-tutorial/04-create-libs" - }, - { - "name": "5 - Project Graph", - "id": "05-dep-graph", - "file": "shared/node-tutorial/05-dep-graph" - }, - { - "name": "6 - Use Computation Caching", - "id": "06-computation-caching", - "file": "shared/node-tutorial/06-computation-caching" - }, - { - "name": "7 - Test Affected Projects", - "id": "07-test-affected-projects", - "file": "shared/node-tutorial/07-test-affected-projects" - }, - { - "name": "8 - Summary", - "id": "08-summary", - "file": "shared/node-tutorial/08-summary" - } - ] - }, - - { - "name": "CLI", - "id": "cli", - "itemList": [ - { - "name": "generate", - "id": "generate", - "file": "generated/cli/generate" - }, - { - "name": "serve", - "id": "serve", - "file": "generated/cli/serve" - }, - { - "name": "build", - "id": "build", - "file": "generated/cli/build" - }, - { - "name": "test", - "id": "test", - "file": "generated/cli/test" - }, - { - "name": "lint", - "id": "lint", - "file": "generated/cli/lint" - }, - { - "name": "e2e", - "id": "e2e", - "file": "generated/cli/e2e" - }, - { - "name": "run", - "id": "run", - "file": "generated/cli/run" - }, - { - "name": "daemon", - "id": "daemon", - "file": "generated/cli/daemon" - }, - { - "name": "graph", - "id": "dep-graph", - "file": "generated/cli/graph" - }, - { - "name": "run-many", - "id": "run-many", - "file": "generated/cli/run-many" - }, - { - "name": "affected", - "id": "affected", - "file": "generated/cli/affected" - }, - { - "name": "affected:build", - "id": "affected-build", - "file": "generated/cli/affected-build" - }, - { - "name": "affected:test", - "id": "affected-test", - "file": "generated/cli/affected-test" - }, - { - "name": "affected:lint", - "id": "affected-lint", - "file": "generated/cli/affected-lint" - }, - { - "name": "affected:e2e", - "id": "affected-e2e", - "file": "generated/cli/affected-e2e" - }, - { - "name": "affected:graph", - "id": "affected-dep-graph", - "file": "generated/cli/affected-graph" - }, - { - "name": "affected:apps", - "id": "affected-apps", - "file": "generated/cli/affected-apps" - }, - { - "name": "affected:libs", - "id": "affected-libs", - "file": "generated/cli/affected-libs" - }, - { - "name": "print-affected", - "id": "print-affected", - "file": "generated/cli/print-affected" - }, - { - "name": "format:check", - "id": "format-check", - "file": "generated/cli/format-check" - }, - { - "name": "format:write", - "id": "format-write", - "file": "generated/cli/format-write" - }, - { - "name": "migrate", - "id": "migrate", - "file": "generated/cli/migrate" - }, - { - "name": "report", - "id": "report", - "file": "generated/cli/report" - }, - { - "name": "list", - "id": "list", - "file": "generated/cli/list" - }, - { - "name": "workspace-lint", - "id": "workspace-lint", - "file": "generated/cli/workspace-lint" - }, - { - "name": "workspace-generator", - "id": "workspace-generator", - "file": "generated/cli/workspace-generator" - }, - { - "name": "connect-to-nx-cloud", - "id": "connect-to-nx-cloud", - "file": "generated/cli/connect-to-nx-cloud" - }, - { - "name": "reset", - "id": "reset", - "file": "generated/cli/reset" - } - ] - }, - { - "name": "Workspace", - "id": "workspace", - "itemList": [ - { - "id": "nrwl-workspace-overview", - "name": "Overview", - "searchResultsName": "@nrwl/workspace Overview", - "file": "shared/workspace-plugin" - }, - { - "name": "library generator", - "id": "library", - "file": "generated/api-workspace/generators/library" - }, - { - "name": "npm-package generator", - "id": "npm-package", - "file": "generated/api-workspace/generators/npm-package" - }, - { - "name": "move generator", - "id": "move", - "file": "generated/api-workspace/generators/move" - }, - { - "name": "remove generator", - "id": "remove", - "file": "generated/api-workspace/generators/remove" - }, - { - "name": "run-commands generator", - "id": "run-commands-generator", - "file": "generated/api-workspace/generators/run-commands" - }, - { - "name": "workspace-generator generator", - "id": "workspace-generator", - "file": "generated/api-workspace/generators/workspace-generator" - }, - { - "name": "convert-to-nx-project generator", - "id": "convert-to-nx-project-generator", - "file": "generated/api-workspace/generators/convert-to-nx-project" - }, - { - "name": "run-commands executor", - "id": "run-commands-executor", - "file": "generated/api-workspace/executors/run-commands" - }, - { - "name": "run-script executor", - "id": "run-script", - "file": "generated/api-workspace/executors/run-script" - } - ] - }, - { - "name": "js", - "id": "js", - "itemList": [ - { - "name": "Overview", - "id": "overview", - "searchResultsName": "@nrwl/js Overview", - "file": "shared/js-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-js/generators/application" - }, - { - "name": "library generator", - "id": "library", - "file": "generated/api-js/generators/library" - }, - { - "name": "convert-to-swc generator", - "id": "convert-to-swc", - "file": "generated/api-js/generators/convert-to-swc" - }, - { - "name": "node executor", - "id": "node", - "file": "generated/api-js/executors/node" - }, - { - "name": "tsc executor", - "id": "tsc", - "file": "generated/api-js/executors/tsc" - }, - { - "name": "swc executor", - "id": "swc", - "file": "generated/api-js/executors/swc" - } - ] - }, - { - "name": "web", - "id": "web", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/web Overview", - "file": "shared/web-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-web/generators/application" - }, - { - "name": "build executor", - "id": "build", - "file": "generated/api-web/executors/webpack" - }, - { - "name": "dev-server executor", - "id": "dev-server", - "file": "generated/api-web/executors/dev-server" - }, - { - "name": "file-server executor", - "id": "file-server", - "file": "generated/api-web/executors/file-server" - }, - { - "name": "package executor", - "id": "package", - "file": "generated/api-web/executors/rollup" - } - ] - }, - { - "name": "angular", - "id": "angular", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/angular Overview", - "file": "shared/angular-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-angular/generators/application" - }, - { - "name": "convert-tslint-to-eslint", - "id": "convert-tslint-to-eslint", - "file": "generated/api-angular/generators/convert-tslint-to-eslint" - }, - { - "name": "downgrade-module generator", - "id": "downgrade-module", - "file": "generated/api-angular/generators/downgrade-module" - }, - { - "name": "karma generator", - "id": "karma", - "file": "generated/api-angular/generators/karma" - }, - { - "name": "karma-project generator", - "id": "karma-project", - "file": "generated/api-angular/generators/karma-project" - }, - { - "name": "library generator", - "id": "library", - "file": "generated/api-angular/generators/library" - }, - { - "name": "library-secondary-entry-point generator", - "id": "library-secondary-entry-point", - "file": "generated/api-angular/generators/library-secondary-entry-point" - }, - { - "name": "move generator", - "id": "move", - "file": "generated/api-angular/generators/move" - }, - { - "name": "ngrx generator", - "id": "ngrx", - "file": "generated/api-angular/generators/ngrx" - }, - { - "name": "scam generator", - "id": "scam", - "file": "generated/api-angular/generators/scam" - }, - { - "name": "scam-directive generator", - "id": "scam-directive", - "file": "generated/api-angular/generators/scam-directive" - }, - { - "name": "scam-pipe generator", - "id": "scam-pipe", - "file": "generated/api-angular/generators/scam-pipe" - }, - { - "name": "setup-mfe generator", - "id": "setup-mfe", - "file": "generated/api-angular/generators/setup-mfe" - }, - { - "name": "setup-tailwind generator", - "id": "setup-tailwind", - "file": "generated/api-angular/generators/setup-tailwind" - }, - { - "name": "stories generator", - "id": "stories", - "file": "generated/api-angular/generators/stories" - }, - { - "name": "storybook-configuration generator", - "id": "storybook-configuration", - "file": "generated/api-angular/generators/storybook-configuration" - }, - { - "name": "storybook-migrate-defaults-5-to-6 generator", - "id": "storybook-migrate-defaults-5-to-6", - "file": "generated/api-angular/generators/storybook-migrate-defaults-5-to-6" - }, - { - "name": "storybook-migrate-stories-to-6-2 generator", - "id": "storybook-migrate-stories-to-6-2", - "file": "generated/api-angular/generators/storybook-migrate-stories-to-6-2" - }, - { - "name": "upgrade-module generator", - "id": "upgrade-module", - "file": "generated/api-angular/generators/upgrade-module" - }, - { - "name": "web-worker generator", - "id": "web-worker", - "file": "generated/api-angular/generators/web-worker" - }, - { - "name": "delegate-build executor", - "id": "delegate-build", - "file": "generated/api-angular/executors/delegate-build" - }, - { - "name": "ng packagr lite executor", - "id": "ng-packagr-lite", - "file": "generated/api-angular/executors/ng-packagr-lite" - }, - { - "name": "package executor", - "id": "package", - "file": "generated/api-angular/executors/package" - }, - { - "name": "webpack-browser executor", - "id": "webpack-browser", - "file": "generated/api-angular/executors/webpack-browser" - }, - { - "name": "webpack-server executor", - "id": "webpack-server", - "file": "generated/api-angular/executors/webpack-server" - } - ] - }, - { - "name": "react", - "id": "react", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/react Overview", - "file": "shared/react-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-react/generators/application" - }, - { - "name": "component generator", - "id": "component", - "file": "generated/api-react/generators/component" - }, - { - "name": "component-cypress-spec generator", - "id": "component-cypress-spec", - "file": "generated/api-react/generators/component-cypress-spec" - }, - { - "name": "component-story generator", - "id": "component-story", - "file": "generated/api-react/generators/component-story" - }, - { - "name": "library generator", - "id": "library", - "file": "generated/api-react/generators/library" - }, - { - "name": "redux generator", - "id": "redux", - "file": "generated/api-react/generators/redux" - }, - { - "name": "stories generator", - "id": "stories", - "file": "generated/api-react/generators/stories" - }, - { - "name": "storybook-configuration generator", - "id": "storybook-configuration", - "file": "generated/api-react/generators/storybook-configuration" - }, - { - "name": "storybook-migrate-defaults-5-to-6 generator", - "id": "storybook-migrate-defaults-5-to-6", - "file": "generated/api-react/generators/storybook-migrate-defaults-5-to-6" - }, - { - "name": "hook generator", - "id": "hook", - "file": "generated/api-react/generators/hook" - } - ] - }, - { - "name": "jest", - "id": "jest", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/jest Overview", - "file": "shared/jest-plugin" - }, - { - "name": "jest executor", - "id": "jest", - "file": "generated/api-jest/executors/jest" - } - ] - }, - { - "name": "cypress", - "id": "cypress", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/cypress Overview", - "file": "shared/cypress-plugin" - }, - { - "name": "cypress executor", - "id": "cypress", - "file": "generated/api-cypress/executors/cypress" - }, - { - "name": "cypress-project generator", - "id": "cypress-project", - "file": "generated/api-cypress/generators/cypress-project" - } - ] - }, - { - "name": "storybook", - "id": "storybook", - "itemList": [ - { - "id": "overview-react", - "name": "Overview (React)", - "searchResultsName": "@nrwl/storybook Overview (React)", - "file": "shared/guides/storybook/plugin-react" - }, - { - "id": "overview-angular", - "name": "Overview (Angular)", - "searchResultsName": "@nrwl/storybook Overview (Angular)", - "file": "shared/guides/storybook/plugin-angular" - }, - { - "id": "migrate-webpack-final-react", - "name": "Migrate to the Nrwl React Storybook Preset", - "file": "shared/guides/storybook/migrate-webpack-final-react" - }, - { - "id": "migrate-webpack-final-angular", - "name": "Migrate to the Nrwl Angular Storybook Preset", - "file": "shared/guides/storybook/migrate-webpack-final-angular" - }, - { - "id": "upgrade-storybook-v6-react", - "name": "Upgrading to Storybook 6 (React)", - "file": "shared/guides/storybook/storybook-v6-react" - }, - { - "id": "upgrade-storybook-v6-angular", - "name": "Upgrading to Storybook 6 (Angular)", - "file": "shared/guides/storybook/storybook-v6-angular" - }, - { - "id": "storybook-composition-setup", - "name": "Setting up Storybook Composition with Nx", - "file": "shared/guides/storybook/storybook-composition-setup" - }, - { - "name": "configuration generator", - "id": "configuration", - "file": "generated/api-storybook/generators/configuration" - }, - { - "name": "cypress-project generator", - "id": "cypress-project", - "file": "generated/api-storybook/generators/cypress-project" - }, - { - "name": "migrate-defaults-5-to-6 generator", - "id": "migrate-defaults-5-to-6", - "file": "generated/api-storybook/generators/migrate-defaults-5-to-6" - }, - { - "name": "migrate-stories-to-6-2 generator", - "id": "migrate-stories-to-6-2", - "file": "generated/api-storybook/generators/migrate-stories-to-6-2" - }, - { - "id": "executors", - "name": "Executors / Builders", - "itemList": [ - { - "name": "build", - "id": "build", - "file": "generated/api-storybook/executors/build" - }, - { - "name": "storybook", - "id": "storybook", - "file": "generated/api-storybook/executors/storybook" - } - ] - } - ] - }, - { - "name": "linter", - "id": "linter", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/linter Overview", - "file": "shared/linter-plugin" - }, - { - "id": "eslint-plugin-nx", - "name": "eslint-plugin-nx", - "searchResultsName": "@nrwl/eslint-plugin-nx Overview", - "file": "shared/eslint-plugin-nx" - }, - { - "name": "eslint executor", - "id": "eslint", - "file": "generated/api-linter/executors/eslint" - }, - { - "name": "lint executor", - "id": "lint", - "file": "generated/api-linter/executors/lint" - }, - { - "name": "workspace-rule generator", - "id": "workspace-rule", - "file": "generated/api-linter/generators/workspace-rule" - } - ] - }, - { - "name": "node", - "id": "node", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/node Overview", - "file": "shared/node-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-node/generators/application" - }, - { - "name": "library generator", - "id": "library", - "file": "generated/api-node/generators/library" - }, - { - "name": "build executor", - "id": "build", - "file": "generated/api-node/executors/build" - }, - { - "name": "execute executor", - "id": "execute", - "file": "generated/api-node/executors/execute" - }, - { - "name": "package executor", - "id": "package", - "file": "generated/api-node/executors/package" - } - ] - }, - { - "name": "express", - "id": "express", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/express Overview", - "file": "shared/express-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-express/generators/application" - } - ] - }, - { - "name": "nest", - "id": "nest", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/nest Overview", - "file": "shared/nest-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-nest/generators/application" - }, - { - "name": "class generator", - "id": "class", - "file": "generated/api-nest/generators/class" - }, - { - "name": "controller generator", - "id": "controller", - "file": "generated/api-nest/generators/controller" - }, - { - "name": "decorator generator", - "id": "decorator", - "file": "generated/api-nest/generators/decorator" - }, - { - "name": "filter generator", - "id": "filter", - "file": "generated/api-nest/generators/filter" - }, - { - "name": "gateway generator", - "id": "gateway", - "file": "generated/api-nest/generators/gateway" - }, - { - "name": "guard generator", - "id": "guard", - "file": "generated/api-nest/generators/guard" - }, - { - "name": "interceptor generator", - "id": "interceptor", - "file": "generated/api-nest/generators/interceptor" - }, - { - "name": "interface generator", - "id": "interface", - "file": "generated/api-nest/generators/interface" - }, - { - "name": "library generator", - "id": "library", - "file": "generated/api-nest/generators/library" - }, - { - "name": "middleware generator", - "id": "middleware", - "file": "generated/api-nest/generators/middleware" - }, - { - "name": "module generator", - "id": "module", - "file": "generated/api-nest/generators/module" - }, - { - "name": "pipe generator", - "id": "pipe", - "file": "generated/api-nest/generators/pipe" - }, - { - "name": "provider generator", - "id": "provider", - "file": "generated/api-nest/generators/provider" - }, - { - "name": "resolver generator", - "id": "resolver", - "file": "generated/api-nest/generators/resolver" - }, - { - "name": "resource generator", - "id": "resource", - "file": "generated/api-nest/generators/resource" - }, - { - "name": "service generator", - "id": "service", - "file": "generated/api-nest/generators/service" - }, - { - "name": "convert-tslint-to-eslint", - "id": "convert-tslint-to-eslint", - "file": "generated/api-nest/generators/convert-tslint-to-eslint" - } - ] - }, - { - "name": "next", - "id": "next", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/next Overview", - "file": "shared/next-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-next/generators/application" - }, - { - "name": "component generator", - "id": "component", - "file": "generated/api-next/generators/component" - }, - { - "name": "page generator", - "id": "page", - "file": "generated/api-next/generators/page" - }, - { - "name": "build executor", - "id": "build", - "file": "generated/api-next/executors/build" - }, - { - "name": "server executor", - "id": "server", - "file": "generated/api-next/executors/server" - }, - { - "name": "export executor", - "id": "export", - "file": "generated/api-next/executors/export" - } - ] - }, - { - "name": "detox", - "id": "detox", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/detox Overview", - "file": "shared/detox-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-detox/generators/application" - }, - { - "name": "build executor", - "id": "build", - "file": "generated/api-detox/executors/build" - }, - { - "name": "test executor", - "id": "test", - "file": "generated/api-detox/executors/test" - } - ] - }, - { - "name": "react native", - "id": "react-native", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/react-native Overview", - "file": "shared/react-native-plugin" - }, - { - "name": "application generator", - "id": "application", - "file": "generated/api-react-native/generators/application" - }, - { - "name": "component generator", - "id": "component", - "file": "generated/api-react-native/generators/component" - }, - { - "name": "library generator", - "id": "library", - "file": "generated/api-react-native/generators/library" - }, - { - "name": "build android executor", - "id": "build-android", - "file": "generated/api-react-native/executors/build-android" - }, - { - "name": "bundle executor", - "id": "bundle", - "file": "generated/api-react-native/executors/bundle" - }, - { - "name": "ensure symlink executor", - "id": "ensure-symlink", - "file": "generated/api-react-native/executors/ensure-symlink" - }, - { - "name": "run android executor", - "id": "run-android", - "file": "generated/api-react-native/executors/run-android" - }, - { - "name": "run ios executor", - "id": "run-ios", - "file": "generated/api-react-native/executors/run-ios" - }, - { - "name": "start executor", - "id": "start", - "file": "generated/api-react-native/executors/start" - }, - { - "name": "sync deps executor", - "id": "sync-deps", - "file": "generated/api-react-native/executors/sync-deps" - } - ] - }, - { - "name": "Nx Plugin", - "id": "nx-plugin", - "itemList": [ - { - "id": "overview", - "name": "Overview", - "searchResultsName": "@nrwl/nx-plugin Overview", - "file": "shared/nx-plugin" - }, - { - "name": "executor generator", - "id": "executor", - "file": "generated/api-nx-plugin/generators/executor" - }, - { - "name": "migration generator", - "id": "migration", - "file": "generated/api-nx-plugin/generators/migration" - }, - { - "name": "plugin generator", - "id": "plugin", - "file": "generated/api-nx-plugin/generators/plugin" - }, - { - "name": "generator generator", - "id": "schematic", - "file": "generated/api-nx-plugin/generators/generator" - }, - { - "name": "e2e executor", - "id": "e2e", - "file": "generated/api-nx-plugin/executors/e2e" - } - ] - }, - { - "name": "Nx Devkit", - "id": "nx-devkit", - "itemList": [ - { - "id": "index", - "name": "Overview", - "searchResultsName": "Nx Devkit", - "file": "generated/api-nx-devkit/index" - }, - { - "id": "ngcli_adapter", - "name": "Ng CLI Adapter", - "searchResultsName": "Ng CLI Adapter", - "file": "generated/api-nx-devkit/ngcli_adapter" - } - ] - }, - { - "name": "Executors / Builders", - "id": "executors", - "itemList": [ - { - "name": "Using Executors / Builders", - "id": "using-builders", - "file": "shared/using-executors" - }, - { - "name": "Running Custom Commands", - "id": "run-commands-builder", - "file": "shared/running-custom-commands" - }, - { - "name": "Creating Custom Builders", - "id": "creating-custom-builders", - "file": "shared/tools-workspace-builders" - } - ] - }, - { - "name": "Generators", - "id": "generators", - "itemList": [ - { - "name": "Using Generators", - "id": "using-schematics", - "file": "shared/generators/using-generators" - }, - { - "name": "Workspace Generators", - "id": "workspace-generators", - "file": "shared/generators/workspace-generators" - }, - { - "name": "Composing Generators", - "id": "composing-generators", - "file": "shared/generators/composing-generators" - }, - { - "name": "Generator Options", - "id": "generator-options", - "file": "shared/generators/generator-options" - }, - { - "name": "Creating Files", - "id": "creating-files", - "file": "shared/generators/creating-files" - }, - { - "name": "Modifying Files", - "id": "modifying-files", - "file": "shared/generators/modifying-files" - } - ] - }, - { - "name": "Workspace Structure", - "id": "structure", - "itemList": [ - { - "name": "Creating Libraries", - "id": "creating-libraries", - "file": "shared/workspace/creating-libraries" - }, - { - "name": "Library Types", - "id": "library-types", - "file": "shared/workspace/library-types" - }, - { - "name": "Grouping Libraries", - "id": "grouping-libraries", - "file": "shared/workspace/grouping-libraries" - }, - { - "name": "Buildable and Publishable Libraries", - "id": "buildable-and-publishable-libraries", - "file": "shared/workspace/buildable-and-publishable-libraries" - }, - { - "name": "Using Tags", - "id": "monorepo-tags", - "file": "shared/monorepo-tags" - }, - { - "name": "Project Graph", - "id": "dependency-graph", - "file": "shared/workspace/structure/dependency-graph" - }, - { - "name": "Extending the Project Graph", - "id": "project-graph-plugins", - "file": "shared/workspace/project-graph-plugins" - } - ] - }, - { - "name": "CI", - "id": "ci", - "itemList": [ - { - "name": "Setting up Azure Pipelines", - "id": "monorepo-ci-azure", - "file": "shared/monorepo-ci-azure" - }, - { - "name": "Setting up CircleCI", - "id": "monorepo-ci-circle-ci", - "file": "shared/monorepo-ci-circle-ci" - }, - { - "name": "Setting up GitHub Actions", - "id": "monorepo-ci-github-actions", - "file": "shared/monorepo-ci-github-actions" - }, - { - "name": "Setting up Jenkins", - "id": "monorepo-ci-jenkins", - "file": "shared/monorepo-ci-jenkins" - }, - { - "name": "Setting up GitLab", - "id": "monorepo-ci-gitlab", - "file": "shared/monorepo-ci-gitlab" - }, - { - "name": "Distributed CI", - "id": "distributed-builds", - "file": "shared/distributed-builds" - }, - { - "name": "Incremental Builds", - "id": "incremental-builds", - "file": "shared/incremental-builds" - }, - { - "name": "Setup incremental builds for Angular applications", - "id": "setup-incremental-builds-angular", - "file": "shared/guides/setup-incremental-builds-angular" - } - ] - }, - { - "name": "Guides", - "id": "guides", - "itemList": [ - { - "name": "Nx and Lerna/Yarn", - "id": "lerna-and-nx", - "file": "shared/guides/lerna-and-nx" - }, - { - "name": "Nx and Turborepo", - "id": "turbo-and-nx", - "file": "shared/guides/turbo-and-nx" - }, - { - "name": "Monorepos", - "id": "why-monorepos", - "file": "shared/guides/why-monorepos" - }, - { - "name": "Adding Images, Fonts, and Files", - "id": "adding-assets-react", - "file": "shared/guides/adding-assets" - }, - { - "name": "Using Environment Variables", - "id": "environment-variables", - "file": "shared/guides/environment-variables" - }, - { - "name": "Using Nx at Enterprises", - "id": "monorepo-nx-enterprise", - "file": "shared/monorepo-nx-enterprise" - }, - { - "name": "Profiling Build Performance", - "id": "performance-profiling", - "file": "shared/guides/performance-profiling" - }, - { - "name": "Using ESLint in Nx Workspaces", - "id": "eslint", - "file": "shared/eslint" - }, - { - "name": "Nx Daemon", - "id": "nx-daemon", - "file": "shared/daemon" - }, - { - "name": "JavaScript and TypeScript", - "id": "js-and-ts", - "file": "shared/guides/js-and-ts" - }, - { - "name": "Configuring Browser Support", - "id": "browser-support", - "file": "shared/guides/browser-support" - }, - { - "name": "React Native with Nx", - "id": "react-native", - "file": "shared/guides/react-native" - }, - { - "name": "Deploying Next.js applications to Vercel", - "id": "deploy-nextjs-to-vercel", - "file": "shared/guides/deploy-nextjs-to-vercel" - }, - { - "name": "Webpack 5 Migration", - "id": "webpack-5", - "file": "shared/guides/webpack-5" - }, - { - "name": "Using Tailwind CSS in React", - "id": "using-tailwind-css-in-react", - "file": "shared/guides/using-tailwind-css-in-react" - }, - { - "name": "Using Tailwind CSS with Angular projects", - "id": "using-tailwind-css-with-angular-projects", - "file": "shared/guides/using-tailwind-css-with-angular-projects" - }, - { - "name": "Using NgRx", - "id": "misc-ngrx", - "file": "shared/guides/misc-ngrx" - }, - { - "name": "Using DataPersistence", - "id": "misc-data-persistence", - "file": "shared/guides/misc-data-persistence" - }, - { - "name": "Nx Devkit and Angular Devkit", - "id": "nx-devkit-angular-devkit", - "file": "shared/guides/nx-devkit-angular-devkit" - }, - { - "name": "Setup MFE with Angular and Nx", - "id": "setup-mfe-with-angular", - "file": "shared/guides/setup-mfe-with-angular" - } - ] - }, - { - "name": "Examples", - "id": "examples", - "itemList": [ - { - "name": "Nx Micro-Frontend Example", - "id": "nx-examples", - "file": "shared/examples/nx-examples" - }, - { - "name": "Powering Up React Development With Nx", - "id": "react-nx", - "file": "shared/examples/react-nx" - }, - { - "name": "Using Apollo GraphQL", - "id": "apollo-react", - "file": "shared/examples/apollo-react" - }, - { - "name": "Large Repo and Caching", - "id": "caching", - "file": "shared/examples/caching" - }, - { - "name": "Large Repo and DTE", - "id": "dte", - "file": "shared/examples/dte" - } - ] - } - ] - } -] diff --git a/nx-dev/nx-dev/public/documentation/project.json b/nx-dev/nx-dev/public/documentation/project.json deleted file mode 100644 index 51750ffe28..0000000000 --- a/nx-dev/nx-dev/public/documentation/project.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "root": "docs", - "sourceRoot": "docs", - "projectType": "library", - "tags": ["scope:nx-dev"] -} diff --git a/nx-dev/nx-dev/public/documentation/shared/affected.png b/nx-dev/nx-dev/public/documentation/shared/affected.png deleted file mode 100644 index d98750ceb6..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/affected.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/all-cache-inputs.png b/nx-dev/nx-dev/public/documentation/shared/all-cache-inputs.png deleted file mode 100644 index e7e5bd839e..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/all-cache-inputs.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-logo.png b/nx-dev/nx-dev/public/documentation/shared/angular-logo.png deleted file mode 100644 index c510293918..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/angular-logo.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-plugin.md b/nx-dev/nx-dev/public/documentation/shared/angular-plugin.md deleted file mode 100644 index 823a44b0a3..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-plugin.md +++ /dev/null @@ -1,87 +0,0 @@ -# Angular Plugin - -![Angular logo](/shared/angular-logo.png) - -The Nx Plugin for Angular contains executors, generators, and utilities for managing Angular applications and libraries within an Nx workspace. It provides: - -- Integration with libraries such as Storybook, Jest, Cypress, Karma, and Protractor. -- Generators to help scaffold code quickly, including: - - Micro Frontends - - Libraries, both internal to your codebase and publishable to npm - - Upgrading AngularJS applications - - Single Component Application Modules (SCAMs) -- NgRx helpers. -- Utilities for automatic workspace refactoring. - -## Setting up the Angular plugin - -Adding the Angular plugin to an existing Nx workspace can be done with the following: - -```bash -yarn add -D @nrwl/angular -``` - -```bash -npm install -D @nrwl/angular -``` - -## Using the Angular Plugin - -### Generating an application - -It's straightforward to generate an Angular application: - -```bash -nx g @nrwl/angular:app appName -``` - -By default, the application will be generated with: - -- ESLint as the linter. -- Jest as the unit test runner. -- Cypress as the E2E test runner. - -We can then serve, build, test, lint, and run e2e tests on the application with the following commands: - -```bash -nx serve appName -nx build appName -nx test appName -nx lint appName -nx e2e appName -``` - -### Generating a library - -Generating an Angular library is very similar to generating an application: - -```bash -nx g @nrwl/angular:lib libName -``` - -By default, the library will be generated with: - -- ESLint as the linter. -- Jest as the unit test runner. - -We can then test and lint the library with the following commands: - -```bash -nx test libName -nx lint libName -``` - -Read more about: - -- [Creating Libraries](/structure/creating-libraries) -- [Library Types](/structure/library-types) -- [Buildable and Publishable Libraries](/structure/buildable-and-publishable-libraries) - -## More Documentation - -- [Angular Nx Tutorial](/angular-tutorial/01-create-application) -- [Setup a Micro Frontend with Angular and Nx](/guides/setup-mfe-with-angular) -- [Using NgRx](/guides/misc-ngrx) -- [Using DataPersistence](/guides/misc-data-persistence) -- [Upgrading an AngularJS application to Angular](/guides/misc-upgrade) -- [Using Tailwind CSS with Angular projects](/guides/using-tailwind-css-with-angular-projects) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/01-create-application.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/01-create-application.md deleted file mode 100644 index 891c9f1b50..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/01-create-application.md +++ /dev/null @@ -1,138 +0,0 @@ -# Angular Nx Tutorial - Step 1: Create Application - - - -In this tutorial you use Nx to build a full-stack application out of common libraries using modern technologies like Cypress and Nest. - -> This tutorial uses several Nx plugins to provide a rich dev experience. **All the plugins are optional.** [Read about using Nx Core without plugins](/getting-started/nx-core). - -## Create a new workspace - -**Start by creating a new workspace.** - -```bash -npx create-nx-workspace@latest -``` - -You then receive the following prompts in your command line: - -```bash -Workspace name (e.g., org name) myorg -What to create in the new workspace angular -Application name todos -Default stylesheet format CSS -``` - -> You can also choose to add [Nx Cloud](https://nx.app), but its not required for the tutorial. - -When asked about 'preset', select `angular`, and `todos` for the app name. - -```treeview -myorg/ -├── apps/ -│ ├── todos/ -│ │ ├── src/ -│ │ │ ├── app/ -│ │ │ ├── assets/ -│ │ │ ├── environments/ -│ │ │ ├── favicon.ico -│ │ │ ├── index.html -│ │ │ ├── main.ts -│ │ │ ├── polyfills.ts -│ │ │ ├── styles.scss -│ │ │ └── test-setup.ts -│ │ ├── .browserslistrc -│ │ ├── .eslintrc.json -│ │ ├── jest.config.js -│ │ ├── project.json -│ │ ├── tsconfig.app.json -│ │ ├── tsconfig.editor.json -│ │ ├── tsconfig.json -│ │ └── tsconfig.spec.json -│ └── todos-e2e/ -│ ├── src/ -│ │ ├── fixtures/ -│ │ │ └── example.json -│ │ ├── integration/ -│ │ │ └── app.spec.ts -│ │ ├── plugins/ -│ │ │ └── index.ts -│ │ └── support/ -│ │ ├── app.po.ts -│ │ ├── commands.ts -│ │ └── index.ts -│ ├── cypress.json -│ ├── project.json -│ └── tsconfig.json -├── libs/ -├── tools/ -├── .eslintrc.json -├── .prettierrc -├── angular.json -├── decorate-angular-cli.js -├── jest.config.js -├── jest.preset.js -├── nx.json -├── package.json -├── README.md -└── tsconfig.base.json -``` - -The generate command added two projects to our workspace: - -- An Angular application -- E2E tests for the Angular application - -## Serve the newly created application - -Now that the application is set up, run it locally via: - -```bash -npx nx serve todos -``` - -## Note on the Nx CLI - -If you would prefer to run using a global installation of Nx, you can run: - -```bash -nx serve todos -``` - -Depending on how your dev env is set up, the command above might result in `Command 'nx' not found`. - -To fix it, you can either install the `nx` cli globally by running: - -```bash -npm install -g nx -``` - -or - -```bash -yarn global add nx -``` - -Alternatively, you can run the local installation of Nx by prepending every command with `npx`: - -```bash -npx nx serve todos -``` - -or - -```bash -yarn nx serve todos -``` - -## Note on `nx serve` and `ng serve` - -The Nx CLI syntax is intentionally similar to the Angular CLI. The `nx serve` command -produces the same result as `ng serve`, and `nx build` produces the same results as `ng build`. However, the Nx CLI -supports advanced capabilities that aren't supported by the Angular CLI. For instance, Nx's computation cache only -works when using the Nx CLI. In other words, using `nx` instead of `ng` results in the same output, but often performs -a lot better. - -## What's Next - -- Continue to [Step 2: Add E2E Tests](/angular-tutorial/02-add-e2e-test) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/02-add-e2e-test.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/02-add-e2e-test.md deleted file mode 100644 index 58bef5d334..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/02-add-e2e-test.md +++ /dev/null @@ -1,42 +0,0 @@ -# Angular Nx Tutorial - Step 2: Add E2E Tests - - - -By default, Nx uses [Cypress](/cypress/overview) to run E2E tests. - -**Open `apps/todos-e2e/src/support/app.po.ts`.** It's a page object file that contains helpers for querying the page. - -**Add the following two helpers:** - -```typescript -export const getTodos = () => cy.get('li.todo'); -export const getAddTodoButton = () => cy.get('button#add-todo'); -``` - -**Next, update `apps/todos-e2e/src/integration/app.spec.ts`.** - -```typescript -import { getAddTodoButton, getTodos } from '../support/app.po'; - -describe('TodoApps', () => { - beforeEach(() => cy.visit('/')); - - it('should display todos', () => { - getTodos().should((t) => expect(t.length).equal(2)); - getAddTodoButton().click(); - getTodos().should((t) => expect(t.length).equal(3)); - }); -}); -``` - -This is a simple example of an E2E test, but it suffices for the purposes of this tutorial. - -If you have not done so already, stop the `npx nx serve` command and run `npx nx e2e todos-e2e --watch`. - -A UI opens. Click the button in the top right corner that says "Run 1 integration spec". Keep the E2E tests running. - -As you progress through the tutorial, you work on making these E2E tests pass. - -## What's Next - -- Continue to [Step 3: Display Todos](/angular-tutorial/03-display-todos) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/03-display-todos.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/03-display-todos.md deleted file mode 100644 index c3e46d00de..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/03-display-todos.md +++ /dev/null @@ -1,85 +0,0 @@ -# Angular Nx Tutorial - Step 3: Display Todos - - - -Great! You have a failing E2E test. Now you can make it pass! - -The best way to work with Cypress is to keep the failing E2E test running while working on the app. This helps you see the progress you are making. - -## Show todos - -**Open `apps/todos`.** If you have used Angular CLI, this should look very familiar: same layout, same module and component files. The only difference is that Nx uses Jest instead of Karma. - -To make the first assertion of the e2e test pass, update `apps/todos/src/app/app.component.ts`: - -```typescript -import { Component } from '@angular/core'; - -interface Todo { - title: string; -} - -@Component({ - selector: 'myorg-root', - templateUrl: './app.component.html', - styleUrls: ['./app.component.css'], -}) -export class AppComponent { - todos: Todo[] = [{ title: 'Todo 1' }, { title: 'Todo 2' }]; -} -``` - -and `apps/todos/src/app/app.component.html`: - -```html -

Todos

- -
    -
  • {{ t.title }}
    • -
-``` - -**Rerun the specs by clicking the button in the top right corner of the left pane.** Now the tests fail while trying to find the add todo button. - -## Add todos - -**Add the `add-todo` button with the corresponding click handler.** - -```typescript -import { Component } from '@angular/core'; - -interface Todo { - title: string; -} - -@Component({ - selector: 'myorg-root', - templateUrl: './app.component.html', - styleUrls: ['./app.component.css'], -}) -export class AppComponent { - todos: Todo[] = [{ title: 'Todo 1' }, { title: 'Todo 2' }]; - - addTodo() { - this.todos.push({ - title: `New todo ${Math.floor(Math.random() * 1000)}`, - }); - } -} -``` - -```html -

Todos

- -
    -
  • {{ t.title }}
    • -
- - -``` - -The tests should pass now. - -## What's Next - -- Continue to [Step 4: Connect to an API](/angular-tutorial/04-connect-to-api) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/04-connect-to-api.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/04-connect-to-api.md deleted file mode 100644 index bb79a5386f..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/04-connect-to-api.md +++ /dev/null @@ -1,61 +0,0 @@ -# Angular Nx Tutorial - Step 4: Connect to an API - - - -Real-world applications do not live in isolation — they need APIs to talk to. Setup your app to talk to an API. - -**Open `apps/todos/src/app/app.module.ts` to import `HttpClientModule`.** - -```typescript -import { BrowserModule } from '@angular/platform-browser'; -import { NgModule } from '@angular/core'; - -import { AppComponent } from './app.component'; -import { HttpClientModule } from '@angular/common/http'; - -@NgModule({ - declarations: [AppComponent], - imports: [BrowserModule, HttpClientModule], - providers: [], - bootstrap: [AppComponent], -}) -export class AppModule {} -``` - -**Now, use `HttpClient` in the component to get the data from the api.** - -```typescript -import { Component } from '@angular/core'; -import { HttpClient } from '@angular/common/http'; - -interface Todo { - title: string; -} - -@Component({ - selector: 'myorg-root', - templateUrl: './app.component.html', - styleUrls: ['./app.component.css'], -}) -export class AppComponent { - todos: Todo[] = []; - - constructor(private http: HttpClient) { - this.fetch(); - } - - fetch() { - this.http.get('/api/todos').subscribe((t) => (this.todos = t)); - } - - addTodo() { - this.http.post('/api/addTodo', {}).subscribe(() => { - this.fetch(); - }); - } -} -``` - -## What's Next - -- Continue to [Step 5: Add Node Application Implementing an API](/angular-tutorial/05-add-node-app) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/05-add-node-app.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/05-add-node-app.md deleted file mode 100644 index bd7cbe34be..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/05-add-node-app.md +++ /dev/null @@ -1,185 +0,0 @@ -# Angular Nx Tutorial - Step 5: Add Node Application Implementing an API - - - -The requests fail because the API has not been created yet. Using Nx you can develop node applications next to your Angular applications. You can use same commands to run and test them. You can share code between the backend and the frontend. Use this capability to implement the API service. - -## Add NestJS plugin to your workspace - -Nx is an extensible framework with plugins for many modern tools and frameworks. **To see some plugins, run `nx list`:** - -```bash -> NX Installed plugins: - - @angular-devkit/build-angular (builders) - @nrwl/angular (builders,generators) - @nrwl/cypress (builders,generators) - @nrwl/jest (builders,generators) - @nrwl/linter (builders,generators) - @nrwl/storybook (builders,generators) - @nrwl/workspace (builders,generators) - - -> NX Also available: - - @nrwl/express (executors,generators) - @nrwl/nest (executors,generators) - @nrwl/next (executors,generators) - @nrwl/node (executors,generators) - @nrwl/nx-plugin (executors,generators) - @nrwl/react (executors,generators) - @nrwl/web (executors,generators) - - -> NX Community plugins: - - nx-plugins - Nx plugin integrations with ESBuild / Vite / Snowpack / Prisma, with derived ESBuild / Snowpack / ... plugins. - @codebrew/nx-aws-cdk - An Nx plugin for aws cdk develop. - @rxap/plugin-localazy - An Nx plugin for localazy.com upload and download tasks. - ... -``` - -**Add the dependency:** - -```bash -npm install --save-dev @nrwl/nest -``` - -or - -```bash -yarn add --dev @nrwl/nest -``` - -> `@nrwl/nest` also added `@nrwl/node`. Run `nx list @nrwl/nest` and `nx list @nrwl/node` to see what those plugins provide. - -## Create a NestJS application - -**Run the following to generate a new Nest application:** - -```bash -npx nx g @nrwl/nest:app api --frontendProject=todos -``` - -Nx asks you a few questions, and, as with the Angular application, the defaults work well here. - -After this is done, you should see something like this: - -```treeview -myorg/ -├── apps/ -│ ├── todos/ -│ ├── todos-e2e/ -│ └── api/ -│ ├── src/ -│ │ ├── app/ -│ │ │ ├── app.controller.ts -│ │ │ ├── app.controller.spec.ts -│ │ │ ├── app.module.ts -│ │ │ ├── app.service.ts -│ │ │ └── app.service.spec.ts -│ │ ├── assets/ -│ │ ├── environments/ -│ │ │ ├── environment.ts -│ │ │ └── environment.prod.ts -│ │ └── main.ts -│ ├── jest.conf.js -│ ├── proxy.conf.json -│ ├── tsconfig.app.json -│ ├── tsconfig.json -│ └── tsconfig.spec.json -├── libs/ -├── tools/ -├── angular.json -├── nx.json -├── package.json -└── tsconfig.base.json -``` - -The `apps` directory is where Nx places anything you can run: frontend applications, backend applications, e2e test suites. That's why the `api` application appeared there. - -You can run: - -- `npx nx serve api` to serve the application -- `npx nx build api` to build the application -- `npx nx test api` to test the application - -**Open `apps/api/src/app/app.module.ts`.** - -```typescript -import { Module } from '@nestjs/common'; - -import { AppController } from './app.controller'; -import { AppService } from './app.service'; - -@Module({ - imports: [], - controllers: [AppController], - providers: [AppService], -}) -export class AppModule {} -``` - -We recommend using the [Nest](/nest/overview) framework when creating node applications. Nest is a powerful framework which helps develop robust node applications. You can also use Express or any node libraries with Nx. - -In this case you have an application that registers a service and a controller. Services in Nest are responsible for the business logic, and controllers are responsible for implementing Http endpoints. - -**Update `apps/api/src/app/app.service.ts`:** - -```typescript -import { Injectable } from '@nestjs/common'; - -interface Todo { - title: string; -} - -@Injectable() -export class AppService { - todos: Todo[] = [{ title: 'Todo 1' }, { title: 'Todo 2' }]; - - getData(): Todo[] { - return this.todos; - } - - addTodo() { - this.todos.push({ - title: `New todo ${Math.floor(Math.random() * 1000)}`, - }); - } -} -``` - -**Next, update the controller to invoke the service:** - -```typescript -import { Controller, Get, Post } from '@nestjs/common'; - -import { AppService } from './app.service'; - -@Controller() -export class AppController { - constructor(private readonly appService: AppService) {} - - @Get('todos') - getData() { - return this.appService.getData(); - } - - @Post('addTodo') - addTodo() { - return this.appService.addTodo(); - } -} -``` - -In a new terminal window, serve the API. - -```bash -npx nx serve api -``` - -The API starts running on port `3333`. - -## What's Next - -- Continue to [Step 6: Proxy](/angular-tutorial/06-proxy) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/06-proxy.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/06-proxy.md deleted file mode 100644 index 70c934a049..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/06-proxy.md +++ /dev/null @@ -1,48 +0,0 @@ -# Angular Nx Tutorial - Step 6: Proxy - - - -You passed `--frontendProject=todos` when creating the node application. What did that argument do? - -It created a proxy configuration that allows the Angular application to talk to the API in development. - -**To see how it works, open `apps/todos/project.json` and find the `serve` target of the todos app.** - -```json -{ - "serve": { - "executor": "@angular-devkit/build-angular:dev-server", - "configurations": { - "production": { - "browserTarget": "todos:build:production" - }, - "development": { - "browserTarget": "todos:build:development" - } - }, - "defaultConfiguration": "development", - "options": { - "proxyConfig": "apps/todos/proxy.conf.json" - } - } -} -``` - -**Note the `proxyConfig` property.** - -**Now open `apps/todos/proxy.conf.json`:** - -```json -{ - "/api": { - "target": "http://localhost:3333", - "secure": false - } -} -``` - -This configuration tells `nx serve` to forward all requests starting with `/api` to the process listening on port `3333`. - -## What's Next - -- Continue to [Step 7: Share Code](/angular-tutorial/07-share-code) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/07-share-code.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/07-share-code.md deleted file mode 100644 index 61e1959edb..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/07-share-code.md +++ /dev/null @@ -1,128 +0,0 @@ -# Angular Nx Tutorial - Step 7: Share Code - - - -Awesome! The application is working end to end! However, there is a problem. Both the backend and the frontend define the `Todo` interface. The interface is in sync now, but in a real application, over time, it will diverge, and, as a result, runtime errors will creep in. You should share this interface between the backend and the frontend. In Nx, you can do this by creating a library. - -**Run the following command to create a library:** - -```bash -npx nx g @nrwl/workspace:lib data -``` - -The result should look like this: - -```treeview -myorg/ -├── apps/ -│ ├── todos/ -│ ├── todos-e2e/ -│ └── api/ -├── libs/ -│ └── data/ -│ ├── src/ -│ │ ├── lib/ -│ │ │ ├── data.spec.ts -│ │ │ └── data.ts -│ │ └── index.ts -│ ├── .babelrc -│ ├── .eslintrc.json -│ ├── jest.config.js -│ ├── project.json -│ ├── README.md -│ ├── tsconfig.json -│ ├── tsconfig.lib.json -│ └── tsconfig.spec.json -├── tools/ -├── angular.json -├── nx.json -├── package.json -└── tsconfig.base.json -``` - -**Copy the interface into `libs/data/src/lib/data.ts`.** - -```typescript -export interface Todo { - title: string; -} -``` - -### A note about VS Code : - -If you're using [VS Code](https://code.visualstudio.com/) it may be necessary at this point to restart the TS server so that the new `@myorg/data` package is recognized. This may need to be done **every time a new workspace library is added**. If you install the [Nx Console](/using-nx/console) extension you won't need to take this step. - -## Refactor the API - -**Now update `apps/api/src/app/app.service.ts` to import the interface:** - -```typescript -import { Injectable } from '@nestjs/common'; -import { Todo } from '@myorg/data'; - -@Injectable() -export class AppService { - todos: Todo[] = [{ title: 'Todo 1' }, { title: 'Todo 2' }]; - - getData(): Todo[] { - return this.todos; - } - - addTodo() { - this.todos.push({ - title: `New todo ${Math.floor(Math.random() * 1000)}`, - }); - } -} -``` - -## Update the Angular application - -**Next import the interface in `apps/todos/src/app/app.component.ts`:** - -```typescript -import { Component } from '@angular/core'; -import { HttpClient } from '@angular/common/http'; -import { Todo } from '@myorg/data'; - -@Component({ - selector: 'myorg-root', - templateUrl: './app.component.html', - styleUrls: ['./app.component.css'], -}) -export class AppComponent { - todos: Todo[] = []; - - constructor(private http: HttpClient) { - this.fetch(); - } - - fetch() { - this.http.get('/api/todos').subscribe((t) => (this.todos = t)); - } - - addTodo() { - this.http.post('/api/addTodo', {}).subscribe(() => { - this.fetch(); - }); - } -} -``` - -> Every time you add a new library, you have to restart `npx nx serve`. - -Restart the api and application in separate terminal windows - -```bash -npx nx serve api -``` - -```bash -npx nx serve todos -``` - -And you should see the application running. - -## What's Next - -- Continue to [Step 8: Create Libraries](/angular-tutorial/08-create-libs) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/08-create-libs.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/08-create-libs.md deleted file mode 100644 index dd49256082..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/08-create-libs.md +++ /dev/null @@ -1,170 +0,0 @@ -# Angular Nx Tutorial - Step 8: Create Libs - - - -Libraries are not just a way to share code in Nx. They are also useful for factoring out code into small units with a well-defined public API. - -## Public API - -Every library has an `index.ts` file, which defines its public API. Other applications and libraries should only access what the `index.ts` exports. Everything else in the library is private. - -## UI libraries - -To illustrate how useful libraries can be, create a library of Angular components. - -Use the generate to scaffold a new library: - -```sh -npx nx g @nrwl/angular:lib ui -``` - -You should see the following: - -```treeview -myorg/ -├── apps/ -│ ├── todos/ -│ ├── todos-e2e/ -│ └── api/ -├── libs/ -│ ├── data/ -│ └── ui/ -│ ├── src/ -│ │ ├── lib/ -│ │ │ └── ui.module.ts -│ │ ├── index.ts -│ │ └── test-setup.ts -│ ├── .eslintrc.json -│ ├── jest.config.js -│ ├── project.json -│ ├── tsconfig.json -│ ├── tsconfig.lib.json -│ └── tsconfig.spec.json -├── tools/ -├── .eslintrc.json -├── nx.json -├── package.json -└── tsconfig.base.json -``` - -The `libs/ui/src/lib/ui.module.ts` file looks like this: - -```typescript -import { NgModule } from '@angular/core'; -import { CommonModule } from '@angular/common'; - -@NgModule({ - imports: [CommonModule], -}) -export class UiModule {} -``` - -## Add a component - -**Add a component to the newly created ui library by running:** - -```bash -npx nx g component todos --project=ui --export -``` - -```treeview -myorg/ -├── apps/ -│ ├── todos/ -│ ├── todos-e2e/ -│ └── api/ -├── libs/ -│ ├── data/ -│ └── ui/ -│ ├── src/ -│ │ ├── lib/ -│ │ │ ├── todos/ -│ │ │ │ ├── todos.component.css -│ │ │ │ ├── todos.component.html -│ │ │ │ ├── todos.component.spec.ts -│ │ │ │ └── todos.component.ts -│ │ │ └── ui.module.ts -│ │ └── index.ts -│ ├── .eslintrc.json -│ ├── jest.config.js -│ ├── tsconfig.json -│ ├── tsconfig.lib.json -│ └── tsconfig.spec.json -├── tools/ -├── nx.json -├── package.json -└── tsconfig.base.json -``` - -**Add a `todos` input to `libs/ui/src/lib/todos/todos.component.ts`.** - -```typescript -import { Component, OnInit, Input } from '@angular/core'; -import { Todo } from '@myorg/data'; - -@Component({ - selector: 'myorg-todos', - templateUrl: './todos.component.html', - styleUrls: ['./todos.component.css'], -}) -export class TodosComponent implements OnInit { - @Input() todos: Todo[] = []; - - constructor() {} - - ngOnInit() {} -} -``` - -**And update `todos.component.html` to display the given todos:** - -```html -
    -
  • {{ t.title }}
    • -
-``` - -## Use the UI library - -**Now import `UiModule` into `apps/todos/src/app/app.module.ts`.** - -```typescript -import { BrowserModule } from '@angular/platform-browser'; -import { NgModule } from '@angular/core'; - -import { AppComponent } from './app.component'; -import { HttpClientModule } from '@angular/common/http'; -import { UiModule } from '@myorg/ui'; - -@NgModule({ - declarations: [AppComponent], - imports: [BrowserModule, HttpClientModule, UiModule], - providers: [], - bootstrap: [AppComponent], -}) -export class AppModule {} -``` - -**And update `app.component.html`:** - -```html -

Todos

- - - - -``` - -Restart the api and application in separate terminal windows - -```bash -npx nx serve api -``` - -```bash -npx nx serve todos -``` - -## What's Next - -- Continue to [Step 9: Using the Project Graph](/angular-tutorial/09-dep-graph) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/09-dep-graph.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/09-dep-graph.md deleted file mode 100644 index f263a020b7..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/09-dep-graph.md +++ /dev/null @@ -1,19 +0,0 @@ -# Angular Nx Tutorial - Step 9: Using the Project Graph - - - -An Nx workspace can contain dozens or hundreds of applications and libraries. As a codebase grows, it becomes more difficult to understand how they depend on each other and the implications of making a particular change. - -Previously, some senior architect would create an ad-hoc dependency diagram and upload it to a corporate wiki. The diagram is not correct even on Day 1 and gets more and more out of sync with every passing day. - -With Nx, you can do better than that. - -Run the command to see the project graph for your workspace. - -```sh -npx nx graph -``` - -## What's Next - -- Continue to [Step 10: Using Computation Caching](/angular-tutorial/10-computation-caching) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/10-computation-caching.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/10-computation-caching.md deleted file mode 100644 index 0a60b6601c..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/10-computation-caching.md +++ /dev/null @@ -1,80 +0,0 @@ -# Angular Nx Tutorial - Step 10: Computation Caching - - - -Nx has built-in computation caching, which helps drastically improve the performance of the commands. - -**To see it in action, run `npx nx build todos`:** - -```bash -❯ nx build todos - -> nx run todos:build:production -✔ Browser application bundle generation complete. -✔ Copying assets complete. -✔ Index html generation complete. - -Initial Chunk Files | Names | Raw Size | Estimated Transfer Size -main.198853e72abe040f.js | main | 125.05 kB | 35.88 kB -polyfills.80c46001d98dd563.js | polyfills | 36.21 kB | 11.49 kB -runtime.db95d73b9ee480c5.js | runtime | 1.04 kB | 599 bytes -styles.ef46db3751d8e999.css | styles | 0 bytes | - - - | Initial Total | 162.30 kB | 47.96 kB - -Build at: 2022-01-21T20:36:14.528Z - Hash: 795c96ce5e48a766 - Time: 11596ms - -——————————————————————————————————————————————— - -> NX SUCCESS Running target "build" succeeded -``` - -**Now, run `npx nx build todos` again, and you will see the results appearing instantly:** - -```bash -❯ nx build todos - -> nx run todos:build:production [existing outputs match the cache, left as is] - -Initial Chunk Files | Names | Raw Size | Estimated Transfer Size -main.198853e72abe040f.js | main | 125.05 kB | 35.88 kB -polyfills.80c46001d98dd563.js | polyfills | 36.21 kB | 11.49 kB -runtime.db95d73b9ee480c5.js | runtime | 1.04 kB | 599 bytes -styles.ef46db3751d8e999.css | styles | 0 bytes | - - - | Initial Total | 162.30 kB | 47.96 kB - -Build at: 2022-01-21T20:36:14.528Z - Hash: 795c96ce5e48a766 - Time: 11596ms - -——————————————————————————————————————————————— - -> NX SUCCESS Running target "build" succeeded - - Nx read the output from cache instead of running the command for 1 out of 1 tasks. -``` - -Based on the state of the source code and the environment, Nx was able to figure out that it had already run this exact command. Nx found the artifact in the local cache and replayed the output and restored the necessary files. - -> Caching only works with the Nx CLI. Running `ng build todos` runs the command every single time. - -## Building multiple projects - -Use the `run-many` command to rebuild the two applications: - -```sh -npx nx run-many --target=build --projects=todos,api -``` - -And notice the output: - -```bash -Nx read the output from the cache instead of running the command for 1 out of 2 tasks. -``` - -Nx built `api` and retrieved `todos` from its computation cache. Read more about the cache here [here](/using-nx/caching). - -> Add --parallel to any command, and Nx does most of the work in parallel. - -## What's Next - -- Continue to [Step 11: Test Affected Projects](/angular-tutorial/11-test-affected-projects) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/11-test-affected-projects.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/11-test-affected-projects.md deleted file mode 100644 index 550b95fa45..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/11-test-affected-projects.md +++ /dev/null @@ -1,85 +0,0 @@ -# Angular Nx Tutorial - Step 11: Testing Affected Projects - - - -Because Nx understands the project graph of your workspace, Nx is efficient at retesting and rebuilding your projects. - -**Commit all the changes in the repo**: - -```bash -git add . -git commit -am 'init' -git checkout -b testbranch -``` - -**Open `libs/ui/src/lib/todos/todos.component.html` and change the template:** - -```html -
    -
  • {{ t.title }}!
    • -
-``` - -Run the command to see affected apps. - -```sh -npx nx affected:apps -``` - -You should see `todos` printed out. The `affected:apps` looks at what you have changed and uses the project graph to figure out which apps can be affected by this change. - -Run the command to see affected libraries - -```sh -npx nx affected:libs -``` - -You should see `ui` printed out. This command works similarly, but instead of printing the affected apps, it prints the affected libs. - -## Test affected projects - -Printing the affected projects can be handy, but usually you want to do something with them. For instance, you may want to test everything that has been affected. - -Run the command to retest only the projects affected by the change: - -```sh -npx nx affected:test -``` - -You will see the following: - -```bash -> NX Running target test for projects: - - - ui - - todos - -... - - Failed projects: - - - todos - - ui -``` - -Note that Nx only tried to retest `ui` and `todos`. It didn't retest `api` or `data` because there is no way that could be affected by the changes in this branch. - -Run the command to retest the failed projects. - -```sh -npx nx affected:test -- --only-failed -``` - -## Affected: - -You can run any target against the affected projects in the graph like this: - -```bash -# The following are equivalent -npx nx affected --target=build -npx nx affected:build -``` - -## What's Next - -- Continue to [Step 12: Summary](/angular-tutorial/12-summary) diff --git a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/12-summary.md b/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/12-summary.md deleted file mode 100644 index 24638bbfcb..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/angular-tutorial/12-summary.md +++ /dev/null @@ -1,18 +0,0 @@ -# Angular Nx Tutorial - Step 12: Summary - -In this tutorial you: - -- Built a full stack application using Angular and Nest -- Shared code between the frontend and the backend -- Created a UI library -- Used Nx affected commands to only retest and rebuild what is affected - -## Learn more - -- [Free Nx Course on YouTube](https://www.youtube.com/watch?time_continue=49&v=2mYLe9Kp9VM&feature=emb_logo) - -**Dive Deep:** - -- [Nx CLI](/using-nx/nx-cli) -- [Computation Caching](/using-nx/caching) -- [Rebuilding What is Affected](/using-nx/affected) diff --git a/nx-dev/nx-dev/public/documentation/shared/api/angular.jpg b/nx-dev/nx-dev/public/documentation/shared/api/angular.jpg deleted file mode 100644 index f03bf78a3b..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/api/angular.jpg and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/api/cypress.jpg b/nx-dev/nx-dev/public/documentation/shared/api/cypress.jpg deleted file mode 100644 index 7727bf6d73..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/api/cypress.jpg and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/api/express.jpg b/nx-dev/nx-dev/public/documentation/shared/api/express.jpg deleted file mode 100644 index f55f7f0783..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/api/express.jpg and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/api/jest.jpg b/nx-dev/nx-dev/public/documentation/shared/api/jest.jpg deleted file mode 100644 index d7ce915a2a..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/api/jest.jpg and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/api/nest.jpg b/nx-dev/nx-dev/public/documentation/shared/api/nest.jpg deleted file mode 100644 index 9e02b1e3dd..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/api/nest.jpg and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/api/node.jpg b/nx-dev/nx-dev/public/documentation/shared/api/node.jpg deleted file mode 100644 index 7003802217..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/api/node.jpg and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/api/react.jpg b/nx-dev/nx-dev/public/documentation/shared/api/react.jpg deleted file mode 100644 index e534bd5b24..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/api/react.jpg and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/api/web.jpg b/nx-dev/nx-dev/public/documentation/shared/api/web.jpg deleted file mode 100644 index d92cea331c..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/api/web.jpg and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/caching-example.png b/nx-dev/nx-dev/public/documentation/shared/caching-example.png deleted file mode 100644 index 026252539a..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/caching-example.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/ci-graph-everything-affected.png b/nx-dev/nx-dev/public/documentation/shared/ci-graph-everything-affected.png deleted file mode 100644 index 95ea861c4e..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/ci-graph-everything-affected.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/ci-graph-one-affected.png b/nx-dev/nx-dev/public/documentation/shared/ci-graph-one-affected.png deleted file mode 100644 index 1eb5a4c166..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/ci-graph-one-affected.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/ci-graph.png b/nx-dev/nx-dev/public/documentation/shared/ci-graph.png deleted file mode 100644 index 94138839ea..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/ci-graph.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/ci-overview.md b/nx-dev/nx-dev/public/documentation/shared/ci-overview.md deleted file mode 100644 index 17b6918a55..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/ci-overview.md +++ /dev/null @@ -1,20 +0,0 @@ -# Continous Integration Setup with Monorepos and Nx - -Monorepos provide a lot of advantages: - -- Everything at that current commit works together. Changes can be verified across all affected parts of the organization. -- Easy to split code into composable modules -- Easier dependency management -- One toolchain setup -- Code editors and IDEs are "workspace" aware -- Consistent developer experience -- And more ... - -But they come with their own technical challenges. The more code you add into your repository and the more code you have to build/test/lint, the slower the CI gets. There are two ways to look at this time spent. In average time, and worst case scenario time. When configured properly, your average CI is the time it takes a given change to go through the CI process. The worst case scenario time is the time it takes to rebuild every project in your monorepo based on a given change. These are baseline you use to measure how long it takes to process pull requests in your CI/CD environment. - -The following guides cover optimizing your CI/CD environments with affected commands and distributed caching: - -- [Setting up CI using GitHub Actions](/ci/monorepo-ci-github-actions) -- [Setting up CI using CircleCI](/ci/monorepo-ci-circle-ci) -- [Setting up CI using Azure Pipelines](/ci/monorepo-ci-azure) -- [Setting up CI using Jenkins](/ci/monorepo-ci-jenkins) diff --git a/nx-dev/nx-dev/public/documentation/shared/cli/build.md b/nx-dev/nx-dev/public/documentation/shared/cli/build.md deleted file mode 100644 index b35c5c1499..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/cli/build.md +++ /dev/null @@ -1,298 +0,0 @@ ---- -title: 'build - CLI command' -description: 'Compiles an application into an output directory named dist/ at the given output path. Must be executed from within a workspace directory.' ---- - -# build - -Compiles an application into an output directory named dist/ at the given output path. Must be executed from within a workspace directory. - -## Usage - -The `build` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx build [options] -``` - -```bash -nx run :build [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Compile a `production` build of the `myapp` project: - -```bash -nx build myapp --prod -``` - -## Options - -The options below are common to the `build` command used within an Nx workspace. The Web and Angular-specific build options are listed after these options. - -### baseHref - -Default: `/` - -Base url for the application being built. - -### commonChunk - -Use a separate bundle containing code used across multiple bundles. - -Default: `true` - -### budgets - -Budget thresholds to ensure parts of your application stay within boundaries which you set. - -### namedChunks - -Default: `true` - -Names the produced bundles according to their entry file - -### deployUrl - -URL where the application will be deployed. - -### es2015Polyfills - -Conditional polyfills loaded in browsers which do not support ES2015. - -### extractCss - -Extract css into a .css file - -### extractLicenses - -Extract all licenses in a separate file, in the case of production builds only. - -### index - -HTML File which will be contain the application - -### main - -The name of the main entry-point file. - -### tsConfig - -The name of the Typescript configuration file. - -### outputPath - -The output path of the generated files. - -### progress - -Log progress to the console while building. - -### optimization - -Enables optimization of the build output. - -### outputHashing - -Default: `none` - -Define the output filename cache-busting hashing mode. - -### scripts - -External Scripts which will be included before the main application entry. - -### showCircularDependencies - -Default: `true` - -Show circular dependency warnings on builds. - -### sourceMap - -Default: `true` - -Output sourcemaps. - -### statsJson - -Generates a 'stats.json' file which can be analyzed using tools such as: 'webpack-bundle-analyzer' or . - -### styles - -External Styles which will be included with the application - -### subresourceIntegrity - -Enables the use of subresource integrity validation. - -### vendorChunk - -Default: `true` - -Use a separate bundle containing only vendor libraries. - -### verbose - -Emits verbose output - -### watch - -Enable re-building when files change. - -### help - -Show help information - -### version - -Show version number - -## Web-Build Options - -### assets - -List of static application assets. - -### fileReplacements - -Replace files with other files in the build. - -### maxWorkers - -Number of workers to use for type checking. - -Default: `# of CPUS - 2` - -### memoryLimit - -Memory limit for type checking service process in MB. - -Default: `2048` - -### polyfills - -Polyfills to load before application - -### stylePreprocessorOptions - -Options to pass to style preprocessors. - -### webpackConfig - -Path to a function which takes a webpack config, some context and returns the resulting webpack config - -## Angular Options - -### aot - -Build using Ahead of Time compilation. - -### buildEventLog - -**EXPERIMENTAL** Output file path for Build Event Protocol events - -### buildOptimizer - -Enables `@angular-devkit/build-optimizer` optimizations when using the `--aot` option. - -### configuration (-c) - -A named build target, as specified in the "configurations" section of angular.json. -Each named target is accompanied by a configuration of option defaults for that target. -Setting this explicitly overrides the "--prod" flag - -### crossOrigin - -Define the crossorigin attribute setting of elements that provide CORS support. - -### deleteOutputPath - -Delete the output path before building. - -### deployUrl - -URL where files will be deployed. - -### es5BrowserSupport - -Enables conditionally loaded ES2015 polyfills. - -### evalSourceMap - -Output in-file eval sourcemaps. - -### experimentalRollupPass - -Concatenate modules with Rollup before bundling them with Webpack. - -### forkTypeChecker - -Run the TypeScript type checker in a forked process. - -### i18nFile - -Localization file to use for i18n. - -### i18nFormat - -Format of the localization file specified with --i18n-file. - -### i18nLocale - -Locale to use for i18n. - -### i18nMissingTranslation - -How to handle missing translations for i18n. - -### localize - -### ngswConfigPath - -Path to ngsw-config.json. - -### poll - -Enable and define the file watching poll time period in milliseconds. - -### polyfills - -The full path for the polyfills file, relative to the current workspace. - -### preserveSymlinks - -Do not use the real path when resolving modules. - -### rebaseRootRelativeCssUrls - -Change root relative URLs in stylesheets to include base HREF and deploy URL. Use only for compatibility and transition. The behavior of this option is non-standard and will be removed in the next major release. - -### resourcesOutputPath - -The path where style resources will be placed, relative to outputPath. - -### serviceWorker - -Generates a service worker config for production builds. - -### skipAppShell - -Flag to prevent building an app shell. - -### vendorSourceMap - -Resolve vendor packages sourcemaps. - -### verbose - -Adds more details to output logging. - -### webWorkerTsConfig - -TypeScript configuration for Web Worker modules. diff --git a/nx-dev/nx-dev/public/documentation/shared/cli/e2e.md b/nx-dev/nx-dev/public/documentation/shared/cli/e2e.md deleted file mode 100644 index 117d964a4b..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/cli/e2e.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -title: 'e2e - CLI command' -description: 'Builds and serves an app, then runs end-to-end tests using the configured E2E test runner.' ---- - -# e2e - -Builds and serves an app, then runs end-to-end tests using the configured E2E test runner. - -## Usage - -The `e2e` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx e2e -``` - -```bash -nx run :e2e -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run E2E test with a custom base url: - -```bash -nx e2e myapp-e2e --base-url http://localhost:4201 -``` - -Run E2E test with a specific target: - -```bash -nx e2e myapp-e2e --configuration smoke -``` - -Run E2E test in watch mode: - -```bash -nx e2e myapp-e2e --watch -``` - -## Common Options - -The options below are common to the E2E commands used within an Nx workspace. Cypress and Protractor-specific options are listed below. - -### baseUrl - -Use this to pass directly the address of your distant server address with the port running your application. Setting this will ignore any local server targets. To skip running local targets, reset the `devServerTarget` to empty string. - -### configuration (-c) - -A named build target, as specified in the "configurations" section of angular.json. Each named target is accompanied by a configuration of option defaults for that target. Setting this explicitly overrides the `--prod` option. - -### devServerTarget - -Dev server target to run tests against. - -### prod - -Shorthand for `--configuration=production`. When true, sets the build configuration to the production target. By default, the production target is set up in the workspace configuration such that all builds make use of bundling, limited tree-shaking, and also limited dead code elimination. - -### version - -Show version number - -### watch - -Open the Cypress test runner & automatically run tests when files are updated - -## Cypress Options - -### browser - -The browser to run tests in. - -### ci-build-id - -A unique identifier for a run to enable grouping or parallelization. - -### ci-build-id - -A unique identifier for a run to enable grouping or parallelization. - -### cypress-config - -The path of the Cypress configuration json file. - -### exit - -Whether or not the Cypress Test Runner will stay open after running tests in a spec file - -### group - -A named group for recorded runs in the Cypress dashboard. - -### headless - -Whether or not to open the Cypress application to run the tests. If set to 'true', will run in headless mode. - -### help - -Shows a help message for this command in the console. - -### key - -The key cypress should use to run tests in parallel/record the run (CI only). - -### parallel - -Whether or not Cypress should run its tests in parallel (CI only). - -### record - -Whether or not Cypress should record the results of the tests - -### spec - -A comma delimited glob string that is provided to the Cypress runner to specify which spec files to run. For example: '**examples/**,**actions.spec** - -### ts-config - -The path of the Cypress tsconfig configuration json file. - -## Protractor Options - -### element-explorer - -Start Protractor's Element Explorer for debugging. - -### host - -Host to listen on. - -### port - -The port to use to serve the application. - -### protractor-config - -The name of the Protractor configuration file. - -### specs - -Override specs in the protractor config. - -### suite - -Override suite in the protractor config. - -### webdriver-update - -Try to update webdriver. diff --git a/nx-dev/nx-dev/public/documentation/shared/cli/generate.md b/nx-dev/nx-dev/public/documentation/shared/cli/generate.md deleted file mode 100644 index 785bd2c4a2..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/cli/generate.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: 'generate - CLI command' -description: 'Runs a generator that creates and/or modifies files based on a generator from a collection.' ---- - -# generate - -Runs a generator that creates and/or modifies files based on a generator from a collection. - -## Usage - -```bash -nx generate -``` - -```bash -nx g -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Generate a new Angular application: - -```bash -nx generate @nrwl/angular:app myapp -``` - -Generate a new React application: - -```bash -nx generate @nrwl/react:app myapp -``` - -Generate a new web component application: - -```bash -nx generate @nrwl/web:app myapp -``` - -Generate a new Node application: - -```bash -nx generate @nrwl/node:app myapp -``` - -Generate a new Angular library application: - -```bash -nx generate @nrwl/angular:library mylibrary -``` - -Generate a new React library application: - -```bash -nx generate @nrwl/react:library mylibrary -``` - -Generate a new Node library application: - -```bash -nx generate @nrwl/node:library mylibrary -``` - -## Options - -### defaults - -Default: `false` - -When true, disables interactive input prompts for options with a default. - -### dryRun - -Default: `false` - -When true, disables interactive input prompts for options with a default. - -### force - -Default: `false` - -When true, forces overwriting of existing files. - -### interactive - -Default: `true` - -When false, disables interactive input prompts. - -### help - -Show help and display available generators in the default collection. - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/shared/cli/lint.md b/nx-dev/nx-dev/public/documentation/shared/cli/lint.md deleted file mode 100644 index 1a6f588c43..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/cli/lint.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: 'lint - CLI command' -description: 'Runs linting tools on application code in a given project folder using the configured linter.' ---- - -# lint - -Runs linting tools on application code in a given project folder using the configured linter. - -## Usage - -The `lint` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx lint [options] -``` - -```bash -nx run :lint [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run lint checks for the `myapp` project and fix linter errors: - -```bash -nx lint myapp --fix -``` - -## Common Options - -The options below are common to the `lint` command used within an Nx workspace. The ESLint and Angular-specific lint options are listed after these options. - -### exclude - -Files to exclude from linting. - -### files - -Files to include in linting. - -### fix - -Fixes linting errors (may overwrite linted files). - -### force - -Succeeds even if there was linting errors. - -### format - -ESLint Output formatter (https://eslint.org/docs/user-guide/formatters). (default: stylish) - -### silent - -Hide output text. - -### tsConfig - -The name of the TypeScript configuration file. - -### help - -Show help information - -### version - -Show version number - -## ESLint Options - -### cache - -Only check changed files. - -### cacheLocation - -Path to the cache file or directory. - -### config - -The name of the configuration file. - -### linter - -The tool to use for running lint checks. - -Default: `tslint` - -### outputFile - -File to write report to. - -## Angular-TSLint Options - -### configuration (-c) - -The linting configuration to use. - -### tslint-config - -The name of the TSLint configuration file. - -### type-check - -Controls the type check for linting. diff --git a/nx-dev/nx-dev/public/documentation/shared/cli/run.md b/nx-dev/nx-dev/public/documentation/shared/cli/run.md deleted file mode 100644 index 37f07a3de9..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/cli/run.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 'run - CLI command' -description: 'Runs an Architect target with an optional custom builder configuration defined in your project.' ---- - -# run - -Runs an Architect target with an optional custom builder configuration defined in your project. - -## Usage - -```bash -nx run [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run the `build` target for the `myapp` : - -```bash -nx run myapp:build -``` - -Run the `build` target for the `myapp` project with a `production` configuration: - -```bash -nx run myapp:build:production -``` - -## Options - -### configuration (-c) - -A named builder configuration, defined in the "configurations" section of the workspace configuration file. The builder uses the named configuration to run the given target. - -### help - -Show help - -### version - -Show version number diff --git a/nx-dev/nx-dev/public/documentation/shared/cli/serve.md b/nx-dev/nx-dev/public/documentation/shared/cli/serve.md deleted file mode 100644 index 519975a50b..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/cli/serve.md +++ /dev/null @@ -1,204 +0,0 @@ ---- -title: 'serve - CLI command' -description: 'Builds and serves an application, rebuilding on file changes.' ---- - -# serve - -Builds and serves an application, rebuilding on file changes. - -## Usage - -The `serve` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx serve [options] -``` - -```bash -nx run :serve [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Serve the `myapp` project: - -```bash -nx serve myapp -``` - -## Common Options - -The options below are common to the `serve` command used within an Nx workspace. The Web and Angular-specific serve options are listed after these options. - -### allowedHosts - -This option allows you to whitelist services that are allowed to access the dev server. - -### hmr - -Enable hot module replacement. - -### host - -Host to listen on. - -Default: `localhost` - -### liveReload - -Whether to reload the page on change, using live-reload. - -Default: `true` - -### open (-o) - -Open the application in the browser. - -### port - -Port to listen on. - -Default: `4200` - -### publicHost - -Public URL where the application will be served - -### ssl - -Serve using HTTPS. - -### sslKey - -SSL key to use for serving HTTPS. - -### sslCert - -SSL certificate to use for serving HTTPS. - -### watch - -Watches for changes and rebuilds application - -Default: `true` - -### help - -Show help - -### version - -Show version number - -## Web-Serve Options - -### buildTarget - -Target which builds the application - -### memoryLimit - -Memory limit for type checking service process in MB. - -### maxWorkers - -Number of workers to use for type checking. - -## Angular-Serve Options - -### aot - -Build using Ahead of Time compilation. - -### base-href - -Base url for the application being built. - -### browser-target - -Target to serve. - -### build-event-log - -**EXPERIMENTAL** Output file path for Build Event Protocol events. - -### common-chunk - -Use a separate bundle containing code used across multiple bundles. - -### configuration (-c) - -A named build target, as specified in the "configurations" section of the workspace configuration. -Each named target is accompanied by a configuration of option defaults for that target. -Setting this explicitly overrides the `--prod` flag - -### deploy-url - -URL where files will be deployed. - -### disable-host-check - -Don't verify connected clients are part of allowed hosts. - -### eval-source-map - -Output in-file eval sourcemaps. - -### hmr-warning - -Show a warning when the `--hmr` option is enabled. - -### optimization - -Enables optimization of the build output. - -### poll - -Enable and define the file watching poll time period in milliseconds. - -### prod - -Shorthand for `--configuration=production`. -When true, sets the build configuration to the production target. -By default, the production target is set up in the workspace configuration such that all builds make use of bundling, limited tree-shaking, and also limited dead code elimination. - -### progress - -Log progress to the console while building. - -### proxy-config - -Proxy configuration file. - -### public-host - -The URL that the browser client (or live-reload client, if enabled) should use to connect to the development server. Use for a complex dev server setup, such as one with reverse proxies. - -### serve-path - -The pathname where the app will be served. - -### serve-path-default-warning - -Show a warning when deploy-url/base-href use unsupported serve path values. - -### source-map - -Output sourcemaps. - -### vendor-chunk - -Use a separate bundle containing only vendor libraries. - -### vendor-source-map - -Resolve vendor packages sourcemaps. - -### verbose - -Adds more details to output logging. diff --git a/nx-dev/nx-dev/public/documentation/shared/cli/test.md b/nx-dev/nx-dev/public/documentation/shared/cli/test.md deleted file mode 100644 index c4eca9a970..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/cli/test.md +++ /dev/null @@ -1,263 +0,0 @@ ---- -title: 'test - CLI command' -description: 'Runs unit tests in a project using the configured unit test runner.' ---- - -# test - -Runs unit tests in a project using the configured unit test runner. - -## Usage - -The `test` command is a built-in alias to the [run command](/cli/run). - -These two commands are equivalent: - -```bash -nx test [options] -``` - -```bash -nx run :test [options] -``` - -[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`. - -### Examples - -Run unit tests: - -```bash -nx test myapp -``` - -## Common Options - -The options below are common to the `test` command used within an Nx workspace. The Jest and Karma-specific test options are listed after these options. - -### codeCoverage - -Indicates that test coverage information should be collected and reported in the output. (https://jestjs.io/docs/en/cli#coverage) - -### tsConfig - -The path to the Typescript configuration file. - -### watch - -Watch files for changes and rerun tests. - -### help - -Show help information. - -### version - -Show version number - -## Jest Options - -### bail - -Exit the test suite immediately after `n` number of failing tests. (https://jestjs.io/docs/en/cli#bail) - -### ci - -Whether to run Jest in continuous integration (CI) mode. This option is on by default in most popular CI environments. It will prevent snapshots from being written unless explicitly requested. (https://jestjs.io/docs/en/cli#ci) - -### color - -Forces test results output color highlighting (even if stdout is not a TTY). Set to false if you would like to have no colors. (https://jestjs.io/docs/en/cli#colors) - -### colors - -Forces test results output highlighting even if stdout is not a TTY. (https://jestjs.io/docs/en/cli#colors) - -### coverageReporters - -A list of reporter names that Jest uses when writing coverage reports. Any istanbul reporter - -### coverageDirectory - -An array of regexp pattern strings that are matched against all file paths before executing the test. If the file path matches any of the patterns, coverage information will be skipped. - -### config - -The path to a Jest config file specifying how to find and execute tests. If no rootDir is set in the config, the directory containing the config file is assumed to be the rootDir for the project. This can also be a JSON-encoded value which Jest will use as configuration - -### clearCache - -Deletes the Jest cache directory and then exits without running tests. Will delete Jest's default cache directory. _Note: clearing the cache will reduce performance_. - -### findRelatedTests - -Find and run the tests that cover a comma separated list of source files that were passed in as arguments. (https://jestjs.io/docs/en/cli#findrelatedtests-spaceseparatedlistofsourcefiles) - -### jestConfig - -The path of the Jest configuration. (https://jestjs.io/docs/en/configuration) - -### json - -Prints the test results in JSON. This mode will send all other test output and user messages to stderr. (https://jestjs.io/docs/en/cli#json) - -### maxWorkers - -Specifies the maximum number of workers the worker-pool will spawn for running tests. This defaults to the number of the cores available on your machine. Useful for CI. (its usually best not to override this default) (https://jestjs.io/docs/en/cli#maxworkers-num) - -### onlyChanged - -Attempts to identify which tests to run based on which files have changed in the current repository. Only works if you're running tests in a git or hg repository at the moment. (https://jestjs.io/docs/en/cli#onlychanged) - -### outputFile - -Write test results to a file when the --json option is also specified. (https://jestjs.io/docs/en/cli#outputfile-filename) - -### passWithNoTests - -Will not fail if no tests are found (for example while using `--testPathPattern`.) (https://jestjs.io/docs/en/cli#passwithnotests) - -### reporters - -Run tests with specified reporters. Reporter options are not available via CLI. Example with multiple reporters: jest --reporters="default" --reporters="jest-junit" (https://jestjs.io/docs/en/cli#reporters) - -### runInBand - -Run all tests serially in the current process (rather than creating a worker pool of child processes that run tests). This is sometimes useful for debugging, but such use cases are pretty rare. Useful for CI. (https://jestjs.io/docs/en/cli#runinband) - -### setupFile - -The name of a setup file used by Jest. (https://jestjs.io/docs/en/configuration#setupfilesafterenv-array) - -### silent - -Prevent tests from printing messages through the console. (https://jestjs.io/docs/en/cli#silent) - -### testFile - -The name of the file to test. - -### testNamePattern - -Run only tests with a name that matches the regex pattern. (https://jestjs.io/docs/en/cli#testnamepattern-regex) - -### testPathPattern - -An array of regexp pattern strings that is matched against all tests paths before executing the test. (https://jestjs.io/docs/en/cli#testpathpattern-regex) - -### testLocationInResults - -Adds a location field to test results. Used to report location of a test in a reporter. { "column": 4, "line": 5 } (https://jestjs.io/docs/en/cli#testlocationinresults) - -### testResultsProcessor - -Node module that implements a custom results processor. (https://jestjs.io/docs/en/configuration#testresultsprocessor-string) - -### updateSnapshot - -Use this flag to re-record snapshots. Can be used together with a test suite pattern or with `--testNamePattern` to re-record snapshot for test matching the pattern. (https://jestjs.io/docs/en/cli#updatesnapshot) - -### useStderr - -Divert all output to stderr. - -### verbose - -Display individual test results with the test suite hierarchy. (https://jestjs.io/docs/en/cli#verbose) - -### watchAll - -Watch files for changes and rerun all tests when something changes. If you want to re-run only the tests that depend on the changed files, use the `--watch` option. (https://jestjs.io/docs/en/cli#watchall) - -## Karma Options - -### browsers - -Override which browsers tests are run against. - -### codeCoverage - -Output a code coverage report. - -### codeCoverageExclude - -Globs to exclude from code coverage. - -### configuration (-c) - -A named build target, as specified in the "configurations" section of angular.json. -Each named target is accompanied by a configuration of option defaults for that target. -Setting this explicitly overrides the `--prod` flag. - -### environment - -Defines the build environment. - -### evalSourceMap - -Output in-file eval sourcemaps. - -### help - -Shows a help message for this command in the console. - -### include - -Globs of files to include, relative to workspace or project root. - -There are 2 special cases: - -- when a path to directory is provided, all spec files ending ".spec.@(ts|tsx)" will be included -- when a path to a file is provided, and a matching spec file exists it will be included instead - -### karmaConfig - -The name of the Karma configuration file. - -### main - -The name of the main entry-point file. - -### poll - -Enable and define the file watching poll time period in milliseconds. - -### polyfills - -The name of the polyfills file. - -### preserveSymlinks - -Do not use the real path when resolving modules. - -### prod - -Shorthand for "--configuration=production". When true, sets the build configuration to the production target. By default, the production target is set up in the workspace configuration such that all builds make use of bundling, limited tree-shaking, and also limited dead code elimination. - -### progress - -Log progress to the console while building. - -### reporters - -Karma reporters to use. Directly passed to the karma runner. - -### sourceMap - -Output sourcemaps. - -### tsConfig - -The name of the TypeScript configuration file. - -### vendorSourceMap - -Resolve vendor packages sourcemaps. - -### watch - -Run build when files change. - -### webWorkerTsConfig - -TypeScript configuration for Web Worker modules. diff --git a/nx-dev/nx-dev/public/documentation/shared/configuration/packagejson.md b/nx-dev/nx-dev/public/documentation/shared/configuration/packagejson.md deleted file mode 100644 index 6086c43b3d..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/configuration/packagejson.md +++ /dev/null @@ -1,376 +0,0 @@ -# Configuration: package.json and nx.json - -There are two main types of configuration in every Nx workspace: [project configuration](#project-configuration) -and [the global Nx CLI configuration](#cli-configuration). - -Projects can be configured in `package.json` (if you use npm scripts and not Nx executors) and `project.json` (if you -use Nx executors). Both `package.json` and `project.json` files are located in each project's folder. Nx merges the two -files to get each project's configuration. This guide covers the `package.json` case. - -## Project Configuration - -Every npm script defined in `package.json` is a target you can invoke via Nx. For instance, if your project has the -following `package.json`: - -```jsonc -{ - "name": "mylib", - "scripts": { - "test: "jest", - "build": "tsc -p tsconfig.lib.json" // the actual command here is arbitrary - } -} -``` - -you can invoke `nx build mylib` or `nx test mylib` without any extra configuration. - -You can add Nx-specific configuration as follows: - -```jsonc -{ - "name": "mylib", - "scripts": { - "test: "jest", - "build": "tsc -p tsconfig.lib.json" // the actual command here is arbitrary - }, - "nx": { - "targets": { - "build": { - "outputs": ["dist/libs/mylib"], - "dependsOn": [ - { - "target": "build", - "projects": "dependencies" - } - ] - }, - "test": { - "outputs": [], - "dependsOn": [ - { - "target": "build", - "projects": "self" - } - ] - } - } - } -} -``` - -### outputs - -`"outputs": ["dist/libs/mylib"]` tells Nx where the `build` target is going to create file artifacts. The provided value -is actually the default, so we can omit it in this case. `"outputs": []` tells Nx that the `test` target doesn't create -any artifacts on disk. - -This configuration is usually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the -configuration above. - -### dependsOn - -Targets can depend on other targets. - -A common scenario is having to build dependencies of a project first before building the project. This is what -the `dependsOn` property of the `build` target configures. It tells Nx that before it can build `mylib` it needs to make -sure that `mylib`'s dependencies are built as well. This doesn't mean Nx is going to rerun those builds. If the right -artifacts are already in the right place, Nx will do nothing. If they aren't in the right place, but they are available -in the cache, Nx will retrieve them from the cache. - -Another common scenario is for a target to depend on another target of the same project. For instance, `dependsOn` of -the `test` target tells Nx that before it can test `mylib` it needs to make sure that `mylib` is built, which will -result in `mylib`'s dependencies being built as well. - -This configuration is usually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the -configuration above. - -### tags - -You can annotate your projects with `tags` as follows: - -```jsonc -{ - "name": "mylib", - "nx": { - "tags": ["scope:myteam"] - } -} -``` - -You can [configure lint rules using these tags](/structure/monorepo-tags) to, for instance, ensure that libraries belonging to `myteam` are not depended on by libraries belong to `theirteam`. - -### implicitDependencies - -Nx uses powerful source-code analysis to figure out your workspace's project graph. Some dependencies cannot be deduced -statically, so you can set them manually like this: - -```jsonc -{ - "name": "mylib", - "nx": { - "implicitDependencies": ["anotherlib"] - } -} -``` - -You can also remove a dependency as follows: - -```jsonc -{ - "name": "mylib", - "nx": { - "implicitDependencies": ["!anotherlib"] # regardless of what Nx thinks, "mylib" doesn't depend on "anotherlib" - } -} -``` - -### Ignoring a project - -Nx will add every project with a `package.json` file in it to its project graph. If you want to ignore a particular -project, add the following to its `package.json`: - -```jsonc -{ - "name": "mylib", - "nx": { - "ignore": true - } -} -``` - -### workspace json - -The `workspace.json` file in the root directory is optional. It's used if you want to list the projects in your workspace explicitly instead of Nx scanning the file tree for all `project.json` and `package.json` files that match the globs specified in the `workspaces` property of the root `package.json`. - -```json -{ - "version": 2, - "projects": { - "myapp": "apps/myapp" - } -} -``` - -- `"version": 2` tells Nx that we are using Nx's format for the `workspace.json` file. -- `projects` is a map of project names to their locations. - -## CLI Configuration - -The `nx.json` file configures the Nx CLI and project defaults. - -The following is an expanded version showing all options. Your `nx.json` will likely be much shorter. - -```json -{ - "npmScope": "happyorg", - "affected": { - "defaultBase": "main" - }, - "workspaceLayout": { - "appsDir": "demos", - "libsDir": "packages" - }, - "implicitDependencies": { - "workspace.json": "*", - "package.json": { - "dependencies": "*", - "devDependencies": "*" - }, - "tsconfig.base.json": "*", - "nx.json": "*" - }, - "targetDependencies": { - "build": [ - { - "target": "build", - "projects": "dependencies" - } - ] - }, - "cli": { - "defaultCollection": "@nrwl/js" - }, - "generators": { - "@nrwl/js:library": { - "buildable": true - } - }, - "tasksRunnerOptions": { - "default": { - "runner": "@nrwl/workspace/tasks-runners", - "options": { - "cacheableOperations": ["build", "lint", "test", "e2e"] - } - } - } -} -``` - -### NPM Scope - -Tells Nx what prefix to use when generating library imports. - -### Affected - -Tells Nx which branch and HEAD to use when calculating affected projects. - -- `defaultBase` defines the default base branch, defaulted to `main`. - -### Workspace Layout - -You can add a `workspaceLayout` property to modify where libraries and apps are located. - -```json -{ - "workspaceLayout": { - "appsDir": "demos", - "libsDir": "packages" - } -} -``` - -These settings would store apps in `/demos/` and libraries in `/packages/`. The paths specified are relative to the -workspace root. - -### Files & Implicit Dependencies - -Nx performs advanced source-code analysis to figure out the project graph of the workspace. So when you make a change, -Nx can deduce what can be broken by this change. Some dependencies between projects and shared files cannot be inferred -statically. You can configure those using `implicitDependencies`. - -```json -{ - "implicitDependencies": { - "workspace.json": "*", - "package.json": { - "dependencies": "*", - "devDependencies": { - "mypackage": ["mylib"] - }, - "scripts": { - "check:*": "*" - } - }, - "globalFile": ["myapp"], - "styles/**/*.css": ["myapp"] - } -} -``` - -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. -- Changing `globalFile` only affects `myapp`. -- Changing any CSS file inside the `styles` directory only affects `myapp`. - -### Target Dependencies - -Targets can depend on other targets. A common scenario is having to build dependencies of a project first before -building the project. The `dependsOn` property in `package.json` can be used to define the list of dependencies of an -individual target. - -Often the same `dependsOn` configuration has to be defined for every project in the repo, and that's when -defining `targetDependencies` in `nx.json` is helpful. - -```json -{ - "targetDependencies": { - "build": [ - { - "target": "build", - "projects": "dependencies" - } - ] - } -} -``` - -The configuration above is identical to adding `{"dependsOn": [{"target": "build", "projects": "dependencies"]}` to -every build target of every project. - -### 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 plugin 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 -pass `--buildable=true` when creating new libraries. - -```json -{ - "generators": { - "@nrwl/js:library": { - "buildable": true - } - } -} -``` - -### Tasks Runner Options - -> A task is an invocation of a target. - -Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, and so on. The tasks runner -named "default" is used by default. Specify a different one like this `nx run-many --target=build --all --runner=another`. - -Tasks runners can accept different options. The following are the options supported -by `"@nrwl/workspace/tasks-runners"` and `"@nrwl/nx-cloud"`. - -- `cacheableOperations` defines the list of targets/operations that are cached by Nx. -- `parallel` defines the max number of targets ran in parallel (in older versions of Nx you had to - pass `--parallel --maxParallel=3` instead of `--parallel=3`). -- `captureStderr` defines whether the cache captures stderr or just stdout. -- `skipNxCache` defines whether the Nx Cache should be skipped. Defaults to `false`. -- `cacheDirectory` defines where the local cache is stored, which is `node_modules/.cache/nx` by default. -- `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": "@nrwl/workspace/tasks-runners", - "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`. - -## .nxignore - -You may optionally add an `.nxignore` file to the root. This file is used to specify files in your workspace that should -be completely ignored by Nx. - -The syntax is the same as -a [`.gitignore` file](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring). - -**When a file is specified in the `.nxignore` file:** - -1. Changes to that file are not taken into account in the `affected` calculations. -2. Even if the file is outside an app or library, `nx workspace-lint` won't warn about it. diff --git a/nx-dev/nx-dev/public/documentation/shared/configuration/projectjson.md b/nx-dev/nx-dev/public/documentation/shared/configuration/projectjson.md deleted file mode 100644 index ac8f2e3dcc..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/configuration/projectjson.md +++ /dev/null @@ -1,480 +0,0 @@ -# Configuration: project.json and nx.json - -There are two main types of configuration in every Nx workspace: [project configuration](#project-configuration) -and [the global Nx CLI configuration](#cli-configuration). - -Projects can be configured in `package.json` (if you use npm scripts and not Nx executors) and `project.json` (if you -use Nx executors). Both `package.json` and `project.json` files are located in each project's folder. Nx merges the two -files to get each project's configuration. This guide covers the `project.json` case. - -> Angular developers can also configure projects in angular.json. Read [this guide](/getting-started/nx-and-angular#angularjson) for more information. - -## Project Configuration - -The `project.json` file contains configuration specific to its project. This file is often created when you use Nx -Plugins. It configures custom executors, which are used instead of npm scripts. Custom executors are typed, toolable and provide a -lot more flexibility for running long-live processes. They are also more composable. - -If you satisfied with npm scripts though, you will never see a `project.json` file in your workspace. But we encourage -you to explore Nx Plugins and the power they bring. - -Let's look at the following `project.json`: - -```json -{ - "root": "libs/mylib/", - "sourceRoot": "libs/mylib/src", - "projectType": "library", - "targets": { - "test": { - "executor": "@nrwl/jest:jest", - "outputs": [], - "dependsOn": [ - { - "target": "build", - "projects": "self" - } - ], - "options": { - "jestConfig": "libs/mylib/jest.config.js", - "tsConfig": "libs/mylib/tsconfig.spec.json" - } - }, - "build": { - "executor": "@nrwl/js:tsc", - "outputs": ["dist/libs/mylib"], - "dependsOn": [ - { - "target": "build", - "projects": "dependencies" - } - ], - "options": { - "tsConfig": "libs/mylib/tsconfig.lib.json", - "main": "libs/mylib/src/main.ts" - }, - "configurations": { - "production": { - "tsConfig": "libs/mylib/tsconfig-prod.lib.json" - } - } - } - }, - "tags": ["scope:myteam"], - "implicitDependencies": ["anotherlib"] -} -``` - -- `root` tells Nx the location of the library including its sources and configuration files. -- `sourceRoot` tells Nx the location of the library's source files. -- `projectType` is either 'application' or 'library'. The project type is used in project graph viz and in a few aux - commands. - -### Targets - -Let's look at a sample test target: - -```json -{ - "test": { - "executor": "@nrwl/jest:jest", - "outputs": [], - "dependsOn": [ - { - "target": "build", - "projects": "self" - } - ], - "options": { - "jestConfig": "libs/mylib/jest.config.js", - "tsConfig": "libs/mylib/tsconfig.spec.json" - } - } -} -``` - -**Target Name** - -The name of the target `test` means that you can invoke it as follows: `nx test mylib` or `nx run mylib:test`. The name -isn't significant in any other way. If you rename it to, for example, `mytest`, you will be able to run as -follows: `nx mytest mylib` or `nx run mylib:mytest`. - -**Executor** - -The `executor` property tells Nx what function to invoke when you run the target. `"@nrwl/jest:jest"` tells Nx to find -the `@nrwl/jest` package, find the executor named `jest` and invoke it with the options. - -**Options** - -The `options` provides a map of values that will be passed to the executor. The provided command line args will be -merged into this map. I.e., `nx test mylib --jestConfig=libs/mylib/another-jest.config.js` will pass the following to -the executor: - -```json -{ - "jestConfig": "libs/mylib/another-jest.config.js", - "tsConfig": "libs/mylib/tsconfig.spec.json" -} -``` - -**Configurations** - -The `configurations` property provides extra sets of values that will be merged into the options map. - -```json -{ - "build": { - "executor": "@nrwl/js:tsc", - "outputs": ["dist/libs/mylib"], - "dependsOn": [ - { - "target": "build", - "projects": "dependencies" - } - ], - "options": { - "tsConfig": "libs/mylib/tsconfig.lib.json", - "main": "libs/mylib/src/main.ts" - }, - "configurations": { - "production": { - "tsConfig": "libs/mylib/tsconfig-prod.lib.json" - } - } - } -} -``` - -You can select a configuration like this: `nx build mylib --configuration=production` -or `nx run mylib:build:configuration=production`. - -The following code snippet shows how the executor options get constructed: - -```javascript -require(`@nrwl/jest`).executors['jest']({ - ...options, - ...selectedConfiguration, - ...commandLineArgs, -}); // Pseudocode -``` - -The selected configuration adds/overrides the default options, and the provided command line args add/override the -configuration options. - -### Outputs - -`"outputs": ["dist/libs/mylib"]` tells Nx where the `build` target is going to create file artifacts. The provided value -is actually the default, so we can omit it in this case. `"outputs": []` tells Nx that the `test` target doesn't create -any artifacts on disk. - -### dependsOn - -Targets can depend on other targets. - -A common scenario is having to build dependencies of a project first before building the project. This is what -the `dependsOn` property of the `build` target configures. It tells Nx that before it can build `mylib` it needs to make -sure that `mylib`'s dependencies are built as well. This doesn't mean Nx is going to rerun those builds. If the right -artifacts are already in the right place, Nx will do nothing. If they aren't in the right place, but they are available -in the cache, Nx will retrieve them from the cache. - -Another common scenario is for a target to depend on another target of the same project. For instance, `dependsOn` of -the `test` target tells Nx that before it can test `mylib` it needs to make sure that `mylib` is built, which will -result in `mylib`'s dependencies being built as well. - -This configuration is usually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the -configuration above. - -### tags - -You can annotate your projects with `tags` as follows: - -```jsonc -{ - "tags": ["scope:myteam"] -} -``` - -You can [configure lint rules using these tags](/structure/monorepo-tags) to, for instance, ensure that libraries belonging to `myteam` are not depended on by libraries belong to `theirteam`. - -### implicitDependencies - -Nx uses powerful source-code analysis to figure out your workspace's project graph. Some dependencies cannot be deduced -statically, so you can set them manually like this: - -```json -{ - "root": "libs/mylib/", - "sourceRoot": "libs/mylib/src", - "projectType": "library", - "targets": {}, - "implicitDependencies": ["anotherlib"] -} -``` - -You can also remove a dependency as follows: - -```jsonc -{ - "root": "libs/mylib/", - "sourceRoot": "libs/mylib/src", - "projectType": "library", - "targets": {}, - "implicitDependencies": ["!anotherlib"] # regardless of what Nx thinks, "mylib" doesn't depend on "anotherlib" -} -``` - -### workspace json - -The `workspace.json` file in the root directory is optional. It's used if you want to list the projects in your workspace explicitly instead of Nx scanning the file tree for all `project.json` and `package.json` files. - -```json -{ - "version": 2, - "projects": { - "myapp": "apps/myapp" - } -} -``` - -- `"version": 2` tells Nx that we are using Nx's format for the `workspace.json` file. -- `projects` is a map of project names to their locations. - -You could inline `project.json` files into `workspace.json`. This used to be the default, but it's no longer -recommended. If you have an existing workspace where the configuration is inlined, -run `nx g convert-to-nx-project --all`. - -If you have an old workspace where the configuration version is set to 1, change the version number to 2 and -run `nx format`. - -## CLI Configuration - -The `nx.json` file configures the Nx CLI and project defaults. - -The following is an expanded version showing all options. Your `nx.json` will likely be much shorter. - -```json -{ - "npmScope": "happyorg", - "affected": { - "defaultBase": "main" - }, - "workspaceLayout": { - "appsDir": "demos", - "libsDir": "packages" - }, - "implicitDependencies": { - "workspace.json": "*", - "package.json": { - "dependencies": "*", - "devDependencies": "*" - }, - "tsconfig.base.json": "*", - "nx.json": "*" - }, - "targetDependencies": { - "build": [ - { - "target": "build", - "projects": "dependencies" - } - ] - }, - "cli": { - "defaultCollection": "@nrwl/js" - }, - "generators": { - "@nrwl/js:library": { - "buildable": true - } - }, - "tasksRunnerOptions": { - "default": { - "runner": "@nrwl/workspace/tasks-runners", - "options": { - "cacheableOperations": ["build", "lint", "test", "e2e"] - } - } - } -} -``` - -### NPM Scope - -Tells Nx what prefix to use when generating library imports. - -### Affected - -Tells Nx which branch and HEAD to use when calculating affected projects. - -- `defaultBase` defines the default base branch, defaulted to `main`. - -### Workspace Layout - -You can add a `workspaceLayout` property to modify where libraries and apps are located. - -```json -{ - "workspaceLayout": { - "appsDir": "demos", - "libsDir": "packages" - } -} -``` - -These settings would store apps in `/demos/` and libraries in `/packages/`. The paths specified are relative to the -workspace root. - -### Files & Implicit Dependencies - -Nx performs advanced source-code analysis to figure out the project graph of the workspace. So when you make a change, -Nx can deduce what can be broken by this change. Some dependencies between projects and shared files cannot be inferred -statically. You can configure those using `implicitDependencies`. - -```json -{ - "implicitDependencies": { - "workspace.json": "*", - "package.json": { - "dependencies": "*", - "devDependencies": { - "mypackage": ["mylib"] - }, - "scripts": { - "check:*": "*" - } - }, - "globalFile": ["myapp"], - "styles/**/*.css": ["myapp"] - } -} -``` - -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. -- Changing `globalFile` only affects `myapp`. -- Changing any CSS file inside the `styles` directory only affects `myapp`. - -### Target Dependencies - -Targets can depend on other targets. A common scenario is having to build dependencies of a project first before -building the project. The `dependsOn` property in `package.json` can be used to define the list of dependencies of an -individual target. - -Often the same `dependsOn` configuration has to be defined for every project in the repo, and that's when -defining `targetDependencies` in `nx.json` is helpful. - -```json -{ - "targetDependencies": { - "build": [ - { - "target": "build", - "projects": "dependencies" - } - ] - } -} -``` - -The configuration above is identical to adding `{"dependsOn": [{"target": "build", "projects": "dependencies"]}` to -every build target of every project. - -### 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 -pass `--buildable=true` when creating new libraries. - -```json -{ - "generators": { - "@nrwl/js:library": { - "buildable": true - } - } -} -``` - -### Tasks Runner Options - -> A task is an invocation of a target. - -Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, and so on. The tasks runner -named "default" is used by default. Specify a different one like this `nx run-many --target=build --all --runner=another`. - -Tasks runners can accept different options. The following are the options supported -by `"@nrwl/workspace/tasks-runners"` and `"@nrwl/nx-cloud"`. - -- `cacheableOperations` defines the list of targets/operations that are cached by Nx. -- `parallel` defines the max number of targets ran in parallel (in older versions of Nx you had to - pass `--parallel --maxParallel=3` instead of `--parallel=3`). -- `captureStderr` defines whether the cache captures stderr or just stdout. -- `skipNxCache` defines whether the Nx Cache should be skipped. Defaults to `false`. -- `cacheDirectory` defines where the local cache is stored, which is `node_modules/.cache/nx` by default. -- `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": "@nrwl/workspace/tasks-runners", - "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`. - -## .nxignore - -You may optionally add an `.nxignore` file to the root. This file is used to specify files in your workspace that should -be completely ignored by Nx. - -The syntax is the same as -a [`.gitignore` file](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring). - -**When a file is specified in the `.nxignore` file:** - -1. Changes to that file are not taken into account in the `affected` calculations. -2. Even if the file is outside an app or library, `nx workspace-lint` won't warn about it. - -## 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: - -```bash -nx workspace-lint -``` - -This will identify any projects with no files in the configured project root folder, as well as any file that's not part -of any project configured in the workspace. diff --git a/nx-dev/nx-dev/public/documentation/shared/console.md b/nx-dev/nx-dev/public/documentation/shared/console.md deleted file mode 100644 index 8e13ca6ed2..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/console.md +++ /dev/null @@ -1,132 +0,0 @@ -# Nx Editor Plugins - -**Spend less time looking up command line arguments and more time shipping incredible products.** - -With Nx, you can get a full-stack application up and running in minutes, no need to figure out sourcemaps, webpack or test runners. It all works out of the box. Nx also helps you to enforce consistent development practices by generating components, services, and state management modules. - -## Why use Nx Editor Plugins? - -Developers use both command-line tools and user interfaces. They commit in the terminal, but resolve conflicts in VSCode or WebStorm. They use the right tool for the job. - -Nx is a command-line tool, which works great when you want to serve an application or generate a simple component. But it falls short once you start doing advanced things. - -For instance: - -- Exploring custom generator collections is hard in the terminal, but it's easy using Nx Console. -- Using rarely-used flags is challenging. Do you pass absolute or relative paths? You don't have to remember any flags, names or paths -  Nx Console will help you by providing autocompletion and validating your inputs. -- Finding the right Nx extension can take a long time. When using Nx Console, you can find and install an extension in minutes. - -Nx Console does all that and more! - -## Download - -### VSCode - -If you are using [VSCode](https://code.visualstudio.com/), you can install the [Nx Console VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) from Marketplace. The Nx Console VSCode Plugin is **built and maintained by the Nx team**. - -### WebStorm - -If you are using [WebStorm](https://www.jetbrains.com/webstorm/), you can install one of the available plugins: -[nx-webstorm](https://plugins.jetbrains.com/plugin/15000-nx-webstorm) -[Nx Console Idea](https://plugins.jetbrains.com/plugin/15101-nx-console-idea) - -These plugins are **NOT** built or maintained by the Nx team. They are maintained by independent community contributors. - -## Nx Console for VSCode - -![Nx Console logo](/shared/nx-console-logo.png) - -- [Install from the VSCode Marketplace](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) -- [Contribute on GitHub](https://github.com/nrwl/nx-console) - -![Nx Console screenshot](/shared/nx-console-screenshot.png) - -### True UI for Nx - -Nx Console is the UI for Nx. It works for any generator or any architect commands. Nx Console does not have a specific UI for, say, generating a component. Instead, Nx Console does what the command-line version of Nx does - it analyzes the same meta information to create the needed UI. This means that anything you can do with Nx, you can do with Nx Console. After all, Nx Console is the UI for Nx. - -### Useful for both experts and beginners - -Even though we started building Nx Console as a tool for experts, we also aimed to make Nx Console a great tool for developers who are new to development or Nx. You can create projects, interact with your editor, run generators and commands and install extensions without ever touching the terminal or having to install any node packages globally. Also, Nx Console highlights the properties you are likely to use for built-in generators and commands, so if you haven't used the CLI, you don't get overwhelmed. - -### Documentation - -#### Generate - -The `Generate` action allows you to choose a generator and then opens a form listing out all the options for that generator. As you make changes to the form, the generator is executed in `--dry-run` mode in a terminal so you can preview the results of running the generator in real time. - - - -**From the Command Palette** - -You can also launch the `Generate` action from the Command Palette (`⇧⌘P`) by selecting `nx: generate (ui)`. - - - -You can even construct the generator options while staying entirely within the Command Palette. Use `⇧⌘P` to open the Command Palette, then select `nx: generate`. After choosing a generator, select any of the listed options to modify the generator command. When you're satisfied with the constructed command, choose the `Execute` command at the top of the list. - - - -#### Run - -The `Run` action allows you to choose an executor command and then opens a form listing out all the options for that executor. The frequently used executor commands `build`, `serve`, `test`, `e2e` and `lint` also have their own dedicated actions. - - - -**From the Command Palette** - -You can also construct the executor command options while staying entirely within the Command Palette. Use `⇧⌘P` to open the Command Palette, then select `nx: test`. After choosing a project, select any of the listed options to modify the executor command options. When you're satisfied with the constructed command, choose the `Execute` command at the top of the list. - - - -#### Common Nx Commands - -You can also launch other common Nx commands with the options listed out in the Command Palette. - - - -#### Projects - -Clicking on the name of any project navigates to that project's definition in the `workspace.json` (or `angular.json`) file. Clicking on the name of any executor command navigates to that executor command's definition in the `workspace.json` (or `angular.json`) file. - -Clicking the ![refresh-light.svg](./refresh-light.svg) icon next to the `PROJECTS` header repopulates the Projects pane from the `workspace.json` (or `angular.json`) file. - -Clicking the ![folder-light.svg](./folder-light.svg) icon next to a project reveals that project's folder in the VSCode Explorer pane. - -Clicking the ![continue-light.svg](./continue-light.svg) icon next to an executor command executes that command without prompting for options. - - - -#### Streamlining - -If you find yourself running the same command many times, here are few tips to save yourself some key strokes. - -**Rerun Last Task** - -If you want to rerun the last task with all the same options specified, bring up the Command Palette (`⇧⌘P`) and choose `Rerun Last Task`. - -**Keyboard Shortcuts** - -You can also set up custom tasks and assign keyboard shortcuts to them. In `.vscode/tasks.json` add a task like this: - -```json -{ - "label": "Test Affected", - "type": "shell", - "command": "nx affected --target=test" -} -``` - -Then from the Command Palette (`⇧⌘P`) choose `Preferences: Open Keyboard Shortcuts (JSON)`. Then add the following shortcut: - -```json -{ - "key": "ctrl+cmd+t", - "command": "workbench.action.tasks.runTask", - "args": "Test Affected" -} -``` - -Now, pressing `^⌘T` will run `nx affected --target=test`. - -Here is more information on [VSCode tasks](https://code.visualstudio.com/docs/editor/tasks) and [keyboard shortcuts](https://code.visualstudio.com/docs/getstarted/keybindings). diff --git a/nx-dev/nx-dev/public/documentation/shared/continue-light.svg b/nx-dev/nx-dev/public/documentation/shared/continue-light.svg deleted file mode 100644 index 2563bfa114..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/continue-light.svg +++ /dev/null @@ -1,3 +0,0 @@ - - - diff --git a/nx-dev/nx-dev/public/documentation/shared/cypress-logo.png b/nx-dev/nx-dev/public/documentation/shared/cypress-logo.png deleted file mode 100644 index 6553e4a03e..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/cypress-logo.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/cypress-plugin.md b/nx-dev/nx-dev/public/documentation/shared/cypress-plugin.md deleted file mode 100644 index 1632e656bc..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/cypress-plugin.md +++ /dev/null @@ -1,100 +0,0 @@ -# Cypress Plugin - -![Cypress logo](/shared/cypress-logo.png) - -Cypress is an e2e test runner built for modern web. It has a lot of great features: - -- Time travel -- Real-time reloads -- Automatic waiting -- Spies, stubs, and clocks -- Network traffic control -- Screenshots and videos - -## Setting Up Cypress - -### Generating Applications - -By default, when creating a new frontend application, Nx will use Cypress to create the e2e tests project. - -```bash -nx g @nrwl/web:app frontend -``` - -### Creating a Cypress E2E project for an existing project - -You can create a new Cypress E2E project for an existing project. - -If the `@nrwl/cypress` package is not installed, install the version that matches your `@nrwl/workspace` version. - -```bash -yarn add --dev @nrwl/cypress -``` - -```bash -npm install --save-dev @nrwl/cypress -``` - -Next, generate an E2E project based on an existing project. - -```bash -nx g @nrwl/cypress:cypress-project your-app-name-e2e --project=your-app-name -``` - -Replace `your-app-name` with the app's name as defined in your `workspace.json` file. - -## Using Cypress - -### Testing Applications - -Simply run `nx e2e frontend-e2e` to execute e2e tests with Cypress. - -By default, Cypress will run in “headed” mode (you will see the tests executing in a new browser window). You will have the result of all the tests and errors (if any) in your terminal. - -Screenshots and videos will be accessible in `dist/apps/frontend/screenshots` and `dist/apps/frontend/videos`. - -### Watching for Changes - -With, `nx e2e frontend-e2e --watch` Cypress will start in the application mode. - -Running Cypress with `--watch` is a great way to enhance dev workflow - you can build up test files with the application running and Cypress will re-run those tests as you enhance and add to the suite. - -Cypress doesn't currently re-run your tests after changes are made to application code when it runs in “headed” mode. There is an [open feature request](https://github.com/nrwl/nx/issues/870) to add this behaviour. - -### Using Cypress in the Headless Mode - -If you want to run the Cypress tests in headless mode (e.g., on CI), you can do so by passing `--headless`. You will see all the test results live in the terminal. Videos and screenshots will be available for debugging. - -In headless mode your tests **will** be re-run every time you make a change to your application code. - -### Testing Against Prod Build - -You can run your e2e test against a production build like this: `nx e2e frontend-e2e --prod`. - -## Configuration - -### Specifying a Custom Url to Test - -The `baseUrl` property provides you the ability to test an application hosted on a specific domain. - -```bash -nx e2e frontend-e2e --baseUrl=https://frontend.com -``` - -> If no `baseUrl` and no `devServerTarget` are provided, Cypress will expect to have the `baseUrl` property in the `cypress.json` file, or will error. - -### Using cypress.json - -If you need to fine tune your Cypress setup, you can do so by modifying `cypress.json` in the e2e project. For instance, you can easily add your `projectId` to save all the screenshots and videos into your Cypress dashboard. The complete configuration is documented on [the official website](https://docs.cypress.io/guides/references/configuration.html#Options). - -## More Documentation - -React Nx Tutorial - -- [Step 2: Add E2E Tests](/react-tutorial/02-add-e2e-test) -- [Step 3: Display Todos](/react-tutorial/03-display-todos) - -Angular Nx Tutorial - -- [Step 2: Add E2E Tests](/angular-tutorial/02-add-e2e-test) -- [Step 3: Display Todos](/angular-tutorial/03-display-todos) diff --git a/nx-dev/nx-dev/public/documentation/shared/daemon.md b/nx-dev/nx-dev/public/documentation/shared/daemon.md deleted file mode 100644 index 706887d79b..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/daemon.md +++ /dev/null @@ -1,34 +0,0 @@ -# Nx Daemon - -In version 13 we introduced the opt-in Nx Daemon which Nx can leverage to dramatically speed up project graph computation, particularly for large workspaces. - -## Why is it needed? - -Every time you invoke a target directly, such as `nx test myapp`, or run affected commands, such `nx affected:test`, Nx first needs to generate a project graph in order to figure out how all the different projects and files within your workspace fit together. Naturally, the larger your workspace gets, the more expensive this project graph generation becomes. - -Thankfully, because Nx stores its metadata on disk, Nx only recomputes what has changed since the last command invocation. - -This helps quite a bit, but the recomputation is not very surgical because there is no way for Nx to know what kind of changes you have made, so it has to consider a wide range of possibilities when recomputing the project graph, even with the cache available. - -## What is Nx Daemon - -The Nx Daemon is a process which runs in the background on your local machine. There is one unique Nx Daemon per Nx workspace meaning if you have multiple Nx workspaces on your machine active at the same time, the corresponding Nx Daemon instances will operate independently of one another and can be on different versions of Nx. - -> On macOS and linux, the server runs as a unix socket, and on Windows it runs as a named pipe. - -The Nx Daemon is more efficient at recomputing the project graph because it watches the files in your workspaces and updates the project graph right away (intelligently throttling to ensure minimal recomputation). It also keeps everything in memory, so the response tends to be a lot faster. - -In order to be most efficient, the Nx Daemon has some built in mechanisms to automatically shut down (including removing all file watchers) when it is not needed. These include: - -- after 3 hours of inactivity (meaning the workspace's Nx Daemon did not receive any requests or detect any file changes in that time) -- when the Nx installation changes - -If you ever need to manually shut down the Nx Daemon, you can run `nx reset` within the workspace in question. - -## Turning it Off - -As of v13.6.0, the Nx Daemon is enabled by default. If you want to turn it off, simply set `useDaemonProcess: false` in the runners options in nx.json. You can also set the `NX_DAEMON` env variable to `false`. - -## Logs - -To see information about the running Nx Daemon (such as its background process ID and log output file), run `nx daemon --help`. Once you have the path to that log file, you could either open it in your IDE or stream updates in a separate terminal window by running `tail -f {REPLACE_WITH_LOG_PATH}`, for example. diff --git a/nx-dev/nx-dev/public/documentation/shared/dependency-graph.png b/nx-dev/nx-dev/public/documentation/shared/dependency-graph.png deleted file mode 100644 index e55f1a9227..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/dependency-graph.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/detox-logo.png b/nx-dev/nx-dev/public/documentation/shared/detox-logo.png deleted file mode 100644 index e09e2bf3c2..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/detox-logo.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/detox-plugin.md b/nx-dev/nx-dev/public/documentation/shared/detox-plugin.md deleted file mode 100644 index 7a23ea2667..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/detox-plugin.md +++ /dev/null @@ -1,102 +0,0 @@ -# Detox Plugin - -![Detox logo](/shared/detox-logo.png) - -Detox is gray box end-to-end testing and automation library for mobile apps. It has a lot of great features: - -- Cross Platform -- Runs on Devices -- Automatically Synchronized -- Test Runner Independent -- Debuggable - -## Setting Up Detox - -### Install applesimutils (Mac only) - -[applesimutils](https://github.com/wix/AppleSimulatorUtils) is a collection of utils for Apple simulators. - -```sh -brew tap wix/brew -brew install applesimutils -``` - -### Install Jest Globally - -```sh -npm install -g jest -``` - -### Generating Applications - -By default, when creating a mobile application, Nx will use Detox to create the e2e tests project. - -```bash -nx g @nrwl/react-native:app frontend -``` - -### Creating a Detox E2E project for an existing project - -You can create a new Detox E2E project for an existing mobile project. - -If the `@nrwl/detox` package is not installed, install the version that matches your `@nrwl/workspace` version. - -```sh -# yarn -yarn add --dev @nrwl/detox -``` - -```sh -# npm -npm install --save-dev @nrwl/detox -``` - -Next, generate an E2E project based on an existing project. - -```sh -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. - -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. - -## Using Detox - -### Testing Applications - -- Run `nx test-ios frontend-e2e` to build the iOS app and execute e2e tests with Detox for iOS (Mac only) -- Run `nx test-android frontend-e2e` to build the Android app and execute e2e tests with Detox for Android - -You can run below commands: - -- `nx build-ios frontend-e2e`: build the iOS app (Mac only) -- `nx build-android frontend-e2e`: build the Android app - -### Testing against Prod Build - -You can run your e2e test against a production build: - -- `nx test-ios frontend-e2e --prod`: to build the iOS app and execute e2e tests with Detox for iOS with Release configuration (Mac only) -- `nx test-android frontend-e2e`: rto build the Android app and execute e2e tests with Detox for Android with release build type -- `nx build-ios frontend-e2e --prod`: build the iOS app using Release configuration (Mac only) -- `nx build-android frontend-e2e --prod`: build the Android app using release build type - -## Configuration - -### Using .detoxrc.json - -If you need to fine tune your Detox setup, you can do so by modifying `.detoxrc.json` in the e2e project. - -#### Change Testing Simulator/Emulator - -For 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`. - -For Android, in terminal, run `emulator -list-avds` to view a list of emulators installed. To open your emulator, run `emulator -avd `. In `frontend-e2e/.detoxrc.json`, you could change the simulator under `devices.emulator.device`. - -In additon, to override the device name specified in a configuration, you could use `--device-name` option: `nx test-ios --device-name "iPhone 11"`. The `device-name` property provides you the ability to test an application run on specific device. - -```bash -nx test-ios frontend-e2e --device-name "iPhone 11" -nx test-android frontend-e2e --device-name "Pixel_4a_API_30" -``` diff --git a/nx-dev/nx-dev/public/documentation/shared/devkit-and-nx-plugins.md b/nx-dev/nx-dev/public/documentation/shared/devkit-and-nx-plugins.md deleted file mode 100644 index fada7965f9..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/devkit-and-nx-plugins.md +++ /dev/null @@ -1,74 +0,0 @@ -# Nx Plugins and Devkit - -Nx is a VSCode of build tools. The core of Nx enables project and task graph creation and analysis, orchestration and -execution of tasks, computation caching, and code generation. [Nx plugins](#nx-plugins) extend this functionality and are built on top of the underlying [Nx Devkit](#nx-devkit). - -> Many organizations use Nx without any plugins. If you are mainly interested in making your workspace faster or enabling distributed task execution, then plugins aren't necessary. - -## Nx plugins - -Nx plugins are npm packages that contain generators and executors to extend the capabilities of an Nx workspace. - -Plugins have: - -- **Generators** - - - Generators automate making changes to the file system. - - Anytime you run `nx generate ...`, you invoke a generator. - - They are used to create/update applications, libraries, components, and more. - -- **Executors** - - - Executors define how to perform an action on a project. - - You invoke an executor with `nx run ...` (or `nx test`, `nx build`). - - They are used to build applications and libraries, test them, lint them, and more. - -- **Project Graph Extensions** - - - Plugins can provide a function `processProjectGraph` to add extra edges to the project graph. - - This allows plugins to influence the behavior of `nx affected` and the project graph visualization. - - See [project graph plugins](/structure/project-graph-plugins) for more information. - -- **Project Inference Extensions** - - - 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 - targets without adding them into project configuration. - -All of the core plugins are written using Nx Devkit, and you can use the same utilities to write your own generators and -executors. - -The Nx team maintains a core set of plugins for many application and tooling frameworks. You can write [custom generators](/generators/workspace-generators) and [executors](/executors/creating-custom-builders) for your own workspace. You can also write your own plugin and share it with the community. The [Nx Plugin](/nx-plugin/overview) plugin provides guidance on how you can build your own custom plugins. - -### Listing Nx plugins - -Nx provides a list of installed and available plugins from Nrwl and community maintainers. Plugins maintained by Nrwl -maintained are scoped under the `@nrwl` organization. - -Use the `nx list` command to display all registered plugins. - -Using the `nx list [plugin]` command displays the generators and executors provided by that package. - -## Nx Devkit - -The Nx Devkit is the underlying technology used to customize Nx to support different technologies and custom use-cases. -It contains many utility functions for reading and writing files, updating configuration, working with Abstract Syntax -Trees (ASTs), and more. - -### Pay as you go - -As with most things in Nx, the core of Nx Devkit is very simple. It only uses language primitives and immutable -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 generators. - -## Learn more - -- [Using Nx Core Without Plugins](/getting-started/nx-core) -- [Workspace generators](/generators/workspace-generators) -- [Workspace executors](/executors/creating-custom-builders) -- [Nx Community Plugins](/community) diff --git a/nx-dev/nx-dev/public/documentation/shared/distributed-builds.md b/nx-dev/nx-dev/public/documentation/shared/distributed-builds.md deleted file mode 100644 index fa836afdf5..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/distributed-builds.md +++ /dev/null @@ -1,20 +0,0 @@ -# Distributed Builds and Distributed CI - -Nx uses computation caching and code change analysis (`affected:*` commands) to limit the number of things that have to be rebuilt and retested. This can drastically reduce the average CI time. - -But regardless of how smart Nx is, there will be some large changes affecting the whole codebase. The only way to keep those fast as your repository keeps growing is to build and test them using multiple machines/agents. - -There are several ways to distribute your CI across multiple machines. - -The easiest way is to use Nx Cloud. Learn more about [configuring your CI](https://nx.app/docs/configuring-ci) environment using Nx Cloud with [Distributed Caching](https://nx.app/docs/distributed-caching) and [Distributed Task Execution](https://nx.app/docs/distributed-execution) in the Nx Cloud docs. - -But you can also set up distribution manually using the `print-affected` and `run-many` commands. - -Please look at the following two examples: - -- [Example of setting up distributed Azure build for Nx workspace](https://github.com/nrwl/nx-azure-build) -- [Example of setting up distributed Jenkins build for Nx workspace](https://github.com/nrwl/nx-jenkins-build) - -The Azure example is very easy to port to other CI providers (e.g., CircleCI, GitLab). - -Read [Distributing CI: Binning and Distributed Task Execution](https://blog.nrwl.io/distributing-ci-binning-and-distributed-task-execution-632fe31a8953?source=friends_link&sk=5120b7ff982730854ed22becfe7a640a) to learn about the two approaches. diff --git a/nx-dev/nx-dev/public/documentation/shared/eslint-logo.png b/nx-dev/nx-dev/public/documentation/shared/eslint-logo.png deleted file mode 100644 index 28545772e7..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/eslint-logo.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/eslint-plugin-nx.md b/nx-dev/nx-dev/public/documentation/shared/eslint-plugin-nx.md deleted file mode 100644 index 843b0880f4..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/eslint-plugin-nx.md +++ /dev/null @@ -1,81 +0,0 @@ -# ESLint Plugin - -![ESLint logo](/shared/eslint-logo.png) - -A plugin containing a collection of recommended ESLint rule configurations wrapped as ESLint plugins and an Nx specific [enforce-module-boundaries](#enforce-module-boundaries) rule. - -## Setting Up ESLint Plugin - -### Installation - -In any Nx workspace, you can install `@nrwl/eslint-plugin-nx` by running the following commands if the package is not already installed: - -```bash -npm i --save-dev @nrwl/eslint-plugin-nx -``` - -```bash -yarn add --dev @nrwl/eslint-plugin-nx -``` - -## ESLint plugins - -The plugin contains the following rule configurations divided into sub-plugins. - -### JavaScript - -The `@nrwl/nx/javascript` ESLint plugin contains best practices when using JavaScript. - -### TypeScript - -The `@nrwl/nx/typescript` ESLint plugin contains best practices when using TypeSript. - -### Angular - -Contains configurations matching best practices when using Angular framework: - -- @nrwl/nx/angular -- @nrwl/nx/angular-template - -### React - -Contains configurations matching best practices when using React framework: - -- @nrwl/nx/react-base -- @nrwl/nx/react-jsx -- @nrwl/nx/react-typescript - -You can also use `@nrwl/nx/react` which includes all three `@nrwl/nx/react-*` plugins - -## enforce-module-boundaries - -The `@nrwl/nx/enforce-module-boundaries` ESLint rule enables you to define strict rules for accessing resources between different projects in the repository. By enforcing strict boundaries it helps keep prevent unplanned cross-dependencies. - -### Usage - -You can use `enforce-module-boundaries` rule by adding it to your ESLint rules configuration: - -```json -{ - // ... more ESLint config here - "overrides": [ - { - "files": ["*.ts", "*.tsx", "*.js", "*.jsx"], - "rules": { - "@nrwl/nx/enforce-module-boundaries": [ - "error", - { - // ...rule specific configuration - } - ] - } - } - // ... more ESLint overrides here - ] -} -``` - -Read more about proper usage of this rule: - -- [Imposing Constraints on the Project Graph](/structure/monorepo-tags) -- [Taming Code Organization with Module Boundaries in Nx](https://blog.nrwl.io/mastering-the-project-boundaries-in-nx-f095852f5bf4) diff --git a/nx-dev/nx-dev/public/documentation/shared/eslint.md b/nx-dev/nx-dev/public/documentation/shared/eslint.md deleted file mode 100644 index 544a45af31..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/eslint.md +++ /dev/null @@ -1,112 +0,0 @@ -# Using ESLint in Nx Workspaces - -## Rules requiring type information - -ESLint is powerful linter by itself, able to work on the syntax of your source files and assert things about based on the rules you configure. It gets even more powerful, however, when TypeScript type-checker is layered on top of it when analyzing TypeScript files, which is something that `@typescript-eslint` allows us to do. - -By default, Nx sets up your ESLint configs with performance in mind - we want your linting to run as fast as possible. Because creating the necessary so called TypeScript `Program`s required to create the type-checker behind the scenes is relatively expensive compared to pure syntax analysis, you should only configure the `parserOptions.project` option in your project's `.eslintrc.json` when you need to use rules requiring type information (and you should not configure `parserOptions.project` in your workspace's root `.eslintrc.json`). - -Let's take an example of an ESLint config that Nx might generate for you out of the box for a Next.js project called `tuskdesk`: - -**apps/tuskdesk/.eslintrc.json** - -```jsonc -{ - "extends": ["plugin:@nrwl/nx/react", "../../.eslintrc.json"], - "ignorePatterns": ["!**/*"], - "overrides": [ - { - "files": ["*.ts", "*.tsx", "*.js", "*.jsx"], - "rules": {} - }, - { - "files": ["*.ts", "*.tsx"], - "rules": {} - }, - { - "files": ["*.js", "*.jsx"], - "rules": {} - } - ] -} -``` - -Here we do _not_ have `parserOptions.project`, which is appropriate because we are not leveraging any rules which require type information. - -If we now come in and add a rule which does require type information, for example `@typescript-eslint/await-thenable`, our config will look as follows: - -**apps/tuskdesk/.eslintrc.json** - -```jsonc -{ - "extends": ["plugin:@nrwl/nx/react", "../../.eslintrc.json"], - "ignorePatterns": ["!**/*"], - "overrides": [ - { - "files": ["*.ts", "*.tsx", "*.js", "*.jsx"], - "rules": { - // This rule requires the TypeScript type checker to be present when it runs - "@typescript-eslint/await-thenable": "error" - } - }, - { - "files": ["*.ts", "*.tsx"], - "rules": {} - }, - { - "files": ["*.js", "*.jsx"], - "rules": {} - } - ] -} -``` - -Now if we try and run `nx lint tuskdesk` we will get an error - -```bash -> nx run tuskdesk:lint - -Linting "tuskdesk"... - - Error: You have attempted to use a lint rule which requires the full - TypeScript type-checker to be available, but you do not have - `parserOptions.project` configured to point at your project - tsconfig.json files in the relevant TypeScript file "overrides" - block of your project ESLint config `apps/tuskdesk/.eslintrc.json` - -``` - -The solution is to update our config once more, this time to set `parserOptions.project` to appropriately point at our various tsconfig.json files which belong to our project: - -**apps/tuskdesk/.eslintrc.json** - -```jsonc -{ - "extends": ["plugin:@nrwl/nx/react", "../../.eslintrc.json"], - "ignorePatterns": ["!**/*"], - "overrides": [ - { - "files": ["*.ts", "*.tsx", "*.js", "*.jsx"], - // We set parserOptions.project for the project to allow TypeScript to create the type-checker behind the scenes when we run linting - "parserOptions": { - "project": ["apps/tuskdesk/tsconfig.*?.json"] - }, - "rules": { - "@typescript-eslint/await-thenable": "error" - } - }, - { - "files": ["*.ts", "*.tsx"], - "rules": {} - }, - { - "files": ["*.js", "*.jsx"], - "rules": {} - } - ] -} -``` - -And that's it! Now any rules requiring type information will run correctly when we run `nx lint tuskdesk`. - -> NOTE: As well as adapting the path to match your project's real path, please be aware that if you apply the above to a **Next.js** application, you should change the glob pattern at the end to be `tsconfig(.*)?.json`. E.g. if `tuskdesk` had been a Next.js app, we would have written: `"project": ["apps/tuskdesk/tsconfig(.*)?.json"]` diff --git a/nx-dev/nx-dev/public/documentation/shared/examples/apollo-react.md b/nx-dev/nx-dev/public/documentation/shared/examples/apollo-react.md deleted file mode 100644 index e3aa0cbe28..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/examples/apollo-react.md +++ /dev/null @@ -1,12 +0,0 @@ -# Using Apollo GraphQL with React in an Nx Workspace - -In this article, you’ll learn how to: - -- Create an Nx workspace for both frontend and backend applications -- Create a GraphQL API using NestJS -- Autogenerate frontend code based on your GraphQL schema -- Create a React application to consume your GraphQL api - -**Blog Post:** [Using Apollo GraphQL with React in an Nx Workspace](https://blog.nrwl.io/using-apollo-graphql-with-react-in-an-nx-workspace-99db8d69cebe) - -**Repository:** [nx-apollo-react-example](https://github.com/nrwl/nx-apollo-react-example) diff --git a/nx-dev/nx-dev/public/documentation/shared/examples/caching.md b/nx-dev/nx-dev/public/documentation/shared/examples/caching.md deleted file mode 100644 index e26cd4ed22..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/examples/caching.md +++ /dev/null @@ -1,10 +0,0 @@ -# File Large Next.js Apps Made Faster by Using Nx - -Repo contains: - -- 5 shared buildable packages/libraries with 250 components each -- 5 Next.js applications built out of 20 app-specific libraries. Each app-specific lib has 250 components each. Each library uses the shared components. - -The repo shows how Nx works in a large workspace. It also benchmarks Nx and explains the optimisations Nx uses to be fast. - -**Repository:** [vsavkin/large-monorepo](https://github.com/vsavkin/large-monorepo) diff --git a/nx-dev/nx-dev/public/documentation/shared/examples/dte.md b/nx-dev/nx-dev/public/documentation/shared/examples/dte.md deleted file mode 100644 index 70f151d9e6..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/examples/dte.md +++ /dev/null @@ -1,10 +0,0 @@ -# Distributed Task Execution at Scale - -Repo contains: - -- 5 shared buildable packages/libraries with 250 components each -- 5 Next.js applications built out of 20 app-specific libraries. Each app-specific lib has 250 components each. Each library uses the shared components. - -The repo shows how Nx distributed task execution can make the CI 16 times faster with a small configuration change. - -**Repository:** [vsavkin/interstellar](https://github.com/vsavkin/interstellar) diff --git a/nx-dev/nx-dev/public/documentation/shared/examples/nx-examples.md b/nx-dev/nx-dev/public/documentation/shared/examples/nx-examples.md deleted file mode 100644 index fc01b63367..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/examples/nx-examples.md +++ /dev/null @@ -1,9 +0,0 @@ -# Nx Micro-Frontend Example - -This repository contains a single book store website that serves a React app for some routes and an Angular app for other routes. Both apps make use of web components to share UI. - -The repository is kept up to date with the latest version of Nx and is used as a smoke test for migrations to new versions of Nx. - -**Repository:** [nx-examples](https://github.com/nrwl/nx-examples) - -**Live Demo:** [Nx Store](https://nrwl-nx-examples-cart.netlify.app/cart) diff --git a/nx-dev/nx-dev/public/documentation/shared/examples/react-nx.md b/nx-dev/nx-dev/public/documentation/shared/examples/react-nx.md deleted file mode 100644 index 69add2be32..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/examples/react-nx.md +++ /dev/null @@ -1,12 +0,0 @@ -# Powering Up React Development With Nx - -Learn to: - -- Generate a new React monorepo workspace with one application. -- Add new feature libraries and route to them from our application. -- Create React components with a generator -- Generate a NestJS app in the same monorepo - -**Blog post:** [Powering Up React Development With Nx](https://blog.nrwl.io/powering-up-react-development-with-nx-cf0a9385dbec) - -**Repository:** [nrwl/react-nx-example](https://github.com/nrwl/react-nx-example) diff --git a/nx-dev/nx-dev/public/documentation/shared/express-logo.png b/nx-dev/nx-dev/public/documentation/shared/express-logo.png deleted file mode 100644 index 19ef2ea19e..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/express-logo.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/express-plugin.md b/nx-dev/nx-dev/public/documentation/shared/express-plugin.md deleted file mode 100644 index fb545a0dbc..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/express-plugin.md +++ /dev/null @@ -1,88 +0,0 @@ -# Express Plugin - -![Express Logo](/shared/express-logo.png) - -[Express](https://expressjs.com/) is mature, minimal, and an open source web framework for making web applications and -apis. - -## Setting Up Express - -To create a new workspace with Express, run the following command: - -```shell - npx create-nx-workspace --preset=express -``` - -### Adding Express to an Existing Project - -Install the express plugin - -```shell -npm install --save-dev @nrwl/express -``` - -```shell -yarn add --dev @nrwl/express -``` - -## Creating Applications - -Add a new application to your workspace with the following command: - -```shell -nx g @nrwl/express:app my-app -``` - -Serve the application by running - -```shell -nx serve my-app -``` - -This starts the application on localhost:3333/api by default. - -> Express does not come with any library generators, but you can leverage the[`@nrwl/js`](/js/overview#create-libraries) plugin to generate a Node.js library for your express application. - -### Application Proxies - -The Express application generator 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. - -```shell -nx g @nrwl/express:app --frontendProject my-react-app -``` - -## Using Express - -### Testing Projects - -You can run unit tests with: - -```shell -nx test -``` - -### Building Projects - -Express projects can be built with: - -```shell -nx build -``` - -Build artifacts will be found in the `dist` directory under `apps/` by default. Customize the build -configuration by editing `outputPath` in the [project configuration](/configuration/projectjson). - -### Waiting for Other Tasks - -You can wait for other tasks to run before serving the express app which can be handy for spinning up various services -the application depends on— for example, other apis in a microservice. - -Setting the `waitUntilTargets` option with an array of targets (format: `"project:target"`) executes those tasks -before serving the Express application. - -## More Documentation - -- [Using Jest](/jest/overview) -- [@nrwl/js](/js/overview) -- [Express](https://expressjs.com/) diff --git a/nx-dev/nx-dev/public/documentation/shared/folder-light.svg b/nx-dev/nx-dev/public/documentation/shared/folder-light.svg deleted file mode 100644 index 8daecdac6a..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/folder-light.svg +++ /dev/null @@ -1,3 +0,0 @@ - - - diff --git a/nx-dev/nx-dev/public/documentation/shared/generators/composing-generators.md b/nx-dev/nx-dev/public/documentation/shared/generators/composing-generators.md deleted file mode 100644 index 21b3dfb4c0..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/generators/composing-generators.md +++ /dev/null @@ -1,42 +0,0 @@ -# Composing Generators - -Generators are useful individually, but reusing and composing generators allows you to build whole workflows out of simpler building blocks. - -## Using Nx Devkit Generators - -Nx Devkit generators can be imported and invoked like any javascript function. They often return a `Promise`, so they can be used with the `await` keyword to mimic synchronous code. Because this is standard javascript, control flow logic can be adjusted with `if` blocks and `for` loops as usual. - -```typescript -import { libraryGenerator } from '@nrwl/workspace'; - -export default async function (tree: Tree, schema: any) { - await libraryGenerator( - tree, // virtual file system tree - { name: schema.name } // options for the generator - ); -} -``` - -## Using jscodeshift Codemods - -Codemods created for use with [`jscodeshift`](https://github.com/facebook/jscodeshift) can be used within Nx Devkit generators using the `visitNotIgnoredFiles` helper function. This way you can compose codemods with other generators while retaining `--dry-run` and Nx Console compatibilities. - -```typescript -import { Tree, visitNotIgnoredFiles } from '@nrwl/devkit'; -import { applyTransform } from 'jscodeshift/src/testUtils'; -import arrowFunctionsTransform from './arrow-functions'; - -// The schema path can be an individual file or a directory -export default async function (tree: Tree, schema: { path: string }): any { - visitNotIgnoredFiles(tree, schema.path, (filePath) => { - const input = tree.read(filePath).toString(); - const transformOptions = {}; - const output = applyTransform( - { default: arrowFunctionsTransform, parser: 'ts' }, - transformOptions, - { source: input, path: filePath } - ); - tree.write(filePath, output); - }); -} -``` diff --git a/nx-dev/nx-dev/public/documentation/shared/generators/creating-files.md b/nx-dev/nx-dev/public/documentation/shared/generators/creating-files.md deleted file mode 100644 index e1b4f7c187..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/generators/creating-files.md +++ /dev/null @@ -1,146 +0,0 @@ -# Creating files with a generator - -Generators provide an API for managing files within your workspace. You can use generators to do things such as create, update, move, and delete files. Files with static or dynamic content can also be created. - -The generator below shows you how to generate a library, and then scaffold out additional files with the newly created library. - -First, you define a folder to store your static or dynamic templates used to generated files. This is commonly done in a `files` folder. - -```treeview -happynrwl/ -├── apps/ -├── libs/ -├── tools/ -│ ├── generators -│ | └── my-generator/ -│ | | └── files -│ | | └── NOTES.md -│ | | ├── index.ts -│ | | └── schema.json -├── nx.json -├── package.json -└── tsconfig.base.json -``` - -The files can use EJS syntax to substitute variables and logic. See the [EJS Docs](https://ejs.co/) to see more information about how to write these template files. - -Example NOTES.md: - -```markdown -Hello, my name is <%= name %>! -``` - -Next, update the `index.ts` file for the generator, and generate the new files. - -```typescript -import { - Tree, - formatFiles, - installPackagesTask, - generateFiles, - joinPathFragments, - readProjectConfiguration, -} from '@nrwl/devkit'; -import { libraryGenerator } from '@nrwl/workspace'; - -export default async function (tree: Tree, schema: any) { - await libraryGenerator(tree, { name: schema.name }); - const libraryRoot = readProjectConfiguration(tree, schema.name).root; - generateFiles( - tree, // the virtual file system - joinPathFragments(__dirname, './files'), // path to the file templates - libraryRoot, // destination path of the files - schema // config object to replace variable in file templates - ); - await formatFiles(tree); - return () => { - installPackagesTask(tree); - }; -} -``` - -The exported function first creates the library, then creates the additional files in the new library's folder. - -Next, run the generator: - -> Use the `-d` or `--dry-run` flag to see your changes without applying them. - -```bash -nx workspace-generator my-generator mylib -``` - -The following information will be displayed. - -```bash -CREATE libs/mylib/README.md -CREATE libs/mylib/.babelrc -CREATE libs/mylib/src/index.ts -CREATE libs/mylib/src/lib/mylib.spec.ts -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.js -CREATE libs/mylib/tsconfig.spec.json -UPDATE jest.config.js -CREATE libs/mylib/NOTES.md -``` - -`libs/mylib/NOTES.md` will contain the content with substituted variables: - -```markdown -Hello, my name is mylib! -``` - -## Dynamic File Names - -If you want the generated file or folder name to contain variable values, use `__variable__`. So `NOTES-for-__name__.md` would be resolved to `NOTES_for_mylib.md` in the above example. - -## EJS Syntax Quickstart - -The [EJS syntax](https://ejs.co/) can do much more than replace variable names with values. Here are some common techniques. - -1. Pass a function into the template: - -```typescript -// template file -This is my <%= uppercase(name) %> -``` - -```typescript -// typescript file -function uppercase(val: string) { - return val.toUpperCase(); -} - -// later - -generateFiles(tree, joinPathFragments(__dirname, './files'), libraryRoot, { - uppercase, - name: schema.name, -}); -``` - -2. Use javascript for control flow in the template: - -```typescript -<% if(shortVersion) { %> -This is the short version. -<% } else { - for(let x=0; x - This text will be repeated <%= numRepetitions %> times. -<% } // end for loop -} // end else block %> -``` - -```typescript -// typescript file -generateFiles(tree, joinPathFragments(__dirname, './files'), libraryRoot, { - shortVersion: false, - numRepetitions: 3, -}); -``` diff --git a/nx-dev/nx-dev/public/documentation/shared/generators/generator-options.md b/nx-dev/nx-dev/public/documentation/shared/generators/generator-options.md deleted file mode 100644 index fe7c13fce5..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/generators/generator-options.md +++ /dev/null @@ -1,905 +0,0 @@ -# Customizing generator options - -## Adding a TypeScript schema - -To create a TypeScript schema to use in your generator function, define a TypeScript file next to your schema.json named `schema.ts`. Inside the `schema.ts`, define an interface to match the properties in your schema.json file, and whether they are required. - -```typescript -export interface GeneratorOptions { - name: string; - type?: string; -} -``` - -Import the TypeScript schema into your generator file and replace the any in your generator function with the interface. - -```typescript -import { Tree, formatFiles, installPackagesTask } from '@nrwl/devkit'; -import { libraryGenerator } from '@nrwl/workspace'; - -export default async function (tree: Tree, schema: GeneratorOptions) { - await libraryGenerator(tree, { name: `${schema.name}-${schema.type || ''}` }); - await formatFiles(tree); - return () => { - installPackagesTask(tree); - }; -} -``` - -## Adding static options - -Static options for a generator don't prompt the user for input. To add a static option, define a key in the schema.json file with the option name, and define an object with its type, description, and optional default value. - -```json -{ - "$schema": "http://json-schema.org/schema", - "id": "my-generator", - "type": "object", - "properties": { - "name": { - "type": "string", - "description": "Library name", - "$default": { - "$source": "argv", - "index": 0 - } - }, - "type": { - "type": "string", - "description": "Provide the library type, such as 'data-access' or 'state'" - } - }, - "required": ["name"] -} -``` - -If you run the generator without providing a value for the type, it is not included in the generated name of the library. - -## Adding dynamic prompts - -Dynamic options can prompt the user to select from a list of options. To define a prompt, add a `x-prompt` property to the option object, set the type to list, and define an items array for the choices. - -```json -{ - "$schema": "http://json-schema.org/schema", - "id": "my-generator", - "type": "object", - "properties": { - "name": { - "type": "string", - "description": "Library name", - "$default": { - "$source": "argv", - "index": 0 - } - }, - "type": { - "type": "string", - "description": "Provide the library type", - "x-prompt": { - "message": "Which type of library would you like to generate?", - "type": "list", - "items": [ - { - "value": "data-access", - "label": "Data Access" - }, - { - "value": "feature", - "label": "Feature" - }, - { - "value": "state", - "label": "State Management" - } - ] - } - } - }, - "required": ["name"] -} -``` - -Running the generator without providing a value for the type will prompt the user to make a selection. - -## All configurable schema options - -Properties tagged with ⚠️ are required. Others are optional. - -### Schema - -```json -{ - "properties": { - "name": {} // see Properties - }, - "required": [], - "description": "", - "definitions": {}, // same as "properties" - "additionalProperties": false -} -``` - -#### ⚠️ `properties` - -The properties of a generator. Properties are listed by name: - -```json -{ - "properties_name": { - // properties configuration - } -} -``` - -The available options of the properties' configuration can be -seen in the [Properties](#properties) section. - -#### `required` - -The property keys that are required. Example: - -```json -{ - "properties": { - "name": { - "type": "string" - }, - "type": { - "type": "string" - } - }, - "required": ["name"] -} -``` - -In this example, the property `name` is required, while the property `type` is optional. -You can define your TypeScript schema like this: - -```ts -interface Schema { - name: string; // required - type?: string; // optional -} -``` - -#### `description` - -The description of your schema for users to understand -what they can do with the generator. - -Example: `A exception class generator.` - -#### `definitions` - -Define an auxiliary schema in order to be reused and combined later on. Examples: - -```json -{ - "$id": "https://example.com/schemas/customer", - "$schema": "https://json-schema.org/draft/2020-12/schema", - - "type": "object", - "properties": { - "first_name": { "type": "string" }, - "last_name": { "type": "string" }, - "shipping_address": { "$ref": "/schemas/address" }, - "billing_address": { "$ref": "/schemas/address" } - }, - "required": [ - "first_name", - "last_name", - "shipping_address", - "billing_address" - ], - - "$defs": { - "address": { - "$id": "/schemas/address", - "$schema": "http://json-schema.org/draft-07/schema#", - - "type": "object", - "properties": { - "street_address": { "type": "string" }, - "city": { "type": "string" }, - "state": { "$ref": "#/definitions/state" } - }, - "required": ["street_address", "city", "state"], - - "definitions": { - "state": { "enum": ["CA", "NY", "... etc ..."] } - } - } - } -} -``` - -In this example, we defined the `state` in the `definitions` and -reference it later by `$ref`. - -> Reference 1: [JSON Schema > Definitions & References](https://cswr.github.io/JsonSchema/spec/definitions_references/) -> -> Reference 2: [Understanding JSON Schema > Extending Recursive Schemas](https://json-schema.org/understanding-json-schema/structuring.html?highlight=definitions#bundling) - -#### `additionalProperties` - -Specify whether the additional properties in the input are allowed. Example: - -```json -{ - "type": "object", - "properties": { - "number": { "type": "number" }, - "street_name": { "type": "string" }, - "street_type": { "enum": ["Street", "Avenue", "Boulevard"] } - }, - "additionalProperties": false -} -``` - -In this example, this schema only accepts the properties that are explicitly defined in the `properties` object such like: - -```json -{ "number": 1600, "street_name": "Pennsylvania", "street_type": "Avenue" } -``` - -Any additional properties will be considered invalid. - -```json -{ - "number": 1600, - "street_name": "Pennsylvania", - "street_type": "Avenue", - "direction": "NW" -} -``` - -> The above examples are from [Understanding JSON schema > Additional Properties](https://json-schema.org/understanding-json-schema/reference/object.html#additional-properties). -> There are more details in that tutorial. - -### Properties - -```json -{ - "type": "", - "required": [], - "enum": [], - "properties": {}, - "oneOf": [], - "anyOf": [], - "allOf": [], - "items": [], - "alias": "", - "aliases": [], - "description": "", - "format": "", - "visible": false, - "default": "", - "$ref": "", - "$default": { - "$source": "argv", - "index": 0 - }, - "additionalProperties": false, - "x-prompt": { - "message": "", - "type": "", - "items": [], - "multiselect": false - }, - "x-deprecated": false -} -``` - -Options available in `number` type: - -```json -{ - "multipleOf": 5, - "minimum": 5, - "exclusiveMinimum": 4, - "maximum": 200, - "exclusiveMaximum": 201 -} -``` - -Options available in `string` type: - -```json -{ - "pattern": "\\d+", - "minLength": 10, - "maxLength": 100 -} -``` - -#### `type` - -The type of the input. Can be one of `string`, `number`, `bigint`, `boolean`, `object` or `array`. - -Example: - -```json -{ - "type": "string", - "minLength": "10" -} -``` - -#### `required` - -The property keys that are required. Example: - -```json -{ - "properties": { - "a": { - "type": "boolean" - }, - "b": { - "type": "boolean" - } - }, - "required": ["a"] -} -``` - -In this example, the property `a` is required, while the property `b` is optional. - -#### `enum` - -Make sure that the value is in the enumeration. Example: - -```json -{ - "type": "string", - "enum": ["foo", "bar"] - - // valid case: `foo`, `bar` - // invalid case: any other string like `hello` -} -``` - -#### `properties` - -The sub-properties of a property. Example: - -```json -{ - "index": { - "description": "Configures the generation of the application's HTML index.", - "type": "object", - "description": "", - "properties": { - "input": { - "type": "string", - "minLength": 1, - "description": "The path of a file to use for the application's generated HTML index." - }, - "output": { - "type": "string", - "minLength": 1, - "default": "index.html", - "description": "The output path of the application's generated HTML index file. The full provided path will be used and will be considered relative to the application's configured output path." - } - }, - "required": ["input"] - } -} -``` - -In this example, the property `index` is a `object`, which accepts two properties: `input` and `output`. - -#### `oneOf` - -Only accepts a value that matches one of the condition properties. Example: - -```json -{ - "sourceMap": { - "description": "Output sourcemaps. Use 'hidden' for use with error reporting tools without generating sourcemap comment.", - "default": true, - "oneOf": [ - { - "type": "boolean" - }, - { - "type": "string" - } - ] - } -} -``` - -In this example, `sourceMap` accepts a value whose type is either `boolean` or `string`. Another example: - -```json -{ - "optimization": { - "description": "Enables optimization of the build output.", - "oneOf": [ - { - "type": "object", - "properties": { - "scripts": { - "type": "boolean", - "description": "Enables optimization of the scripts output.", - "default": true - }, - "styles": { - "type": "boolean", - "description": "Enables optimization of the styles output.", - "default": true - } - }, - "additionalProperties": false - }, - { - "type": "boolean" - } - ] - } -} -``` - -`optimization` accepts either an object that includes `scripts` and `styles` properties, or a boolean that switches the optimization on or off. - -#### `anyOf` - -Only accepts a value that matches one of the condition properties. Example: - -```json -{ - "format": { - "type": "string", - "description": "ESLint Output formatter (https://eslint.org/docs/user-guide/formatters).", - "default": "stylish", - "anyOf": [ - { - "enum": [ - "stylish", - "compact", - "codeframe", - "unix", - "visualstudio", - "table", - "checkstyle", - "html", - "jslint-xml", - "json", - "json-with-metadata", - "junit", - "tap" - ] - }, - { "minLength": 1 } - ] - } -} -``` - -In this example, `format` accepts a string listed in the `enum` property, and/or a string whose minimum length is larger than 1. - -#### `allOf` - -Only accepts a value that matches all the condition properties. Example: - -```json -{ - "a": { - "type": "number", - "allOf": [{ "multipleOf": 5 }, { "multipleOf": 3 }] - } -} -``` - -In this example, `a` only accepts a value that can be divided by 5 **and** 3. - -#### `alias` - -The alias of this property. Example: - -```json -{ - "tags": { - "type": "string", - "description": "Add tags to the project (used for linting)", - "alias": "t" - }, - "directory": { - "type": "string", - "description": "A directory where the project is placed", - "alias": "d" - } -} -``` - -You can pass either `--tags` or `-t` to provide the value of the property `tag`; either `--directory` or `-d` to provide the value of the property `directory`. - -#### `aliases` - -Mostly same as `alias`, but it can accept multiple aliases. Example: - -```json -{ - "directory": { - "description": "Directory where the generated files are placed.", - "type": "string", - "aliases": ["dir", "path"] - } -} -``` - -You can pass either `--dir`, `--path` or even `--directory` to provide the value of the property `directory`. - -#### `description` - -The description for users of your property. Example: - -```json -{ - "flat": { - "description": "Flag to indicate if a directory is created.", - "type": "boolean", - "default": false - } -} -``` - -#### `format` - -The format of this property. Available options are: `path`, `html-selector`, etc. Example: - -```json -{ - "prefix": { - "type": "string", - "format": "html-selector", - "description": "The prefix to apply to generated selectors.", - "alias": "p" - } -} -``` - -In this example, the value provided for `prefix` should be formatted using the `html-selector` schema. - -#### `visible` - -Indicate whether the property should be visible in the configuration UI. Example: - -```json -{ - "path": { - "format": "path", - "visible": false - } -} -``` - -In this example, the `path` won't be visible in the configuration UI, and will apply a default value. - -#### `default` - -The default value of this property. Example: - -```json -{ - "linter": { - "description": "The tool to use for running lint checks.", - "type": "string", - "enum": ["eslint", "tslint"], - "default": "eslint" - } -} -``` - -In this example, `linter` will pick `eslint` when users do not provide the value explicitly. - -#### `$ref` - -Reference to a schema. Examples can be seen in the [`definitions`](#definitions) section. - -#### `$default` - -The default source of this property. The full declaration of `$default` is: - -```ts -// with ? - optional -// without ? - required -// | - or -$default?: { $source: 'argv'; index: number } | { $source: 'projectName' }; -``` - -Example of `$source: argv`: - -```json -{ - "name": { - "type": "string", - "description": "Library name", - "$default": { - "$source": "argv", - "index": 0 - }, - "x-prompt": "What name would you like to use for the library?", - "pattern": "^[a-zA-Z].*$" - } -} -``` - -`name` will pick the first argument of the command line as the default value. - -Example of `$source: projectName`: - -```json -{ - "project": { - "type": "string", - "description": "The name of the project.", - "alias": "p", - "$default": { - "$source": "projectName" - }, - "x-prompt": "What is the name of the project for the migration?" - } -} -``` - -`project` will pick the default project name as the default value. - -#### `additionalProperties` - -See [the above `additionalProperties` section](#additionalproperties). - -#### `x-prompt` - -Prompt and help user to input the value of the property. It can be a `string` or a `object`. The full declaration is: - -```ts -// with ? - optional -// without ? - required -// | - or -'x-prompt'?: - | string - | { message: string; type: string; items: any[]; multiselect?: boolean }; -``` - -The string `x-prompt` example: - -```json -{ - "name": { - "type": "string", - "description": "Library name", - "$default": { - "$source": "argv", - "index": 0 - }, - "x-prompt": "What is your desired library name?" - } -} -``` - -The object example can be seen at [Adding dynamic prompts](#adding-dynamic-prompts). - -##### ⚠️ `x-prompt` > `message` - -The prompt message. - -Example: `Which type of library would you like to generate?` - -##### ⚠️ `x-prompt` > `type` - -The type of the prompt. - -##### ⚠️ `x-prompt` > `items` - -The choice of the prompt. The `x-prompt.type` must be `list`. The declaration of `items` is: - -```ts -// with ? - optional -// without ? - required -// | - or -items?: (string | { name: string; message: string })[]; -``` - -Example that contains `value` and `label`: - -```json -{ - "style": { - "description": "The file extension to be used for style files.", - "type": "string", - "default": "css", - "enum": ["css", "scss", "sass", "less"], - "x-prompt": { - "message": "Which stylesheet format would you like to use?", - "type": "list", - "items": [ - { - "value": "css", - "label": "CSS" - }, - { - "value": "scss", - "label": "SASS(.scss) [ http://sass-lang.com ]" - }, - { - "value": "sass", - "label": "SASS(.sass) [ http://sass-lang.com ]" - }, - { - "value": "less", - "label": "LESS [ http://lesscss.org ]" - } - ] - } - } -} -``` - -##### `x-prompt` > `multiselect` - -Allow to multi-select in the prompt. - -#### `x-deprecated` - -Indicate whether the property is deprecated. Can be a `boolean` or a `string`. The `boolean` example: - -```json -{ - "setupFile": { - "description": "The name of a setup file used by Jest. (use Jest config file https://jestjs.io/docs/en/configuration#setupfilesafterenv-array)", - "type": "string", - "x-deprecated": true - } -} -``` - -This indicates that the property `setupFile` is deprecated without a reason. The `string` example: - -```json -{ - "tsSpecConfig": { - "type": "string", - "description": "The tsconfig file for specs.", - "x-deprecated": "Use the `tsconfig` property for `ts-jest` in the e2e project `jest.config.js` file. It will be removed in the next major release." - } -} -``` - -This indicates that users should use the `tsconfig` property rather than specify this property. - -#### `number` specific: `multipleOf` - -Make sure that the number can be divided by the specified number. Example: - -```json -{ - "a": { - "type": "number", - "multipleOf": 5 - } -} -``` - -In this example, `a` **only** accepts the value that can be divided by 5. - -#### `number` specific: `minimum` - -Make sure that the number is greater than or equal to the specified number. - -```json -{ - "value": { - "type": "number", - "minimum": 5 - } -} -``` - -In this example, `value` **only** accepts a value that is greater than or equal to 5 (`value >= 5`). - -You can read more at [Understanding JSON schema](https://json-schema.org/understanding-json-schema/reference/numeric.html#range). - -#### `number` specific: `exclusiveMinimum` - -Make sure that the number is greater than the specified number. - -```json -{ - "value": { - "type": "number", - "exclusiveMinimum": 4 - } -} -``` - -In this example, `value` **only** accepts a value that is greater than 4 (`value > 4`). - -You can read more at [Understanding JSON schema](https://json-schema.org/understanding-json-schema/reference/numeric.html#range). - -#### `number` specific: `maximum` - -Make sure that the number is less than or equal to the specified number. - -```json -{ - "value": { - "type": "number", - "maximum": 200 - } -} -``` - -In this example, `value` **only** accepts a value that is less than or equal to 200 (`value <= 200`). - -You can read more at [Understanding JSON schema](https://json-schema.org/understanding-json-schema/reference/numeric.html#range). - -#### `number` specific: `exclusiveMaximum` - -Make sure that the number is less than the specified number. - -```json -{ - "value": { - "type": "number", - "maximum": 201 - } -} -``` - -In this example, `value` **only** accepts a value that is less than 201 (`value < 201`). - -You can read more at [Understanding JSON schema](https://json-schema.org/understanding-json-schema/reference/numeric.html#range). - -#### `string` specific: `pattern` - -Make sure that the string matches the Regexp pattern. - -```json -{ - "value": { - "type": "string", - "pattern": "^\\d+$" - } -} -``` - -In this example, `value` requires the value to match the `^\\d+$` pattern, which is a regular expression that matches a string that contains only digits. - -#### `string` specific: `minLength` - -Make sure that the string length is greater than or equal to the specified value. - -```json -{ - "value": { - "type": "string", - "minLength": 10 - } -} -``` - -In this example, `value` requires the value to be at least 10 characters long. - -#### `string` specific: `maxLength` - -Make sure that the string length is less than or equal to the specified value. - -```json -{ - "value": { - "type": "string", - "maxLength": 10 - } -} -``` - -In this example, `value` requires the value to be at most 10 characters long. - -### More information - -[The current configurable options (and its parse method) can be found here](https://github.com/nrwl/nx/blob/master/packages/tao/src/shared/params.ts). You would need a basic knowledge of TypeScript to read this. - -Most examples are referenced from the codebase of Nx. Thanks to everyone who have ever contributed to Nx! diff --git a/nx-dev/nx-dev/public/documentation/shared/generators/modifying-files.md b/nx-dev/nx-dev/public/documentation/shared/generators/modifying-files.md deleted file mode 100644 index ceb5f4bb26..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/generators/modifying-files.md +++ /dev/null @@ -1,132 +0,0 @@ -# Modifying Files with a Generator - -Modifying existing files is an order of magnitude harder than creating new files, so care should be taken when trying to automate this process. When the situation merits it, automating a process can lead to tremendous benefits across the organization. Here are some approaches listed from simplest to most complex. - -## Compose Existing Generators - -If you can compose together existing generators to modify the files you need, you should take that approach. See [Composing Generators](./composing-generators) for more information. - -## Modify JSON Files - -JSON files are fairly simple to modify, given their predictable structure. - -The following example adds a `package.json` script that issues a friendly greeting. - -```typescript -import { updateJson } from '@nrwl/devkit'; - -export default async function (tree: Tree, schema: any) { - updateJson(tree, 'package.json', (pkgJson) => { - // if scripts is undefined, set it to an empty object - pkgJson.scripts = pkgJson.scripts ?? {}; - // add greet script - pkgJson.scripts.greet = 'echo "Hello!"'; - // return modified JSON object - return pkgJson; - }); -} -``` - -## String Replace - -For files that are not as predictable as JSON files (like `.ts`, `.md` or `.css` files), modifying the contents can get tricky. One approach is to do a find and replace on the string contents of the file. - -Let's say we want to replace any instance of `thomasEdison` with `nikolaTesla` in the `index.ts` file. - -```typescript -export default async function (tree: Tree, schema: any) { - const filePath = `path/to/index.ts`; - const contents = tree.read(filePath); - contents.replace('thomasEdison', 'nikolaTesla'); - tree.write(filePath, contents); -} -``` - -This works, but only replaces the first instance of `thomasEdison`. To replace them all, you need to use regular expressions. (Regular expressions also give you a lot more flexibility in how you search for a string.) - -```typescript -export default async function (tree: Tree, schema: any) { - const filePath = `path/to/index.ts`; - const contents = tree.read(filePath); - contents.replace(/thomasEdison/g, 'nikolaTesla'); - tree.write(filePath, contents); -} -``` - -## AST Manipulation - -ASTs (Abstract Syntax Trees) allow you to understand exactly the code you're modifying. Replacing a string value can accidentally modify text found in a comment rather than changing the name of a variable. - -We'll write a generator that replaces all instances of the type `Array` with `something[]`. To help accomplish this, we'll use the `@phenomnomnominal/tsquery` npm package and the [AST Explorer](https://astexplorer.net) site. TSQuery allows you to query and modify ASTs with a syntax similar to CSS selectors. The AST Explorer tool allows you to easily examine the AST for a given snippet of code. - -First, go to [AST Explorer](https://astexplorer.net) and paste in a snippet of code that contains the input and desired output of our generator. - -```typescript -// input -const arr: Array = []; - -// desired output -const arr: string[] = []; -``` - -Make sure the parser is set to `typescript`. When you place the cursor on the `Array` text, the right hand panel highlights the corresponding node of the AST. The AST node we're looking for looks like this: - -```typescript -{ // TypeReference - typeName: { // Identifier - escapedText: "Array" - }, - typeArguments: [/* this is where the generic type parameter is specified */] -} -``` - -Second, we need to choose a selector to target this node. Just like with CSS selectors, there is an art to choosing a selector that is specific enough to target the correct nodes, but not overly tied to a certain structure. For our simple example, we can use `TypeReference` to select the parent node and check to see if it has a `typeName` of `Array` before we perform the replacement. We'll then use the `typeArguments` to get the text inside the `<>` characters. - -The finished code looks like this: - -```typescript -import { readProjectConfiguration, Tree } from '@nrwl/devkit'; -import { tsquery } from '@phenomnomnominal/tsquery'; -import { TypeReferenceNode } from 'typescript'; - -/** - * Run the callback on all files inside the specified path - */ -function visitAllFiles( - tree: Tree, - path: string, - callback: (filePath: string) => void -) { - tree.children(path).forEach((fileName) => { - const filePath = `${path}/${fileName}`; - if (!tree.isFile(filePath)) { - visitAllFiles(tree, filePath, callback); - } else { - callback(filePath); - } - }); -} - -export default function (tree: Tree, schema: any) { - const sourceRoot = readProjectConfiguration(tree, schema.name).sourceRoot; - visitAllFiles(tree, sourceRoot, (filePath) => { - const fileEntry = tree.read(filePath); - const contents = fileEntry.toString(); - - // Check each `TypeReference` node to see if we need to replace it - const newContents = tsquery.replace(contents, 'TypeReference', (node) => { - const trNode = node as TypeReferenceNode; - if (trNode.typeName.getText() === 'Array') { - const typeArgument = trNode.typeArguments[0]; - return `${typeArgument.getText()}[]`; - } - // return undefined does not replace anything - }); - - // only write the file if something has changed - if (newContents !== contents) { - tree.write(filePath, newContents); - } - }); -} -``` diff --git a/nx-dev/nx-dev/public/documentation/shared/generators/using-generators.md b/nx-dev/nx-dev/public/documentation/shared/generators/using-generators.md deleted file mode 100644 index bb5832fb0c..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/generators/using-generators.md +++ /dev/null @@ -1,26 +0,0 @@ -# Using Generators - -## Overview - -Generators provide a way to automate many tasks you regularly perform as part of your development workflow. Whether it is scaffolding out components, features, ensuring libraries are generated and structured in a certain way, or updating your configuration files, generators help you standardize these tasks in a consistent, and predictable manner. - -The [Workspace Generators](/generators/workspace-generators) guide shows you how to create, run, and customize workspace generators within your Nx workspace. - -## Types of Generators - -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](/generators/workspace-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](/using-nx/updating-nx) to keep your config files in sync with the latest versions of third party tools. - -## 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. - -```bash -nx generate [plugin]:[generator-name] [options] -nx generate @nrwl/react:component mycmp --project=myapp -``` - -It is important to have a clean git working directory before invoking a generator so that you can easily revert changes and re-invoke the generator with different inputs. diff --git a/nx-dev/nx-dev/public/documentation/shared/generators/workspace-generators.md b/nx-dev/nx-dev/public/documentation/shared/generators/workspace-generators.md deleted file mode 100644 index d20da47d72..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/generators/workspace-generators.md +++ /dev/null @@ -1,93 +0,0 @@ -# Workspace Generators - -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. - -```bash -nx generate @nrwl/workspace:workspace-generator my-generator -``` - -After the command is finished, the workspace generator is created under the `tools/generators` folder. - -```treeview -happynrwl/ -├── apps/ -├── libs/ -├── tools/ -│ ├── generators -│ | └── my-generator/ -│ | | ├── index.ts -│ | | └── schema.json -├── nx.json -├── package.json -└── tsconfig.base.json -``` - -The `index.ts` provides an entry point to the generator. The file contains a function that is called to perform manipulations on a tree that represents the file system. -The `schema.json` provides a description of the generator, available options, validation information, and default values. - -The initial generator function creates a library. - -```typescript -import { Tree, formatFiles, installPackagesTask } from '@nrwl/devkit'; -import { libraryGenerator } from '@nrwl/workspace'; - -export default async function (tree: Tree, schema: any) { - await libraryGenerator(tree, { name: schema.name }); - await formatFiles(tree); - return () => { - installPackagesTask(tree); - }; -} -``` - -To invoke other generators, import the entry point function and run it against the tree tree. `async/await` can be used to make code with Promises read like procedural code. The generator function may return a callback function that is executed after changes to the file system have been applied. - -In the schema.json file for your generator, the `name` is provided as a default option. The `cli` property is set to `nx` to signal that this is a generator that uses `@nrwl/devkit` and not `@angular-devkit`. - -```json -{ - "cli": "nx", - "id": "test", - "type": "object", - "properties": { - "name": { - "type": "string", - "description": "Library name", - "$default": { - "$source": "argv", - "index": 0 - } - } - }, - "required": ["name"] -} -``` - -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 - -To run a generator, invoke the `nx workspace-generator` command with the name of the generator. - -```bash -nx workspace-generator my-generator mylib -``` - -## Debugging Workspace 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. - -![](/shared/vscode-schematics-debug.png) - -## Workspace 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). diff --git a/nx-dev/nx-dev/public/documentation/shared/getting-started/EGH_ScalingReactNx.png b/nx-dev/nx-dev/public/documentation/shared/getting-started/EGH_ScalingReactNx.png deleted file mode 100644 index 308795a5a6..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/getting-started/EGH_ScalingReactNx.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/getting-started/advanced-nx-workspace-course.png b/nx-dev/nx-dev/public/documentation/shared/getting-started/advanced-nx-workspace-course.png deleted file mode 100644 index bf8a9f31fe..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/getting-started/advanced-nx-workspace-course.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/getting-started/intro.md b/nx-dev/nx-dev/public/documentation/shared/getting-started/intro.md deleted file mode 100644 index 0082597b43..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/getting-started/intro.md +++ /dev/null @@ -1,27 +0,0 @@ -# Intro to Nx - -Nx is a smart, fast and extensible build system with first class monorepo support and powerful integrations. - -## Philosophy - -Nx has a similar design philosophy to Visual Studio Code. Code is a powerful text editor, and you can be very productive -with it even if you don't install any extensions. The ecosystem of VSCode's extensions though is what can really level -up your productivity. - -Nx is similar. The core of Nx is generic, simple, and unobtrusive. Nx plugins, although very useful for many projects, -are completely optional. - -Most examples on this site use Nx plugins. It's just easier to demonstrate many features Nx offers when Nx generates all -the boilerplate. However, the vast majority of the features will work the same way in a workspace with no plugins. - -## Getting Started - -- [Using Nx without plugins](/getting-started/nx-core) will help you understand the core of Nx. -- [Adding Nx to an existing monorepo](/migration/adding-to-monorepo) will show how to add Nx to an existing monorepo. -- [Mental model](/using-nx/mental-model) is a good starting point for those who like to understand things theoretically first. - -If you want to use Nx plugins to really level up your productivity, pick one of the following guides: - -- [Nx and TypeScript](/getting-started/nx-and-typescript) -- [Nx and React](/getting-started/nx-and-react) -- [Nx and Angular](/getting-started/nx-and-angular) diff --git a/nx-dev/nx-dev/public/documentation/shared/getting-started/nx-and-angular.md b/nx-dev/nx-dev/public/documentation/shared/getting-started/nx-and-angular.md deleted file mode 100644 index 25beaa653e..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/getting-started/nx-and-angular.md +++ /dev/null @@ -1,88 +0,0 @@ -# Nx and Angular - -Nx is a smart, fast and extensible build system with first class monorepo support and powerful integrations. It has a powerful core and a rich plugin ecosystem. - -## Making Things Fast - -If you're only interested in improving the performance of your monorepo by using Nx's [affected:\* commands](/using-nx/affected), [computation cache](/using-nx/cache), and [distributed task execution](/using-nx/dte), then you don't need to use any plugins. Everything will work the same way whether your monorepo has React, Vue, Svelte, or even Go, Rust, or Java apps. Nx is technology-agnostic. - -Check out the following guides to get started: - -- [Using Nx without plugins](/getting-started/nx-core) -- [Adding Nx to an existing monorepo](/migration/adding-to-monorepo) -- [Adding Nx to an Angular CLI project](/migration/migration-angular) -- [Migrating from AngularJS](/migration/migration-angularjs) - -It is also a good idea to read the [mental model guide](/using-nx/mental-model) to understand how Nx works. - -## Nx and Angular Plugins - -Nx plugins helps you develop [Angular](/angular/overview) applications with fully integrated support for -modern tools and libraries like [Jest](/jest/overview), [Cypress](/cypress/overview), -[ESLint](/linter/eslint), Storybook, [NgRx](/angular/guides/misc-ngrx) and more. - - - -Check out the following to get started: - -- [Angular: Interactive Nx Tutorial (with videos)](/angular-tutorial/01-create-application) -- [Free Nx Course on YouTube](https://www.youtube.com/watch?time_continue=49&v=2mYLe9Kp9VM&feature=emb_logo) - -## Nx and Angular CLI - -**If you add Nx to an Angular CLI project, `ng` and `nx` are interchangeable (they invoke the same command). So anywhere you see `"nx build"` or `"nx affected"`, you can also use `"ng build"` or `"ng affected"`.** - -Nx integrates well with the Angular CLI: - -- It decorates the Angular CLI. After adding Nx to your workspace, running `ng` will run the wrapped Angular CLI that goes through Nx. Everything will work the same way but a lot faster. -- It supports all Angular Devkit builders and schematics. -- It supports using `angular.json` to configure projects and their targets. -- Nx Console works with Angular CLI projects. - -This works so well that often folks don't even know they use Nx. - -## Angular CLI has some limitations, and Nx addresses them. - -### angular.json - -Nx supports using `angular.json` to configure projects and their targets, but it comes with a few limitations. For instance, `angular.json` can be many thousands of lines long for large workspaces. - -What we recommend instead is to split `angular.json` into multiple `project.json` files (one for each project). This is how you do it: - -- Change the version number in `angular.json` to `2` -- Run `nx format` -- Run `nx generate @nrwl/workspace:convert-to-nx-project --all=true` - -**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 and nx.json](/configuration/projectjson) applies to `angular.json` in the same way.** - -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. - -### 'ng update' and 'nx migrate' - -If you haven't used Nx before and used the Angular CLI, you probably ran `ng update`. What is the difference? - -`nx migrate` is a much improved version of `ng update`. It runs the same migrations, but allows you to: - -- Rerun the same migration multiple times. -- Reorder migrations. -- Skip migrations. -- Fix migrations that "almost work". -- Commit a partially migrated state. -- Change versions of packages to match org requirements. - -And, in general, it is a lot more reliable for non-trivial workspaces. Why? - -`ng update` tries to perform migration in a single go, automatically. This doesn't work for most non-trivial workspaces. - -- `ng update` doesn't separate updating `package.json` from updating the source code of the repo. It all happens in a single go. This often fails for non-trivial workspaces or for organizations that have a custom npm registry, where you might want to use a different version of a package. -- `ng update` relies on `peerDependencies` to figure out what needs to be updated. Many third-party plugin don't have `peerDependencies` set correctly. -- When using `ng update` it is difficult to execute one migration at a time. Sometimes you want to patch things up after executing a migration. -- When using `ng update` it's not possible to fix almost-working migrations. We do our best but sometimes we don't account for the specifics of a particular workspace. -- When using `ng update` it's not possible to commit a partially-migrated repo. Migration can take days for a large repo. -- When using `ng update` it's not possible to rerun some of the migrations multiple times. This is required because you can rebase the branch multiple times while migrating. - -The Nx core team have gained a lot of experience migrating large workspaces over the last 5 years, and `nx migrate` has been consistently a lot more reliable and easier to use. It has also been a lot easier to implement migrations that work with `nx migrate` comparing to `ng update`. As a result, folks building React and Node applications with Nx have had better experience migrating because Angular folks use `ng update` out of habit, instead of using the command that works better. - -**Starting with Nx 11, you can migrate workspaces only using `nx migrate`**. To reiterate: `nx migrate` runs the migrations written by the Angular CLI team the same way `ng update` runs them. So everything should still work. You just get more control over how it works. - -If you still want to run `ng update`, you can do it as follows: `FORCE_NG_UPDATE=true nx update mypackage`. diff --git a/nx-dev/nx-dev/public/documentation/shared/getting-started/nx-and-react.md b/nx-dev/nx-dev/public/documentation/shared/getting-started/nx-and-react.md deleted file mode 100644 index 991a2a4af7..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/getting-started/nx-and-react.md +++ /dev/null @@ -1,29 +0,0 @@ -# Nx and React - -Nx is a smart, fast and extensible build system with first class monorepo support and powerful integrations. It has a powerful core and a rich plugin ecosystem. - -## Making Things Fast - -If you're only interested in improving the performance of your monorepo by using Nx's [affected:\* commands](/using-nx/affected), [computation cache](/using-nx/cache), and [distributed task execution](/using-nx/dte), then you don't need to use any plugins. Everything will work the same way whether your monorepo has React, Vue, Svelte, or even Go, Rust, or Java apps. Nx is technology-agnostic. - -Check out the following guides to get started: - -- [Using Nx without plugins](/getting-started/nx-core) -- [Adding Nx to an existing monorepo](/migration/adding-to-monorepo) -- [Migrating from CRA](/migration/migration-cra) - -It is also a good idea to read the [mental model guide](/using-nx/mental-model) to understand how Nx works. - -## Nx and React Plugins - -Nx plugins help you develop [React](/react/overview) applications with fully integrated support for modern tools -and libraries like [Jest](/jest/overview), [Cypress](/cypress/overview), -Storybook, [ESLint](/linter/eslint), and more. Nx also supports React -frameworks like [Next.js](/next/overview), Remix, and has great support for [React Native](/react-native/overview). - - - -Check out the following to get started: - -- [React: Interactive Nx Tutorial (with videos)](/react-tutorial/01-create-application) -- [Free Nx Course on Egghead: Scale React Development with Nx](https://egghead.io/playlists/scale-react-development-with-nx-4038) diff --git a/nx-dev/nx-dev/public/documentation/shared/getting-started/nx-setup.md b/nx-dev/nx-dev/public/documentation/shared/getting-started/nx-setup.md deleted file mode 100644 index 676f43f889..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/getting-started/nx-setup.md +++ /dev/null @@ -1,82 +0,0 @@ -# Nx Setup - -## Set up a New Nx Workspace - -Run the following command to create a new workspace. - -```bash -# pass @latest in case npx cached an older version of create-nx-workspace -npx create-nx-workspace@latest -``` - -When creating a workspace, you will have to choose a preset, which will preconfigure a few things for you. - -```bash -# create an empty workspace set up for building applications -npx create-nx-workspace --preset=empty - -# create an empty workspace set up for building packages -npx create-nx-workspace --preset=core - -# create an empty workspace set up for building packages with the @nrwl/js plugin installed -npx create-nx-workspace --preset=ts -``` - -Some presets set up applications, e2e tests, etc. - -```bash -npx create-nx-workspace --preset=react -npx create-nx-workspace --preset=react-native -npx create-nx-workspace --preset=angular -``` - -## Add Nx to an Existing Project - -If you have an existing Lerna or Yarn monorepo, you can gain the benefits of Nx's computation cache and distributed task execution without modifying the file structure by running this command: - -```bash -npx add-nx-to-monorepo -``` - -If you have an existing Create React App project, you can gain the benefits of Nx's computation cache and distributed task execution without modifying the file structure by running this command: - -```bash -npx cra-to-nx -``` - -For more information on adding Nx to an existing repository see the [migration guide](/migration/migration-cra) - -## Install Nx CLI - -To make the developer experience nicer, you may want to install the Nx CLI globally. - -```bash -npm install -g nx -``` - -## Folder Structure - -Nx can be added to any workspace, so there is no fixed folder structure. However, if you use one of the existing presets, you will likely see something like this: - -```treeview -myorg/ -├── apps/ -├── libs/ -├── tools/ -├── workspace.json -├── nx.json -├── package.json -└── tsconfig.base.json -``` - -`/apps/` contains the application projects. This is the main entry point for a runnable application. We recommend keeping applications as light-weight as possible, with all the heavy lifting being done by libraries that are imported by each application. - -`/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](/executors/creating-custom-builders), or [workspace generators](/generators/workspace-generators). - -`/workspace.json` lists every project in your workspace. (this file is optional) - -`/nx.json` configures the Nx CLI itself. It tells Nx what needs to be cached, how to run tasks etc. - -`/tsconfig.base.json` sets up the global TypeScript settings and creates aliases for each library to aid when creating TS/JS imports. diff --git a/nx-dev/nx-dev/public/documentation/shared/github.png b/nx-dev/nx-dev/public/documentation/shared/github.png deleted file mode 100644 index d1a2a63747..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/github.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/adding-assets.md b/nx-dev/nx-dev/public/documentation/shared/guides/adding-assets.md deleted file mode 100644 index 7c3b2b2cdd..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/adding-assets.md +++ /dev/null @@ -1,49 +0,0 @@ -# Adding Images, Fonts, and Files - -With Nx, you can **`import` assets directly from your TypeScript/JavaScript code**. - -```typescript -import React from 'react'; -import logo from './logo.png'; - -const Header = () => Logo; - -export default Header; -``` - -This import will be replaced by a string of the image path when the application builds. To reduce the number of network requests, if the image file size is less than 10 kB, then the image will be inlined using [data URI](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs) instead of a path. - -This works in CSS files as well. - -```css -.logo { - background-image: url(./logo.png); -} -``` - -## Adding SVGs - -SVG images can be imported using the method described above. - -Alternatively, you can import SVG images as React components. - -```typescript -import React from 'react'; -import { ReactComponent as Logo } from './logo.svg'; - -const Header = () => ; - -export default Header; -``` - -This method of import allow you to work with the SVG the same way you would with any other React component. You can style it using CSS, styled-components, etc. The SVG component accepts a `title` prop, as well as any other props that the `svg` element accepts. - -Note that if you are using Next.js, you have to opt into this behavior. To import SVGs as React components with Next.js, you need to make sure that `nx.svgr` value is set to `true` in your Next.js application's `next.config.js` file: - -```js -module.exports = withNx({ - nx: { - svgr: true, - }, -}); -``` diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/browser-support.md b/nx-dev/nx-dev/public/documentation/shared/guides/browser-support.md deleted file mode 100644 index 20669debdf..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/browser-support.md +++ /dev/null @@ -1,70 +0,0 @@ -# Configuring Browser Support - -The official Nx plugins rely on [browserslist](https://github.com/browserslist/browserslist) for configuring application browser support. This affects builds, both production and development, and will decide on which transformations will be run on the code when built. - -In general, the more modern your applications browser support is, the smaller the filesize as the code can rely on modern API's being present and not have to ship polyfills or shimmed code. - -By default, applications generated from official Nx generators ship an aggressively modern browser support config, in the form of a `.browserlistrc` file in the root of the application with the following contents. - -```text -last 1 Chrome version -last 1 Firefox version -last 2 Edge major versions -last 2 Safari major version -last 2 iOS major versions -Firefox ESR -not IE 9-11 # For IE 9-11 support, remove 'not'. -``` - -This configuration is used for many tools including babel, autoprefixer, postcss, and more to decide which transforms are necessary on the source code when producing built code to run in the browser. - -## Adding Support for IE 11 - -Adding support for IE or any other browser is as easy as changing the `.browserlistrc` file, following the rules and options listed on the [browserslist documentation](https://github.com/browserslist/browserslist#queries). These changes will affect differential loading and how the code is processed through babel and other tools for producing your builds. - -To add support for IE 11 simply change the final line in the `.browserlistrc` file to include IE: - -```text -last 1 Chrome version -last 1 Firefox version -last 2 Edge major versions -last 2 Safari major version -last 2 iOS major versions -Firefox ESR -IE 11 -``` - -For additional information regarding the format and rule options, please see: https://github.com/browserslist/browserslist#queries - -## Debugging Browser Support - -Sometimes broad configurations like `> 0.5%, not IE 11` can lead to surprising results, due to supporting browsers like Opera Mini or Android UC browser. - -To see what browsers your configuration is supporting, run `npx browserslist` in the application's directory to get an output of browsers and versions to support. - -```bash -$ npx browserslist -and_chr 61 -chrome 83 -edge 83 -edge 81 -firefox 78 -firefox 68 -ie 11 -ios_saf 13.4-13.5 -ios_saf 13.3 -ios_saf 13.2 -ios_saf 13.0-13.1 -ios_saf 12.2-12.4 -ios_saf 12.0-12.1 -safari 13.1 -safari 13 -safari 12.1 -safari 12 -``` - -Alternatively, if your support config is short you can just add it as a string param on the CLI: - -```bash -npx browserslist '> 0.5%, not IE 11' -``` diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/deploy-nextjs-to-vercel.md b/nx-dev/nx-dev/public/documentation/shared/guides/deploy-nextjs-to-vercel.md deleted file mode 100644 index e97c8e48b9..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/deploy-nextjs-to-vercel.md +++ /dev/null @@ -1,79 +0,0 @@ -# Deploying Next.js applications to Vercel - -Starting from Nx 11, your Next.js application should already be ready for deployment to Vercel. - -## Configure your Vercel project's settings appropriately - -### New Vercel project - -1. If you are "importing" your Nx workspace's repository for the first time, make sure you do _not_ choose a root directory as part of the repo selection process (therefore leaving it to be the root of the full repo/workspace) -2. Ensure the Next.js "Framework Preset" is selected -3. Expand the "Build and Output Settings" and toggle the override switch for the build command. For example, for an application named `tuskdesk` the value will look like this: - -```bash -npx nx build tuskdesk --prod -``` - -4. Toggle the override switch for the output directory. Point it to the `.next` directory inside the built app: - -```bash -dist/apps/tuskdesk/.next -``` - -Therefore, our full configuration (based on a repo called "nx-workspace" and a project called "tuskdesk") will look like this: - -![New Vercel Project](/shared/guides/next-deploy-vercel-1.png) - -### Existing Vercel project - -If you have an existing project on Vercel then the exact same guidance applies as for the section above, it's just that you will need to update the project's existing settings. - -When everything is updated appropriately, for our `tuskdesk` example we would see the following in our "General" settings UI: - -![Existing Vercel Project](/shared/guides/next-deploy-vercel-2.png) - -## Skipping build if the application is not affected - -One of the core features of Nx is to run code quality checks and builds only for projects that are affected by recent code changes. We can use [Vercel's ignored build step feature](https://vercel.com/docs/platform/projects#ignored-build-step) to only build our application if it is affected. - -We are going to achieve this by creating a shell script in our Nx workspace that will be invoked by Vercel. - -```sh - -# Name of the app to check. Change this to your application name! -APP=tuskdesk - -# Determine version of Nx installed -NX_VERSION=$(node -e "console.log(require('./package.json').devDependencies['@nrwl/workspace'])") -TS_VERSION=$(node -e "console.log(require('./package.json').devDependencies['typescript'])") - -# Install @nrwl/workspace in order to run the affected command -npm install -D @nrwl/workspace@$NX_VERSION --prefer-offline -npm install -D typescript@$TS_VERSION --prefer-offline - -# Run the affected command, comparing latest commit to the one before that -npx nx affected:apps --plain --base HEAD~1 --head HEAD | grep $APP -q - -# Store result of the previous command (grep) -IS_AFFECTED=$? - -if [ $IS_AFFECTED -eq 1 ]; then - echo "🛑 - Build cancelled" - exit 0 -elif [ $IS_AFFECTED -eq 0 ]; then - echo "✅ - Build can proceed" - exit 1 -fi -``` - -There are a few points worth noting about this script. - -Firstly, you might have noticed that we are running `npm install` (feel free to use `yarn add` instead) in this script, as a result running it will take some time. Having said that, it is usually still much faster than installing all dependencies and running the build of your application unconditionally. - -Secondly, this script only compares changes introduced in a single latest commit. So if you push multiple new commits - the script will only check if your application is affected by changes in the latest commit. In the future, there should be an environment variable in Vercel to determine what the base for the affected comparison should be. - -Once you've saved this script in your Nx workspace, for example in `tools/ignore-vercel-build.sh`, we need to point Vercel to use this script. - -![Ignore build step](/shared/guides/next-deploy-vercel-3.png) - -Naturally, you can continue on and set any additional Environment Variables etc that may be appropriate for your projects, but we have now covered the key points needed to deploy Next.js projects from Nx workspaces on Vercel! diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/environment-variables.md b/nx-dev/nx-dev/public/documentation/shared/guides/environment-variables.md deleted file mode 100644 index 7cccdfc8e5..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/environment-variables.md +++ /dev/null @@ -1,85 +0,0 @@ -# Environment Variables - -Environment variables are global system variables accessible by all the processes running under the Operating System (OS). Environment variables are useful to store system-wide values such as the directories to search for executable programs (PATH), OS version, Network Information, and custom variables. These env variables are passed at build time and used at the runtime of an app. - -## How to Use - -It's important to note that NX will only include in the process: - -- default env vars such as: `NODE_ENV` -- any environment variable prefixed with `NX_` such as: `NX_CUSTOM_VAR` - -Defining environment variables can vary between OSes. It’s also important to know that this is temporary for the life of the shell session. - -**Unix systems** - -In Unix systems, we need to pass the env vars before passing the (or other) commands \ - -Let's say we want to build with development mode, with env vars we can do that like so: - -```bash -NODE_ENV=development nx build myapp -``` - -And if we want to add a custom env var for the command above, it would look like: - -```bash -NODE_ENV=development NX_BUILD_NUMBER=123 nx build myapp -``` - -**Windows (cmd.exe)** - -```bash -set "NODE_ENV=development" && nx build myapp -``` - -**Windows (Powershell)** - -```bash -($env:NODE_ENV = "development") -and (nx build myapp) -``` - -## Loading Environment Variables - -By default, Nx will load any environment variables you place in the following files: - -1. `workspaceRoot/apps/my-app/.local.env` -2. `workspaceRoot/apps/my-app/.env.local` -3. `workspaceRoot/apps/my-app/.env` -4. `workspaceRoot/.local.env` -5. `workspaceRoot/.env.local` -6. `workspaceRoot/.env` - -Order is important. Nx will move through the above list, ignoring files it can't find, and loading environment variables into the current process for the ones it can find. If it finds a variable that has already been loaded into the process, it will ignore it. It does this for two reasons: - -1. Developers can't accidentally overwrite important system level variables (like `NODE_ENV`) -2. Allows developers to create `.env.local` or `.local.env` files for their local environment and override any project defaults set in `.env` - -For example: - -1. `workspaceRoot/apps/my-app/.env.local` contains `AUTH_URL=http://localhost/auth` -2. `workspaceRoot/apps/my-app/.env` contains `AUTH_URL=https://prod-url.com/auth` -3. Nx will first load the variables from `apps/my-app/.env.local` into the process. When it tries to load the variables from `apps/my-app/.env`, it will notice that `AUTH_URL` already exists, so it will ignore it. - -We recommend nesting your **app** specific `env` files in `apps/your-app`, and creating workspace/root level `env` files for workspace-specific settings (like the [Nx Cloud token](/using-nx/caching#distributed-computation-caching)). - -### Pointing to custom env files - -If you want to load variables from `env` files other than the ones listed above: - -1. Use the [env-cmd](https://www.npmjs.com/package/env-cmd) package: `env-cmd -f .qa.env nx serve` -2. Use the `envFile` option of the [run-commands](/workspace/run-commands-executor#envfile) builder and execute your command inside of the builder - -## Using Environment Variables in index.html - -Nx supports interpolating environment variables into your `index.html` file for React and Web applications. - -To interpolate an environment variable named `NX_DOMAIN_NAME` into your `index.html`, surround it with `%` symbols like so: - -```html - - -

The domain name is %NX_DOMAIN_NAME%.

- - -``` diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/js-and-ts.md b/nx-dev/nx-dev/public/documentation/shared/guides/js-and-ts.md deleted file mode 100644 index 542d457d3d..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/js-and-ts.md +++ /dev/null @@ -1,14 +0,0 @@ -# JavaScript and TypeScript - -Nx is a general-purpose build system and a general-purpose CLI. It works with JavaScript, TypeScript, Java, C#, Go, etc.. The core plugins Nx comes with do work best with JavaScript or TypeScript. - -TypeScript is a great choice for many teams, but not for everyone. If you want to use Nx with JavaScript, simply pass `--js` to all generate commands, as follows: - -```bash -nx g @nrwl/react:app myapp --js -nx g @nrwl/react:component mycmp --project=myapp --js -``` - -You can build/test/lint/serve your applications and libraries the same way whether you use JavaScript and TypeScript. You can also mix and match them. - -Regardless whether you use JavaScript or TypeScript, you will have a `tsconfig.base.json` file at the root of the workspace. **It's not used to build the applications and libraries in the workspace. It's only used to improve the editor experience.** diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/lerna-and-nx.md b/nx-dev/nx-dev/public/documentation/shared/guides/lerna-and-nx.md deleted file mode 100644 index 6f815cadb8..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/lerna-and-nx.md +++ /dev/null @@ -1,70 +0,0 @@ -# Nx and Yarn/Lerna (Workspaces for Publishing NPM Packages) - -> In our teams we see a shift away from Lerna and a strong preference to use Nx for managing JavaScript-based monorepos. -> [Thoughtworks Technology Radar 2021](https://www.thoughtworks.com/en-ca/radar/tools/nx) - -- Want to know how to create a **new** Nx workspace and use Lerna/Yarn with it, check out [Using Nx Core Without Plugins](/getting-started/nx-core). -- Want to add Nx to an existing Lerna/Yarn/PNPM mononorepo, check out [Adding Nx to Lerna/Yarn/PNPM/NPM Workspace](/migration/adding-to-monorepo). -- Want to build a publishable TS/JS library, checkout [Nx and TypeScript](/getting-started/nx-and-typescript). - -This guide clarifies some misconceptions about how Nx and Lerna/Yarn relate. - -## Nx and Lerna/Yarn Workspaces - -Nx has more in common with the build tools used at Google or Facebook (just made a lot more easily accessible for other -companies) than with tools like Yarn Workspaces or Lerna. When using the word "monorepo" in the context of say Google, -we imagine a much richer dev experience, not simply collocating a few projects side-by-side. - -Lerna/Yarn/PNPM are package managers. When it comes to monorepos, they mainly perform `node_modules` deduping. So the -choice isn't between Nx or Yarn Workspaces. It's between whether you want to have multiple `node_modules` folders (in -this case use Nx with Yarn Workspaces) or not (use Nx without Yarn Workspaces). - -### Misconception: You have to choose between Nx and Yarn Workspaces/Lerna. - -Lerna, Yarn workspaces, pnpm workspaces offer the following affordances for developing multiple projects in the same -repo: - -- Deduping node_modules. If I use the same version of say Next.js in all the projects, the package is installed once. -- Task orchestration. If I want to test all the projects, I can use a single command to do it. -- Publishing (Lerna only). I can run one command to publish packages to NPM. - -This is what Nx offers: - -- Smart rebuilds of affected projects -- Distributed task execution & computation caching -- Code sharing and ownership management -- High-quality editor plugins & GitHub apps -- Powerful code generators -- Workspace visualizations -- Rich plugin ecosystem -- Consistent dev experience for any framework -- Automatic upgrade to the latest versions of all frameworks and tools - -As you can see, there is basically no overlap. Nx isn't a package manager (it's not a JS-only tool), -so deduping `node_modules` isn't in that list. Nx doesn't care whether your repo has multiple node_modules folders or -not, or whether you choose to dedupe them or not. In fact, many companies use Nx and Yarn Workspaces together to get -the benefits of both. If you want to use Yarn Workspaces to dedupe `node_modules` in your Nx workspace, you can do it. -Many companies do. - -What often happens though is when folks adopt Nx, they have better affordances for implementing a single-version -policy (why this is a good idea is beyond the scope of this post, but you can read more about why Google does here). But -it's important to stress that this isn't required by Nx. It's simply something that Nx can enable you to do at scale. - -### Misconception: Nx is only for apps - -If you do something well, folks assume that the only thing you can do. Nx is equally suited for publishable npm packages -as it is for applications. - -For instance, the Nx repo itself is built with Nx. It has 2 applications and a few dozen libraries. Those libraries are -published to NPM. - -### Misconception: Nx is "all-in" - -While Nx does have many plugins, each of them is optional. If you check out [Using Nx Core Without Plugins](/getting-started/nx-core), you will see that Nx at its core is very minimal. Much like VS Code, Nx is very minimal but can easily be extended by adding plugins. Saying this is akin to saying that VS Code is "all in". The fullness and richness of the experience depends on how many plugins you choose to use. You could install a lot of Nx Plugins that will do a lot of the heavy lifting in, for instance, connecting your Next.js, Storybook and Cypress. You could but you don't have to. - -### Misconception: Nx is configuration over convention - -If you only use Nx core, the only extra piece configuration you get is `nx.json` at the root. - -Everything else you see in guides is optional. You can choose to configure your executors instead of using npm scripts, or configure generator defaults, and so forth. When you configure the `@nrwl/web:dev-server` executor, though, you aren't just adding a chunk of json config into `project.json`, you are also removing the configuration files you used to implement the same functionality (start -scripts, Webpack config files etc.) So the total amount of configuration is decreasing, and, often, by a lot. diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/login-app.png b/nx-dev/nx-dev/public/documentation/shared/guides/login-app.png deleted file mode 100644 index b4d944d1cc..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/guides/login-app.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/misc-data-persistence.md b/nx-dev/nx-dev/public/documentation/shared/guides/misc-data-persistence.md deleted file mode 100644 index d5f0bdd266..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/misc-data-persistence.md +++ /dev/null @@ -1,216 +0,0 @@ -# Using DataPersistence - -Managing state is a hard problem. We need to coordinate multiple backends, web workers, and UI components, all of which update the state concurrently. - -What should we store in memory and what in the URL? What about the local UI state? How do we synchronize the persistent state, the URL, and the state on the server? All these questions have to be answered when designing the state management of our applications. **Nx** provides a set of helper functions that enables the developer to manage state in Angular with an intentional synchronization strategy and handle error state. Check out the [Managing State in Angular Applications using NgRx](https://blog.nrwl.io/using-ngrx-4-to-manage-state-in-angular-applications-64e7a1f84b7b) for more detailed example of the state problem Nx is solving. - -## Optimistic Updates - -For a better user experience, the `optimisticUpdate` operator updates the state on the client application first, before updating the data on the server-side. While it addresses fetching data in order, removing the race conditions and handling error, it is optimistic about not failing to update the server. In case of a failure, when using `optimisticUpdate`, the local state on the client is already updated. The developer must provide an undo action to restore the previous state to keep it consistent with the server state. The error handling must be done in the callback, or by means of the undo action. - -```typescript -import { Actions, createEffect, ofType } from '@ngrx/effects'; -import { optimisticUpdate } from '@nrwl/angular'; - -@Injectable() -class TodoEffects { - updateTodo$ = createEffect(() => - this.actions$.pipe( - ofType('UPDATE_TODO'), - optimisticUpdate({ - // provides an action - run: (action: UpdateTodo) => { - return this.backend.updateTodo(action.todo.id, action.todo).pipe( - mapTo({ - type: 'UPDATE_TODO_SUCCESS', - }) - ); - }, - undoAction: (action: UpdateTodo, error: any) => { - // dispatch an undo action to undo the changes in the client state - return { - type: 'UNDO_TODO_UPDATE', - todo: action.todo, - }; - }, - }) - ) - ); - - constructor(private actions$: Actions, private backend: Backend) {} -} -``` - -## Pessimistic Updates - -To achieve a more reliable data synchronization, the `pessimisticUpdate` operator updates the server data first. When the change is reflected in the server state, changes the client state by dispatching an action. `pessimisticUpdate` method enforces the order of the fetches and error handling. - -```typescript -import { Actions, createEffect, ofType } from '@ngrx/effects'; -import { pessimisticUpdate } from '@nrwl/angular'; - -@Injectable() -class TodoEffects { - updateTodo$ = createEffect(() => - this.actions$.pipe( - ofType('UPDATE_TODO'), - pessimisticUpdate({ - // provides an action - run: (action: UpdateTodo) => { - // update the backend first, and then dispatch an action that will - // update the client side - return this.backend.updateTodo(action.todo.id, action.todo).pipe( - map((updated) => ({ - type: 'UPDATE_TODO_SUCCESS', - todo: updated, - })) - ); - }, - onError: (action: UpdateTodo, error: any) => { - // we don't need to undo the changes on the client side. - // we can dispatch an error, or simply log the error here and return `null` - return null; - }, - }) - ) - ); - - constructor(private actions$: Actions, private backend: Backend) {} -} -``` - -## Data Fetching - -The `fetch` operator provides consistency when fetching data. If there are multiple requests scheduled for the same action, it will only run the last one. - -```typescript -import { Actions, createEffect, ofType } from '@ngrx/effects'; -import { fetch } from '@nrwl/angular'; - -@Injectable() -class TodoEffects { - loadTodos$ = createEffect(() => - this.actions$.pipe( - ofType('GET_TODOS'), - fetch({ - // provides an action - run: (a: GetTodos) => { - return this.backend.getAll().pipe( - map((response) => ({ - type: 'TODOS', - todos: response.todos, - })) - ); - }, - - onError: (action: GetTodos, error: any) => { - // dispatch an undo action to undo the changes in the client state - return null; - }, - }) - ) - ); - - constructor(private actions$: Actions, private backend: Backend) {} -} -``` - -This is correct, but we can improve the performance by supplying an id of the data by using an accessor function and adding concurrency to the fetch action for different ToDo's. - -```typescript -import { Actions, createEffect, ofType } from '@ngrx/effects'; -import { fetch } from '@nrwl/angular'; - -@Injectable() -class TodoEffects { - loadTodo$ = createEffect(() => - this.actions$.pipe( - ofType('GET_TODO'), - fetch({ - id: (todo: GetTodo) => { - return todo.id; - }, - - // provides an action - run: (todo: GetTodo) => { - return this.backend.getTodo(todo.id).map((response) => ({ - type: 'LOAD_TODO_SUCCESS', - todo: response.todo, - })); - }, - - onError: (action: GetTodo, error: any) => { - // dispatch an undo action to undo the changes in the client state - return null; - }, - }) - ) - ); - - constructor(private actions$: Actions, private backend: Backend) {} -} -``` - -With this setup, the requests for Todo will run concurrently with the requests for Todo 2. - -## Data Fetching On Router Navigation - -Since the user can always interact with the URL directly, we should treat the router as the source of truth and the initiator of actions. In other words, the router should invoke the reducer, not the other way around. - -When our state depends on navigation, we can not assume the route change happened when a new url is triggered but when we actually know the user was able to navigate to the url. The `navigation` operator checks if an activated router state contains the passed in component type, and, if it does, runs the `run` callback. It provides the activated snapshot associated with the component and the current state. And it only runs the last request. - -```typescript -import { Actions, createEffect, ofType } from '@ngrx/effects'; -import { navigation } from '@nrwl/angular'; - -@Injectable() -class TodoEffects { - loadTodo$ = createEffect(() => - this.actions$.pipe( - // listens for the routerNavigation action from @ngrx/router-store - navigation(TodoComponent, { - run: (activatedRouteSnapshot: ActivatedRouteSnapshot) => { - return this.backend - .fetchTodo(activatedRouteSnapshot.params['id']) - .pipe( - map((todo) => ({ - type: 'LOAD_TODO_SUCCESS', - todo: todo, - })) - ); - }, - - onError: ( - activatedRouteSnapshot: ActivatedRouteSnapshot, - error: any - ) => { - // we can log and error here and return null - // we can also navigate back - return null; - }, - }) - ) - ); - - constructor(private action$: Actions, private backend: Backend) {} -} -``` - -The StoreRouterConnectingModule must be configured with an appropriate serializer. The `DefaultRouterStateSerializer` provides the full router state instead of the `MinimalRouterStateSerializer` that is used without configuration. - -```typescript -import { NgModule } from '@angular/core'; -import { - StoreRouterConnectingModule, - DefaultRouterStateSerializer, -} from '@ngrx/router-store'; - -@NgModule({ - imports: [ - StoreRouterConnectingModule.forRoot({ - serializer: DefaultRouterStateSerializer, - }), - ], -}) -export class TodosModule {} -``` diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/misc-ngrx.md b/nx-dev/nx-dev/public/documentation/shared/guides/misc-ngrx.md deleted file mode 100644 index ec1b9133fa..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/misc-ngrx.md +++ /dev/null @@ -1,119 +0,0 @@ -# State Management with NgRx - -Using [NgRx](https://ngrx.io) for state management in an Angular application allows you to -build out application flows that track unique events and manage the state of shared data in a reactive, explicit, and consistent way. - -## Overview - -Nx provides a schematic to build out a new NgRx feature area that manages shared state. - -The **@nrwl/angular** package has an `ngrx` schematic to generate files that implement best practices when using NgRx for state management. This schematic generates source files that include enhancements to NgRx for data persistence strategies, and simplified testing. - -The `ngrx` schematic generates an NgRx feature set containing the following files: - -- `actions` - Express unique events throughout your application. -- `reducer` - Handle state changes from dispatched actions to perform state changes in an immutable way. -- `effects` - Handle side effects for isolating external interactions from UI components. -- `selectors` - Composable functions that select pieces of state and update when their inputs change. -- `facade` - Optional class that provides further encapsulation of NgRx from your component. - -> The `ngrx` schematic only provides a sub-set of schematics for the NgRx libraries. See [@ngrx/schematics](https://ngrx.io/guide/schematics) for the full set of available schematics. - -## Command - -The following command is used to run the `ngrx` schematic: - -```bash -ng g @nrwl/angular:ngrx --module= --defaults [options] -``` - -> Note: the `name` and the `--module=` arguments are required. The `defaults` option chooses the recommended defaults for the schematic, unless you override them. - -The most common additional options are: - -- `root` - Set up the initial NgModule imports for NgRx Store, Effects, Router-Store, and Store DevTools. -- `syntax` - NgRx introduced new creator functions for actions, reducers, and effects that provide the same type-safety with less code than action classes. -- `facade` - Optional. If you prefer to further encapsulate NgRx from your components, add an injectable facade. See the blog [Better State Management with Facades](https://blog.nrwl.io/nrwl-nx-6-2-angular-6-1-and-better-state-management-e139da2cd074#cb93) for details. - -See the [API Docs](/angular/ngrx) for detailed descriptions of all the available options. Also visit the [NgRx](https://ngrx.io) website for more guides and documentation about the libraries. - ---- - -## Initial Setup - -To get started with NgRx in an Angular application, you set up the root level store. As your application grows, you add feature level states, ensuring that your code follows a common pattern each time. - -The example below shows you how to setup NgRx in the root of your application. - -```bash -ng g @nrwl/angular:ngrx app --module=apps//src/app/app.module.ts --root -``` - -The above command applies the following changes to the provided module: - -- Registers `StoreModule.forRoot({})` in the imports array for state management, with recommended runtime checks enabled for maintaining immutable actions and state. -- Registers `EffectsModule.forRoot([])` in the `imports` array for isolation of side effects. -- Registers `StoreRouterConnectingModule.forRoot()` in the `imports` array for integration with the [Angular Router](https://angular.io/guide/router). -- Registers `StoreDevtools.instrument()` in the `imports` array for integration with the [Redux Devtools browser extension](http://extension.remotedev.io/). - -You manage separate slices of state using libraries and feature states. - -## Feature Workflow - -When building new features using NgRx, you want to manage the state from within a separate library. This allows your -state to be easily shared across other libraries and applications. The steps below go through the workflow of using NgRx within the context of a library. - -The example below generates a library to begin a new feature. For this example, `products` is used as the library name. - -```bash -ng g @nrwl/angular:lib products -``` - -To manage the feature state: - -- Use the `ngrx` schematic with the feature name in plural form, such as `products`. -- Provide a path to the `products` library module. - -```bash -ng g @nrwl/angular:ngrx products --module=libs/products/src/lib/products.module.ts --directory +state/products --defaults -``` - -> Use the `--facade` option to generate an injectable Facade class along with the feature. - -The following files are created, or updated: - -```treeview -myorg/ -├── apps/ -└── libs/ - └── products/ - └── src/ - ├── lib/ - │ ├── +state/ - │ │ ├── products.actions.ts - │ │ ├── products.effects.ts - │ │ ├── products.effects.spec.ts - │ │ ├── products.facade.ts # optional - │ │ ├── products.facade.spec.ts # optional - │ │ ├── products.models.ts - │ │ ├── products.reducer.ts - │ │ ├── products.reducer.spec.ts - │ │ ├── products.selectors.ts - │ │ └── products.selectors.spec.ts - │ ├── products.module.spec.ts - │ └── products.module.ts - └── index.ts -``` - -The above command also does the following changes: - -- Updates the feature module and registers `StoreModule.forFeature()` with the name of your feature state in the `imports` array. -- Updates the feature module and registers `EffectsModule.forFeature()` in the `imports` array. - -The feature library's barrel `index.ts` is also updated to export the updated _public API_ for the state including: - -- The NgRx selectors. -- The NgRx feature reducer. -- The optional facade class for the NgRx feature. - -> When generating multiple feature states within a single library, make sure there are no naming collisions in the barrel `index.ts` file. diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/next-deploy-vercel-1.png b/nx-dev/nx-dev/public/documentation/shared/guides/next-deploy-vercel-1.png deleted file mode 100644 index 4aba0a892a..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/guides/next-deploy-vercel-1.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/next-deploy-vercel-2.png b/nx-dev/nx-dev/public/documentation/shared/guides/next-deploy-vercel-2.png deleted file mode 100644 index c609cc7f1b..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/guides/next-deploy-vercel-2.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/next-deploy-vercel-3.png b/nx-dev/nx-dev/public/documentation/shared/guides/next-deploy-vercel-3.png deleted file mode 100644 index e8107659cb..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/guides/next-deploy-vercel-3.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/nx-and-ts.md b/nx-dev/nx-dev/public/documentation/shared/guides/nx-and-ts.md deleted file mode 100644 index 9620b32981..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/nx-and-ts.md +++ /dev/null @@ -1,207 +0,0 @@ -# Nx and TypeScript - -> The build system for TypeScript that TypeScript deserves - -The `@nrwl/js` package ships with corresponding generators and executors that best work when it comes to developing TypeScript applications and libraries. - -> Note, you can also opt-out of TypeScript and use plain JavaScript by passing the `--js` flag to the generators. - - - -`@nrwl/js` is particularly useful if you want to - -- Create framework-agnostic TypeScript libraries within an existing Nx workspace (say to use in your React, Node or Angular app) -- Publish TypeScript packages to NPM - -To get started with TypeScript packages in Nx, either add the `@nrwl/js` package to an existing Nx workspace or generate a new Nx workspace using the `--preset=ts` preset. - -```bash -npx create-nx-workspace happynrwl -–preset=ts -``` - -Generating a new workspace creates a lightweight setup with a `packages` and `tools` folder. The `tools` folder is where you can add monorepo specific scripts and custom Nx generators, the `packages` folder is where all our TS based libs will live. - -```treeview -happynrwl/ -├── packages/ -├── tools/ -├── workspace.json -├── nx.json -├── package.json -└── tsconfig.base.json -``` - -As with most Nx plugins, `@nrwl/js` comes with a set of generators to quickly scaffold new TypeScript libraries as well as TypeScript applications. Let’s have a look at an example. - -## Create a new TypeScript based library - -We can use Nx Console and choose the `@nrwl/js:library` generator or directly use the following command: - -```bash -nx generate @nrwl/js:library --name=hello-tsc --buildable -``` - -This creates a new library in the `packages/hello-tsc` folder that already comes with both ESLint and Jest set up and ready to use. - -You can run `nx lint hello-tsc` to run linting or `nx test hello-tsc` to run Jest tests. - -Note, by passing the `--buildable` flag, our library can be built. - -```bash -nx build hello-tsc -``` - -The output of the build step is placed into the `dist/packages/hello-tsc` by default. - -## Create a TypeScript based application - -Apart from setting up TypeScript libraries, you can also setup a plain TypeScript application that is framework agnostic and consists of an entry point script that can be easily run with Node, to develop a CLI or framework agnostic backend application. - -To generate a new framework agnostic TS application, run - -```bash -nx generate @nrwl/js:app demoapp -``` - -Applications also come with a “serve” target, that allow you to run the app in watch mode: - -```bash -nx serve demoapp -``` - -## Importing Libraries - -All the libraries generated within the Nx workspace are configured with corresponding TypeScript path mappings in the root-level `tsconfig.base.json` file: - -```json -{ - "compileOnSave": false, - "compilerOptions": { - ... - "paths": { - "@happynrwl/hello-swc": ["packages/hello-swc/src/index.ts"], - "@happynrwl/hello-tsc": ["packages/hello-tsc/src/index.ts"] - } - }, -} -``` - -This allows you to easily import from libraries, by using the corresponding TypeScript path mapping. The following shows an example of importing the `helloTsc` function from the `hello-tsc` library into the `tsapp` application (the same method works between libraries as well): - -```typescript -// file: packages/tsapp/src/index.ts - -// importing from hello-tsc -import { helloTsc } from '@happynrwl/hello-tsc'; - -// use the function -helloTsc(); - -console.log(`Running ${tsapp()}`); -``` - -## Use SWC as the compiler - -Nx also ships with support to use SWC instead of TSC. When generating a new library/application just pass the `--compiler=swc`. - -Here's an example of generating a new library: - -```bash -nx generate @nrwl/js:library --name=hello-tsc --buildable --compiler=swc -``` - -Alternatively, if you already have an existing tsc based library/application, you can run the `@nrwl/js:convert-to-swc` generator to migrate the package from TSC to SWC. - -The following command converts the `hello-tsc` library to SWC: - -```bash -nx generate @nrwl/js:convert-to-swc --name=hello-tsc -``` - -## Using NPM Scripts rather than Nx executors - -If you want to use NPM scripts rather than Nx executors, you can use the `--config=npm-scripts`: - -```bash -nx g @nrwl/js:lib mylib --config=npm-scripts -``` - -The Nx generator then creates NPM scripts in the generated library's `package.json` (rather than in the `project.json`): - -```json -// packages/mylib/package.json -{ - "name": "@happynrwl/mylib", - "version": "0.0.1", - "type": "commonjs", - "scripts": { - "build": "echo 'implement build'", - "test": "echo 'implement test'" - } -} -``` - -To run these scripts with Nx, use the same syntax as Nx executors. `nx build mylib` or `nx test mylib` will build or test your library, respectively. - -## Publish your TypeScript packages to NPM - -Nx doesn’t provide an out of the box process for publishing and leaves it to the developer to invoke the final command. The reason for this is that the actual publishing process can be very specific to your project and target you deploy to and might have a lot of custom pre-deployment setup (e.g. generating changelogs, determining semver etc.). Make sure to check out our [community page](/community) as there are a lot of community provided packages integrating into the publishing process. - -However, integrating your own custom publishing process with Nx can be very straightforward, especially with the help of Nx [run-commands](/executors/run-commands-builder) and [“Target Dependencies”](/configuration/projectjson#dependson). - -To add a new run-command to our project, we can leverage the `run-command` generator: - -```bash -nx g @nrwl/workspace:run-commands publish --project hello-tsc --command 'npm publish --tag=latest --access public' -``` - -This adds a new `publish` target to our existing `project.json` configuration of the `hello-tsc` project. Let's also make sure to adjust the `cwd` (current working directory) of our command, which should be the output folder of the `hello-tsc` package. - -```json -{ - "root": "packages/hello-tsc", - "sourceRoot": "packages/hello-tsc/src", - "projectType": "library", - "targets": { - "build": { ... }, - "lint": { ... }, - "test": { ... }, - "publish": { - "executor": "@nrwl/workspace:run-commands", - "outputs": [], - "options": { - "command": "npm publish --tag=latest --access public", - "cwd": "dist/packages/hello-tsc" - } - } - }, - "tags": [] -} -``` - -With that, we're all set up. By running the following commands we can publish our package to NPM. - -```bash -nx build hello-tsc -nx publish hello-tsc -``` - -We can automate this even further by leveraging the `targetDependencies` feature. There's clearly a dependency between `build` and `publish`, in that we want to make sure the `build` happens before the `publish` command. We can define this relationship in the `nx.json` file: - -```json -{ - ... - "targetDependencies": { - ... - "publish": [ - { - "target": "build", - "projects": "self" - } - ] - }, - ... -} -``` - -Now, just running `nx publish hello-tsc` will automatically run the `nx build hello-tsc` command first. And of course, if `build` has already run, it won't execute again, thanks to [Nx computation caching](/using-nx/caching). diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/nx-devkit-angular-devkit.md b/nx-dev/nx-dev/public/documentation/shared/guides/nx-devkit-angular-devkit.md deleted file mode 100644 index 1d3ddbd62a..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/nx-devkit-angular-devkit.md +++ /dev/null @@ -1,199 +0,0 @@ -# Nx Devkit and Angular Devkit - -> Note: this document covers the difference between Nx Devkit and Angular Devkit. See the [Nx Devkit](/getting-started/nx-devkit) guide for more in-depth details about Nx Devkit. - -Nx comes with a devkit to write generators and executors, but you can also use Angular devkit (schematics and builders). In other words, you can use an Angular schematic to implement a generator, and you can use an Angular builder to implement an executor. - -**What are the differences between Nx Devkit and Angular Devkit?** - -## Generators - -The following is a generator written using Nx Devkit: - -```typescript -import { Tree, formatFiles, generateFiles } from '@nrwl/devkit'; -import * as path from 'path'; - -interface Schema { - name: string; - skipFormat: boolean; -} - -export default async function (tree: Tree, options: Schema) { - generateFiles( - tree, - path.join(__dirname, 'files'), - path.join('tools/generators', schema.name), - options - ); - if (!schema.skipFormat) { - await formatFiles(tree); - } -} -``` - -The following is an analogous generator written as an Angular Schematic. - -```typescript -import { - apply, - branchAndMerge, - chain, - mergeWith, - Rule, - template, - url, - move, -} from '@angular-devkit/schematics'; -import { formatFiles } from '@nrwl/workspace'; -import { toFileName } from '@nrwl/workspace'; - -interface Schema { - name: string; - skipFormat: boolean; -} - -export default function (options: Schema): Rule { - const templateSource = apply(url('./files'), [ - template({ - dot: '.', - tmpl: '', - ...(options as any), - }), - move('tools/generators'), - ]); - return chain([ - branchAndMerge(chain([mergeWith(templateSource)])), - formatFiles(options), - ]); -} -``` - -### Notable Differences - -- Nx Devkit generators do not use partial application. An Angular Schematic returns a rule that is then invoked with a tree. -- Nx Devkit generators do not use RxJS observables. Instead you invoke the helpers directly, which makes them more debuggable. As you step through the generator you can see the tree being updated. -- There are more affordances for commonly used operations. For instance, `chain([mergeWith(apply(url` is replaced with `generateFiles`) -- Nx Devkit generators return a function that performs side effects. Angular Schematics have to create a custom task runner and register a task using it. -- Nx Devkit generators are composed as any other JS function. You do need to go through a special resolution step (`externalSchematic`) that is required when using Angular Schematics. -- No special utilities are needed to test Nx Devkit generators. Special utilities are needed to test Angular Schematics. - -### Conversions - -The Nx CLI can invoke Nx Generator or Angular Schematics directly. When the user runs: - -```bash -nx g mygenerator params -ng g mygenerator params # will work exactly the same same as the line above -``` - -The Nx CLI will see what type of generator `mygenerator` is and will invoke it using the right machinery. The user doesn't have to know how the generator is implemented. - -At times, however, it might be useful to use an Nx Devkit generator in an Angular Schematic or vice versa. - -**Making an Angular Schematic out of Nx Devkit Generator:** - -First, you need to - -```typescript -export async function mygenerator(tree: Tree, options: Schema) { - // ... -} -export const mygeneratorSchematic = convertNxGenerator(mygenerator); -``` - -Then, you might need to register it in the `collections.json`: - -```json -{ - "name": "Nx React", - "version": "0.1", - "extends": ["@nrwl/workspace"], - "schematics": { - "mygenerator": { - "factory": "./src/generators/mygenerator/mygenerator#mygeneratorSchematic", - "schema": "./src/generators/mygenerator/schema.json" - } - }, - "generators": { - "init": { - "factory": "./src/generators/mygenerator/mygenerator#mygenerator", - "schema": "./src/generators/mygenerator/schema.json" - } - } -} -``` - -**Making an Nx Devkit Generator out of Angular Schematic:** - -```typescript -export const libraryGenerator = wrapAngularDevkitSchematic( - '@nrwl/angular', - 'library' -); - -export async function mygenerator(tree: Tree, options: Schema) { - await libraryGenerator(tree, options); -} -``` - -## Executors - -The following is an executor written using Nx Devkit: - -```typescript -interface Schema { - message: string; - allCaps: boolean; -} - -export default async function ( - options: Schema, - context: ExecutorContext -): Promise<{ success: true }> { - if (options.allCaps) { - console.log(options.message.toUpperCase()); - } else { - console.log(options.message); - } - return { success: true }; -} -``` - -The following is an analogous executor written as an Angular builder: - -```typescript -interface Schema { - message: string; - allCaps: boolean; -} -export function run( - options: Schema, - context: BuilderContext -): Observable<{ success: true }> { - if (options.allCaps) { - console.log(options.message.toUpperCase()); - } else { - console.log(options.message); - } - return of({ success: true }); -} -export default createBuilder(run); -``` - -### Notable Differences - -- Nx Devkit executors return a Promise (or async iterable). If you want, you can always convert an observable to a promise or an async iterable. See [Using Rxjs Observables](/executors/using-builders#using-rxjs-observables) -- Nx Devkit executors do not have to be wrapped using `createBuilder`. - -The schema files for both Nx Devkit executors and Angular Builders are the same. Nx can run both of them in the same way. - -## When to Use What - -If you are writing an Nx plugin, use Nx Devkit. It's **much** easier to use and debug. It has better docs and more people supporting it. - -Do you have to rewrite your Nx Plugin if it is written using Angular Devkit? No. Nx supports both and will always support both. And, most importantly, the end user might not even know what you used to write a generator or an executor. - -``` - -``` diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/performance-profiling-devtools.png b/nx-dev/nx-dev/public/documentation/shared/guides/performance-profiling-devtools.png deleted file mode 100644 index acc576969f..0000000000 Binary files a/nx-dev/nx-dev/public/documentation/shared/guides/performance-profiling-devtools.png and /dev/null differ diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/performance-profiling.md b/nx-dev/nx-dev/public/documentation/shared/guides/performance-profiling.md deleted file mode 100644 index 7984ef79d7..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/performance-profiling.md +++ /dev/null @@ -1,29 +0,0 @@ -# Profiling Performance - -When running an Nx command, many tasks are run at different times in different processes. -Visualizing where and when the tasks were executed can help optimize the entire run to be quicker. - -## How to Profile the Performance of Running Tasks - -1. Prepend `NX_PROFILE=profile.json` before running targets with Nx. For example, - -```bash -# This builds the "cart" application and creates a profile.json file -NX_PROFILE=profile.json nx build cart - -# This builds affected projects and creates a profile.json file -NX_PROFILE=profile.json nx affected --target build -``` - -2. Open the Performance Tab in Chrome Devtools - ![Performance Profiling with Chrome Devtools](./performance-profiling-devtools.png) -3. Click the upload button and open the `profile.json` that was created. (Or drag the file into the window) -4. Expand each group to see the names of the tasks which were run - -## Optimizing the Performance of Running Tasks - -Now that you have visualized how the tasks were run, you can try tweaking things to make the process faster. Generate profiles after each tweak and compare the results. - -1. Are there tasks that you did not expect to be necessary? Sometimes, more tasks are captured by a command than expected. Excluding them could free up workers for other tasks. -2. Try adding more workers. Did the new workers handle tasks while other workers were busy? This will likely result in faster runs. -3. Are a lot of the tasks waiting on a single task to be completed? Splitting that project into smaller projects may allow fewer projects and therefore tasks to depend on a single project/task. This will allow for more room to parallelize the tasks. diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/react-native.md b/nx-dev/nx-dev/public/documentation/shared/guides/react-native.md deleted file mode 100644 index 25cfda4425..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/react-native.md +++ /dev/null @@ -1,286 +0,0 @@ -# React Native with Nx - -![React Logo](/shared/react-logo.png) - -Nx provides a holistic dev experience powered by an advanced CLI and editor plugins. It provides rich support for common tools like [Detox](/detox/overview), Storybook, Jest, and more. - -In this guide we will show you how to develop [React Native](https://reactnative.dev/) applications with Nx. - -## Creating Nx Workspace - -The easiest way to create your workspace is via `npx`. - -```bash -npx create-nx-workspace happynrwl \ ---preset=react-native \ ---appName=mobile -``` - -**Note:** You can also run the command without arguments to go through the interactive prompts. - -```bash -npx create-nx-workspace happynrwl -``` - -Once the command completes, the workspace will look as follows: - -```treeview -happynrwl/ -├── apps/ -│ ├── mobile/ -│ │ ├── app.json -│ │ ├── metro.config.js -│ │ ├── android/ -│ │ │ ├── app/ -│ │ │ ├── gradle/ -│ │ │ ├── build.gradle -│ │ │ ├── gradle.properties -│ │ │ ├── gradlew -│ │ │ ├── settings.gradle -│ │ ├── ios/ -│ │ │ ├── Mobile/ -│ │ │ ├── Mobile.xcodeproj/ -│ │ │ ├── Mobile.xcworkspace/ -│ │ │ ├── Podfile -│ │ │ ├── Podfile.lock -│ │ ├── src/ -│ │ │ ├── main.tsx -│ │ │ └── app/ -│ │ │ ├── App.tsx -│ │ │ └── App.spec.tsx -│ │ ├── .babelrc -│ │ ├── jest.config.js -│ │ ├── test-setup.ts -│ │ ├── package.json -│ │ ├── project.json -│ │ ├── tsconfig.json -│ │ ├── tsconfig.app.json -│ │ └── tsconfig.spec.json -│ └── mobile-e2e/ -│ ├── .detoxrc.json -│ ├── src/ -│ │ └── app.spec.ts -│ ├── .babelrc -│ ├── jest.config.json -│ ├── project.json -│ ├── tsconfig.e2e.json -│ └── tsconfig.json -├── libs/ -├── tools/ -├── babel.config.json -├── jest.config.js -├── jest.preset.js -├── nx.json -├── package-lock.json -├── package.json -├── tsconfig.base.json -└── workspace.json -``` - -Run `npx nx run-android mobile` to run the applicatoin in development mode on Android simulator/device. Run `npx nx run-ios mobile` to run the applicatoin in developement mode on iOS simulator/device. - -Try out other commands as well. - -- `nx lint mobile` to lint the application -- `nx test mobile` to run unit test on the application using Jest -- `nx serve mobile` to serve the application Javascript bundler that communicates with connected devices. This will start the bundler at http://localhost:8081. -- `nx sync-deps mobile` to sync app dependencies to its `package.json`. - -### Release build - -**Android:** - -```sh -npx nx build-android mobile -``` - -**iOS:** (Mac only) - -No CLI support yet. Run in the Xcode project. See: https://reactnative.dev/docs/running-on-device - -### E2E - -**Android:** - -```sh -npx nx test-android mobile-e2e -``` - -**iOS:** (Mac only) - -```sh -npx nx test-ios mobile-e2e -``` - -When using React Native in Nx, you get the out-of-the-box support for TypeScript, Detox, and Jest. No need to configure anything: watch mode, source maps, and typings just work. - -### Adding React Native to an Existing Workspace - -For existing Nx workspaces, install the `@nrwl/react-native` package to add React Native capabilities to it. - -```bash -npm install @nrwl/react-native --save-dev - -# Or with yarn -yarn add @nrwl/react-native --dev -``` - -## Generating an Application - -To create additional React Native apps run: - -```bash -npx nx g @nrwl/react-native:app -``` - -## Generating a Library - -Nx allows you to create libraries with just one command. Some reasons you might want to create a library include: - -- Share code between applications -- Publish a package to be used outside the monorepo -- Better visualize the architecture using `npx nx graph` - -For more information on Nx libraries, see our documentation on [Creating Libraries](/structure/creating-libraries) -and [Library Types](/structure/library-types). - -To generate a new library run: - -```bash -npx nx g @nrwl/react-native:lib shared-ui-layout -``` - -And you will see the following: - -```treeview -happynrwl/ -├── apps/ -│ └── mobile/ -│ └── mobile-e2e/ -├── libs/ -│ └── shared-ui-layout/ -│ ├── src/ -│ │ └── index.ts -│ ├── .babelrc -│ ├── jest.config.js -│ ├── project.json -│ ├── README.md -│ ├── test-setup.ts -│ ├── tsconfig.json -│ ├── tsconfig.lib.json -│ └── tsconfig.spec.json -├── tools/ -├── babel.config.json -├── jest.config.js -├── jest.preset.js -├── nx.json -├── package-lock.json -├── package.json -├── tsconfig.base.json -└── workspace.json -``` - -Run: - -- `npx nx test shared-ui-layout` to test the library -- `npx nx lint shared-ui-layout` to lint the library - -To generate a new comopnent inside `shared-ui-layout` run: - -```bash -npx nx g @nrwl/react-native:component layout --project=shared-ui-layout --export -``` - -And you will see the following updated for `shared-ui-layout`: - -```treeview -happynrwl/ -└── libs/ - └── shared-ui-layout/ - └── src/ - ├── index.ts - └── lib/ - └── layout/ - ├── layout.tsx - └── layout.spec.tsx -``` - -### Using Nx Library in your Application - -You can import the `shared-ui-layout` library in your application as follows. - -```typescript jsx -// apps/mobile/src/app/App.tsx -import React from 'react'; -import { SafeAreaView } from 'react-native'; - -import { Layout } from '@happynrwl/shared-ui-layout'; - -const App = () => { - return ( - - - - ); -}; - -export default App; -``` - -That's it! There is no need to build the library prior to using it. When you update your library, the React Native application will automatically pick up the changes. - -### Publishable libraries - -For libraries intended to be built and published to a registry (e.g. npm) you can use the `--publishable` and `--importPath` options. - -```bash -npx nx g @nrwl/react-native:lib shared-ui-layout --publishable --importPath=@happynrwl/ui-components -npx nx g @nrwl/react-native:component layout --project=shared-ui-layout --export -``` - -Run `npx nx build shared-ui-layout` to build the library. It will generate the following: - -```treeview -dist/libs/shared-ui-layout/ -├── README.md -├── index.d.ts -├── lib/ -│ └── layout/ -│ └── layout.d.ts -├── package.json -├── shared-ui-layout.esm.css -├── shared-ui-layout.esm.js -├── shared-ui-layout.umd.css -└── shared-ui-layout.umd.js -``` - -This dist folder is ready to be published to a registry. - -## Environment Variables - -The workspace should install[react-native-config](https://github.com/luggit/react-native-config) by default. To use environment variable, create a new `.env` file in the `happynrwl/apps/mobile` folder: - -``` -NX_BUILD_NUMBER=123 -``` - -Then access variables defined there from your app: - -```js -import Config from 'react-native-config'; - -Config.NX_BUILD_NUMBER; // '123' -``` - -## Code Sharing - -Without Nx, creating a new shared library can take from several hours to even weeks: a new repo needs to be provisioned, CI needs to be set up, etc... In an Nx Workspace, it only takes minutes. - -You can share React Native components between multiple React Native applications, share business logic code between React Native mobile applications and plain React web applications. You can even share code between the backend and the frontend. All of these can be done without any unnecessary ceremony. - -## Resources - -Here are other resources that you may find useful to learn more about React Native and Nx. - -- **Blog post:** [Introducing React Native Support for Nx](https://blog.nrwl.io/introducing-react-native-support-for-nx-48d335e90c89) by Jack Hsu -- **Blog post:** [Step by Step Guide on Creating a Monorepo for React Native Apps using Nx](https://blog.nrwl.io/step-by-step-guide-on-creating-a-monorepo-for-react-native-apps-using-nx-704753b6c70e) by Eimly Xiong diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/setup-incremental-builds-angular.md b/nx-dev/nx-dev/public/documentation/shared/guides/setup-incremental-builds-angular.md deleted file mode 100644 index a364c5de85..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/setup-incremental-builds-angular.md +++ /dev/null @@ -1,135 +0,0 @@ -# Setup incremental builds for Angular applications - -In this guide we’ll specifically look into which changes need to be made to enable incremental builds for Angular applications. - -> Incremental builds requires Nx version 10.4.0 or later. - -## Requirements - -It’s required that you run the Angular compatibility compiler (`ngcc`) after every package installation if you have Ivy enabled. This comes configured by default in every Nx workspace. The incremental build relies on the fact that `ngcc` must have already been run. You can check your `package.json` and make sure you have the following: - -```json -{ - ... - "scripts": { - ... - "postinstall": "ngcc --properties es2015 browser module main", - ... - } - ... -} -``` - -> Please note that `ngcc` doesn’t support `pnpm` ([#32087](https://github.com/angular/angular/issues/32087#issuecomment-523225437) and [#38023](https://github.com/angular/angular/issues/38023#issuecomment-732423078)), so you need to use either `yarn` or `npm`. - -## Use buildable libraries - -To enable incremental builds you need to use buildable libraries. - -You can generate a new buildable library with: - -```bash -nx g @nrwl/angular:lib mylib --buildable -``` - -The generated buildable library uses the `@nrwl/angular:ng-packagr-lite` executor which is optimized for the incremental builds scenario: - -```json -"mylib": { - "projectType": "library", - ... - "architect": { - "build": { - "builder": "@nrwl/angular:ng-packagr-lite", - "outputs": ["dist/libs/mylib"], - "options": {...}, - "configurations": {...} - }, - "lint": {...}, - "test": {...} - }, - ... -}, -``` - -> Please note that it is important to keep the `outputs` property in sync with the `dest` property in the file `ng-package.json` located inside the library root. When a library is generated, this is configured correctly, but if the path is later changed in `ng-package.json`, it needs to be updated as well in the project configuration. - -## Adjust the app executor - -Change your Angular app’s “build” target executor to `@nrwl/angular:webpack-browser` and the “serve” target executor to `@nrwl/web:file-server` as shown below: - -```json -"app0": { - "projectType": "application", - ... - "architect": { - "build": { - "builder": "@nrwl/angular:webpack-browser", - "outputs": ["{options.outputPath}"], - "options": { ... } - "configurations": { ... } - }, - "serve": { - "builder": "@nrwl/web:file-server", - "options": { - "buildTarget": "app0:build" - }, - "configurations": { - "production": { - "buildTarget": "app0:build:production" - } - } - }, - ... - } -}, -``` - -## Running and serving incremental builds - -To build an app incrementally use the following command: - -```bash -nx build myapp --with-deps --parallel -``` - -To serve an app incrementally use this command: - -```bash -nx serve myapp --with-deps --parallel -``` - -Note: you can specify the `--with-deps` and `--parallel` flags as part of the options property on the file-server executor in your `angular.json` or `workspace.json`. The file-server executor will pass those to the `nx build` command it invokes. - -```json -"app0": { - "projectType": "application", - ... - "architect": { - "build": { - "builder": "@nrwl/angular:webpack-browser", - "outputs": ["{options.outputPath}"], - "options": { ... } - "configurations": { ... } - }, - "serve": { - "builder": "@nrwl/web:file-server", - "options": { - "buildTarget": "app0:build", - "withDeps": true, - "parallel": true - }, - "configurations": { - "production": { - "buildTarget": "app0:build:production" - } - } - }, - ... - } -}, -``` - -## Example repository - -Check out the [nx-incremental-large-repo](https://github.com/nrwl/nx-incremental-large-repo) for a live example. diff --git a/nx-dev/nx-dev/public/documentation/shared/guides/setup-mfe-with-angular.md b/nx-dev/nx-dev/public/documentation/shared/guides/setup-mfe-with-angular.md deleted file mode 100644 index 680917a589..0000000000 --- a/nx-dev/nx-dev/public/documentation/shared/guides/setup-mfe-with-angular.md +++ /dev/null @@ -1,432 +0,0 @@ -# How to setup a Micro Frontend with Angular and Nx - -[Webpack 5](https://webpack.js.org/blog/2020-10-10-webpack-5-release/) introduced a [Module Federation Plugin](https://webpack.js.org/concepts/module-federation/#modulefederationplugin-high-level) enabling multiple, independently built and deployed bundles of code to form a single application. This is the foundation of Micro Frontend Architecture and the Module Federation Plugin makes implementing such an architecture much simpler. -With Angular 12 adding support for Webpack 5 it increases the viability of scaffolding a Micro Frontend architecture with Angular. - -We made some changes to our `@nrwl/angular:app` generator to aid in the scaffolding of Module Federation configuration required for setting up a Micro Frontend Architecture. - -Therefore, using Nx it can be fairly straightforward to scaffold and build a Micro Frontend Architecture from a monorepo with all the additional benefits of Nx. - -In this guide, we'll show you to how setup a Micro Frontend Architecture with Nx and Angular. - -_NOTE: When serving MFEs in dev mode locally, there'll be an error output to the console, `import.meta` cannot be used outside of a module, and the script that is coming from is `styles.js`. It's a known error output, but it doesn't actually cause any breakages from as far as our testing has shown. It's because the Angular compiler attaches the `styles.js` file to the `index.html` in a `